Introduction to the Principles and Architecture of Curve Stablecoin
Curve Finance is a highly representative innovation in the DeFi field, whether it's in the AMM algorithm for Stablecoin Swap or the veToken economic model design, which is widely imitated by others. At the end of last year, Curve Finance proposed their stablecoin white paper, which made people curious about what new features they would offer to the DeFi ecosystem this time. During the research process, there were some insights and understanding that I hope can help everyone better unders...

TornadoCash V2: Privacy-Pools and "Proof-of-Innocence"
IntroductionTornadoCash is the most renowned anonymous transaction service in the world of cryptocurrency. TornadoCash utilizes Zero-Knowledge Proof (ZKP) technology to conceal the source of funds. The mechanism behind TornadoCash was criticized by the United States government for facilitating illegal financial activities, leading to its enforced delisting by the U.S. Treasury Department in August 2022. Privacy protection and money laundering activities often seem closely intertwined in many ...
EigenLayer Restaking Explainer
As the Ethereum Shanghai upgrade draws near, there's been a growing interest in the LSD (Liquid Staking Derivatives) sector. EigenLayer, which recently released a white paper, has been the center of attention. 『 Restaking 』 is the core concept of EigenLayer. When I first learned about EigenLayer, Restaking was the biggest issue I had trouble understanding. However, after conducting research, I've gained some preliminary understanding. In this article, I hope to help readers who shar...
https://twitter.com/ksin751119
Introduction to the Principles and Architecture of Curve Stablecoin
Curve Finance is a highly representative innovation in the DeFi field, whether it's in the AMM algorithm for Stablecoin Swap or the veToken economic model design, which is widely imitated by others. At the end of last year, Curve Finance proposed their stablecoin white paper, which made people curious about what new features they would offer to the DeFi ecosystem this time. During the research process, there were some insights and understanding that I hope can help everyone better unders...

TornadoCash V2: Privacy-Pools and "Proof-of-Innocence"
IntroductionTornadoCash is the most renowned anonymous transaction service in the world of cryptocurrency. TornadoCash utilizes Zero-Knowledge Proof (ZKP) technology to conceal the source of funds. The mechanism behind TornadoCash was criticized by the United States government for facilitating illegal financial activities, leading to its enforced delisting by the U.S. Treasury Department in August 2022. Privacy protection and money laundering activities often seem closely intertwined in many ...
EigenLayer Restaking Explainer
As the Ethereum Shanghai upgrade draws near, there's been a growing interest in the LSD (Liquid Staking Derivatives) sector. EigenLayer, which recently released a white paper, has been the center of attention. 『 Restaking 』 is the core concept of EigenLayer. When I first learned about EigenLayer, Restaking was the biggest issue I had trouble understanding. However, after conducting research, I've gained some preliminary understanding. In this article, I hope to help readers who shar...
https://twitter.com/ksin751119
Share Dialog
Share Dialog

Subscribe to Albert.Lin

Subscribe to Albert.Lin
<100 subscribers
<100 subscribers
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 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.
No activity yet