Yearn announced Yearn Allowlist on May 6, 2022, in order to improve product security. As a result, I conducted some research to see how Allowlists might improve product security.

Man-in-the-middle attacks are usually avoided by using this method. For example, to retrieve txdata, load it into a transaction, and send it out, the user will frequently utilize the paraswap API. The user's assets may be lost if the returned txdata is maliciously manipulated by an intermediary hacker. You may now use paraswap's allowlist to check whether the returned txdata is accurate. (This is just an example; I'm not sure whether or not paraswap uses allowlist.)

Allowlist defines a schema that other people can use to make their own allowlists. Multiple conditions make up the allowlist. When txdata meets one of the conditions, it is valid.

A condition refers to a function and provides an implementation contract. A condition defines the data sequence (including checking function, implementation id...) The format of each condition is depicted in the diagram below.

• id: condition id

• implementationId: An implementation contract address is represented by an id. The imlementationById map stored in the allowlist contract corresponds to the id and contract address.

• methodName: The name of the target contract's method to invoke.

• paramTypes: The types of the function arguments.

• requirements : There are two parts (type and verify function). target (check target contract) and params are the two types (check function parameters). The verification function specifies which implementation function should be used for checking.

ValidateCalldataByAllowlist() checks every condition registered in Allowlist. testCondition() will go over the conditions that were previously registered in Allowlist.

Calculate the function selector using the methodName and paramTypes of the condition to compare the first four bytes of txdata.

CheckTarget() is called if the requirement type is target. To generate txdata, use methodSignature and targetAddress, and call the implementation's verify function with staticCall.

If the requirement type is params, CheckParams() is called. To acquire the parameter values, use AbiDecoder.getParamFromCalldata() with data and paramsTypes.

To make a txdata, combine the verify function (methodSignature) with the value of the params just solved. To call the implementation's verification function, use staticCall.

It is advised that you utilize ENS/DNSSEC to validate the Allowlist's authenticity.

DApps are becoming increasingly complicated, and performing all computations on-chain will undoubtedly consume a significant amount of gas. Off-chain APIs may become a viable option in the future, but they raise additional security risks. Allowlist is an attempt to reconcile off-chain and on-chain data inconsistencies. To reduce risks and prevent the loss of user assets caused by malicious attacks, it is suggested that all services that provide APIs develop an Allowlist method.

• Yearn Allowlist

• yearn-allowlist

• yearn/eth-allowlist

Yearn announced Yearn Allowlist on May 6, 2022, in order to improve product security. As a result, I conducted some research to see how Allowlists might improve product security.

Man-in-the-middle attacks are usually avoided by using this method. For example, to retrieve txdata, load it into a transaction, and send it out, the user will frequently utilize the paraswap API. The user's assets may be lost if the returned txdata is maliciously manipulated by an intermediary hacker. You may now use paraswap's allowlist to check whether the returned txdata is accurate. (This is just an example; I'm not sure whether or not paraswap uses allowlist.)

Allowlist defines a schema that other people can use to make their own allowlists. Multiple conditions make up the allowlist. When txdata meets one of the conditions, it is valid.

A condition refers to a function and provides an implementation contract. A condition defines the data sequence (including checking function, implementation id...) The format of each condition is depicted in the diagram below.

• id: condition id

• implementationId: An implementation contract address is represented by an id. The imlementationById map stored in the allowlist contract corresponds to the id and contract address.

• methodName: The name of the target contract's method to invoke.

• paramTypes: The types of the function arguments.

• requirements : There are two parts (type and verify function). target (check target contract) and params are the two types (check function parameters). The verification function specifies which implementation function should be used for checking.

ValidateCalldataByAllowlist() checks every condition registered in Allowlist. testCondition() will go over the conditions that were previously registered in Allowlist.

Calculate the function selector using the methodName and paramTypes of the condition to compare the first four bytes of txdata.

CheckTarget() is called if the requirement type is target. To generate txdata, use methodSignature and targetAddress, and call the implementation's verify function with staticCall.

If the requirement type is params, CheckParams() is called. To acquire the parameter values, use AbiDecoder.getParamFromCalldata() with data and paramsTypes.

To make a txdata, combine the verify function (methodSignature) with the value of the params just solved. To call the implementation's verification function, use staticCall.

It is advised that you utilize ENS/DNSSEC to validate the Allowlist's authenticity.

DApps are becoming increasingly complicated, and performing all computations on-chain will undoubtedly consume a significant amount of gas. Off-chain APIs may become a viable option in the future, but they raise additional security risks. Allowlist is an attempt to reconcile off-chain and on-chain data inconsistencies. To reduce risks and prevent the loss of user assets caused by malicious attacks, it is suggested that all services that provide APIs develop an Allowlist method.

• Yearn Allowlist

• yearn-allowlist

• yearn/eth-allowlist