On the Valha announcement article, we published this image:

In practice, we wanted to show what this lack of standardisation looks like for developers interacting with DeFi liquidity providement smart contracts.

We collected information on 85 protocols from 9 Layer 1 or Layer 2 (Ethereum, Arbitrum, Optimism, Avalanche, Polygon, BSC, Celo, Fantom, Tron).

Those protocoles accounts for more than $30Bn or 60% of the overall value locked in DeFi (i.e.: we took most of the DeFi protocols were the contracts were available).

We gathered information at the smart contract level on five atomic actions in DeFi

deposit, redeem, stake, unstake and claim.

1. The deposit function consists of depositing a token (often a stablecoin, the chain's native token, or a known ERC-20) into a vault in order to generate yield and subsequently receive an LP token.

2. Redeem is the opposite action.

3. The stake function consists of placing the LP token gleaned by the deposit action in a new location to earn additional return (ancillary fees, liquidity mining).

4. Unstake is the opposite action.

5. The claim function consists in recovering the rewards earned by the investor if they are not directly accumulated in the token value.

It should be noted that there are sometimes functions in the smart contract which allow to cumulate several actions (deposit and stake, claim and unstake) which are not taken into account here.

• 36 distinct deposit function names

• Top 6 function names with their number of appearances (out of 104 cases)

• 33 argument types combination out of 104 occurences (not taking into account order). On average, there is three occurrences of function with the same number and types of arguments for the deposit action.

The distribution is not uniform, in majority we have a single uint256 (basically a number) as an argument, or an address and an uint256. AMMs are the pools that require the most arguments to deposit as a liquidity provider at the opposite of native ETH staking functions which requires less than 1 argument on average.

• 26 distinct redeem function variants

• Top 4 function names with their number of appearances. (ouf of 106 appearances)

• 35 argument types combination out of 106 occurences (not taking into account order).

Bridges and AMMs require more arguments to exit a position. For bridges it explains by the fact that we might want to consider a destination chain and a destination address. For AMM, you might configure the token you want to exit with for instance. There is no redeem function for native ethereum staking as this action is impossible to date.

• 18 distinct stake function names

• Top 5 function name and their frequency of occurrence (out of 52 appearances)

• 16 argument types combination out of 52 occurences (not taking into account order).

All pool types require approximately the same number of arguments to enter a staking position as the process is similar between protocols.

• 17 different unstake function names

• Top 5 function name and their frequency of occurrence (out of 47 cases)

• 14 argument types combination out of 47 occurences (not taking into account order).

All pool types require approximately the same number of arguments to enter a staking position as the process is similar between protocols.

• 14 distinct claim function types

• Top 4 function name and their frequency of occurrence (out of 55 cases)

• 27 argument types combination out of 55 occurences (not taking into account order).

As there are a lot of claim function with zero argument it is normal to see a high frequency of no argument types combination within protocols. Claim rewards lending pool functions require twice as much argument as other pool categories. This is due to the somewhat complex claim structures on Aave and Compound in particular but it is not inherent to their pool category.

• Standards such as ERC-4626 are far from being implemented yet.

• Main standardization that we see is the adaptation to the Uniswap V2 code for AMM (Balancer, Sushiswap, PancakeSwap etc.).

On the Valha announcement article, we published this image:

In practice, we wanted to show what this lack of standardisation looks like for developers interacting with DeFi liquidity providement smart contracts.

We collected information on 85 protocols from 9 Layer 1 or Layer 2 (Ethereum, Arbitrum, Optimism, Avalanche, Polygon, BSC, Celo, Fantom, Tron).

Those protocoles accounts for more than $30Bn or 60% of the overall value locked in DeFi (i.e.: we took most of the DeFi protocols were the contracts were available).

We gathered information at the smart contract level on five atomic actions in DeFi

deposit, redeem, stake, unstake and claim.

1. The deposit function consists of depositing a token (often a stablecoin, the chain's native token, or a known ERC-20) into a vault in order to generate yield and subsequently receive an LP token.

2. Redeem is the opposite action.

3. The stake function consists of placing the LP token gleaned by the deposit action in a new location to earn additional return (ancillary fees, liquidity mining).

4. Unstake is the opposite action.

5. The claim function consists in recovering the rewards earned by the investor if they are not directly accumulated in the token value.

It should be noted that there are sometimes functions in the smart contract which allow to cumulate several actions (deposit and stake, claim and unstake) which are not taken into account here.

• 36 distinct deposit function names

• Top 6 function names with their number of appearances (out of 104 cases)

• 33 argument types combination out of 104 occurences (not taking into account order). On average, there is three occurrences of function with the same number and types of arguments for the deposit action.

The distribution is not uniform, in majority we have a single uint256 (basically a number) as an argument, or an address and an uint256. AMMs are the pools that require the most arguments to deposit as a liquidity provider at the opposite of native ETH staking functions which requires less than 1 argument on average.

• 26 distinct redeem function variants

• Top 4 function names with their number of appearances. (ouf of 106 appearances)

• 35 argument types combination out of 106 occurences (not taking into account order).

Bridges and AMMs require more arguments to exit a position. For bridges it explains by the fact that we might want to consider a destination chain and a destination address. For AMM, you might configure the token you want to exit with for instance. There is no redeem function for native ethereum staking as this action is impossible to date.

• 18 distinct stake function names

• Top 5 function name and their frequency of occurrence (out of 52 appearances)

• 16 argument types combination out of 52 occurences (not taking into account order).

All pool types require approximately the same number of arguments to enter a staking position as the process is similar between protocols.

• 17 different unstake function names

• Top 5 function name and their frequency of occurrence (out of 47 cases)

• 14 argument types combination out of 47 occurences (not taking into account order).

All pool types require approximately the same number of arguments to enter a staking position as the process is similar between protocols.

• 14 distinct claim function types

• Top 4 function name and their frequency of occurrence (out of 55 cases)

• 27 argument types combination out of 55 occurences (not taking into account order).

As there are a lot of claim function with zero argument it is normal to see a high frequency of no argument types combination within protocols. Claim rewards lending pool functions require twice as much argument as other pool categories. This is due to the somewhat complex claim structures on Aave and Compound in particular but it is not inherent to their pool category.

• Standards such as ERC-4626 are far from being implemented yet.

• Main standardization that we see is the adaptation to the Uniswap V2 code for AMM (Balancer, Sushiswap, PancakeSwap etc.).