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

The scope

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).

The method

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.

The big highlights

Deposit

• 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.

Redeem

• 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.

Stake

• 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.

Unstake

• 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.

Claim

• 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.

Takeaways:

• 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.).

We introduce this series of articles where we explain for developers how to easily interact with some of the protocols in DeFi especially to deposit/redeem/stake funds in yield generating pools.

These explanations are an appetizer for integration. Valha offers comprehensive resources to leverage them in a more complete and detailed way.

In this first episode, we are looking at Angle Protocol.

You can also read this story on Medium:

https://medium.com/@octave_18332/0-valha-integrations-how-to-deal-with-angle-slps-2174bf3534ec

Angle presentation

Angle is a decentralized, capital efficient and over-collateralized stablecoin protocol.

The Stablecoin peg relies on three groups of stakeholders: 1) Stable seekers and holders, 2) Hedging Agents and 3) Standard Liquidity Providers.

• Stable Seekers or Users: they can mint stablecoins by depositing collateral and conversely redeem collateral by burning stablecoin.

• Hedging Agents (HAs): they get leveraged positions with the multiple of their choice on a pair collateral/stablecoin in the form of perpetual futures. By doing so, they insure the Core module against the volatility of the collateral.

• Standard Liquidity Providers (SLPs): they lend money to the Core module to act as a protection layer for the protocol and make up for the Hedging Agents and Stable seekers unbalanced positions. In return they get 1) a part of the transaction fees induced by stable seekers minting and burning, as well as 2) a part of the returns made from lending capital to lending pools and DeFi strategies (like Compound, Aave, Yearn).

  An interesting thing to mention about SLPs is that they can get more yield than what they would get on Compound or Aave because they receive yield on collateral they did not bring initially. Thanks to this multiplier effect, Angle offers yield opportunities to SLPs that cannot be replicated.

Integration focus

• Protocol: Angle Protocol

• Scope: SLPs

• Version: V0

Angle's Valha integration focuses solely on SLPs. Since LPs generate yield by depositing their tokens within specific vaults, this is an attractive way to easily access lucrative yield.

High level design

1. Stable Master Contract

   StableMaster is the contract handling all the accounting. It contains the logic for the fees that are taken to users minting and burning, and for the exchange rate between sanTokens and collateral. This contract is one of the point of entry in the protocol for SLPs (and also for Stable seekers).

   address stableMasterFront = 0x5adDc89785D75C86aB939E9e15bfBBb7Fc086A87
   

2. Gauge Contracts

   Gauge contracts are a type of staking contracts for users to deposit their LP token in.

   address sanDAI_EUR_Gauge = 0x8E2c0CbDa6bA7B65dbcA333798A3949B07638026
   

3. Liquidity Pool Tokens

   “Liquidity Pool Tokens” or “LP Tokens” are tokens representing the share of a SLP into a pool.

4. Underlying Tokens

   “Underlying Tokens” are the tokens used to enter a liquidity pool for SLP.

Interactions

☝️☝️☝️In the following snippets, we consider that the contract implementing the functions has enough ERC20 balance to execute the function.

NB: There are other ways to integrate with Angle protocol, if you think that there is better way to achieve some of the interactions above, feel free to jump in the Discord to discuss it with the team!

A) Deposit

interface IERC20 {
    function approve(address spender, uint256 value) external;
}

interface IStableMasterInteraction {
    function deposit(
        uint256 amount,
        address user,
        address poolManager
    ) external;

    function withdraw(
        uint256 amount,
        address burner,
        address dest,
        address poolManager
    ) external;
}


/// @notice External function to deposit an underlying token into a SLP pool
/// @param _amount Amount of underlying token to deposit
/// @param _receiver Address that will receive the LP Tokens
/// @param _poolAddress Pool address to deposit in
/// @param _token Underlying token address that it uses to deposit
/// @dev Once this function is called, LP token will be minted for the corresponding amount of underlying token and distributed to the _receiver.

function deposit(uint256 _amount, address _receiver, address _poolAddress, address _token) external {
        address poolManager = getPoolManager(_poolAddress);
        IERC20(_token).approve(stableMasterFront, _amount);
        IStableMasterInteraction(stableMasterFront).deposit(_amount, _receiver, poolManager);
}

B) Redeem

interface IERC20 {
    function approve(address spender, uint256 value) external;
}

interface IStableMasterInteraction {
    function deposit(
        uint256 amount,
        address user,
        address poolManager
    ) external;

    function withdraw(
        uint256 amount,
        address burner,
        address dest,
        address poolManager
    ) external;
}

/// @notice External function to withdraw LP tokens from a SLP pool
/// @param _amount Amount of LP token to redeem
/// @param _burner Address that owns the LP token to be redeemed
/// @param _receiver Address that will receive the underlying token
/// @param _pool Address Pool address to withdraw from
/// @dev Once this function is called, LP tokens will be burnt and the corresponding amount of underlying token will be transferred to the _receiver.

function redeem(uint256 _amount, address _burner, address _receiver, address _poolAddress) external {
    address poolManager = getPoolManager(_poolAddress);
    IERC20(_poolAddress).approve(stableMasterFront, _amount);
    IStableMasterInteraction(stableMasterFront).withdraw(_amount, _burner, _receiver, poolManager);
}

C) Stake

interface IGaugeInteraction {
    function deposit(
        uint256 amount,
        address user
    ) external;

    function withdraw(
        uint256 amount,
        bool claim_rewards
    ) external;

    function claim_rewards(
        address user,
        address receiver
    ) external;
}

interface IERC20 {
    function approve(address spender, uint256 value) external;
}

/// @notice External function to withdraw LP tokens from a SLP pool
/// @param _amount Amount of LP token to deposit in the gauge
/// @param _receiver Address which will own the LP tokens once staked. LP token ownership could be transferred to a new address
/// @param _poolAddress LP token pool address
///@param _gaugeAddress Address in which the LP token amount is staked
function stake(uint256 _amount, address _receiver, address _poolAddress, address _gaugeAddress) external {
     IERC20(_poolAddress).approve(_gaugeAddress, _amount);
     IGaugeInteraction(_gaugeAddress).deposit(_amount, _receiver);
}

D) Unstake

This function enables to get back your LP tokens from the staking addresses.

interface IGaugeInteraction {
    function deposit(
        uint256 amount,
        address user
    ) external;

    function withdraw(
        uint256 amount,
        bool claim_rewards
    ) external;

    function claim_rewards(
        address user,
        address receiver
    ) external;
}

interface IERC20 {
    function approve(address spender, uint256 value) external;
}

/// @notice External function to redeem LP tokens from a SLP pool
/// @param _amount Amount of LP token to redeem from the gauge
///@param _gaugeAddress Address in which the LP token amount is redeemed

function unstake(uint256 _amount, address _gaugeAddress) external {
        IERC20(_gaugeAddress).approve(_gaugeAddress, _amount);
        IGaugeInteraction(_gaugeAddress).withdraw(_amount, false);
    }

E) Claim

This method enables to get liquidity mining rewards in ANGLE tokens.

interface IGaugeInteraction {
    function deposit(
        uint256 amount,
        address user
    ) external;

    function withdraw(
        uint256 amount,
        bool claim_rewards
    ) external;

    function claim_rewards(
        address user,
        address receiver
    ) external;
}

/// @notice This reward can be earned once the LP tokens are staked
///@param _gaugeAddress Address in which the LP token amount is staked
///@param _user Address associated to the staked LP tokens
///@param _receiver Address receiving the claim rewards

function claim_rewards(address _gaugeAddress, address _user, address _receiver) external {
        IGaugeInteraction(_gaugeAddress).claim_rewards(_user, _receiver);
    }

To go further

At Valha, we have the mission to make DeFi easier for developers. We want to make the promise of composability more tangible than ever by creating an abstraction layer on top of which it is intuitive, secure and efficient to integrate with any protocol in DeFi.

If you do not want to maintain all your integrations yourself, check our documentation or jump into our Discord to discuss it.

We also maintain an open-source repository of many DeFi integrations and are always for the lookup for new contributors, so feel free to explore or Github. Reach out to us on Twitter or in our Discord for potential collaboration in the future.

Foundation thesis

The last 20 years have shown a profound change in people’s experience of saving and investing. Instead of going to their local bank, it is easy to have a digital-only and intuitive experience.

The financial interface has changed, but not the backbone of financial operations. The financial infrastructure remains siloed into IT systems with different standards and limited interoperability. Even new financial applications like Robinhood are built on those old infrastructures.

As a result, the investment experience remains:

• fragmented: entities and individuals have accounts on different platforms to invest in various assets

• opaque: it is hard to understand how your savings or investment account are invested

• cumbersome: KYC process to go through each time, hard to transfer savings and investments accounts from one bank/platform to another

The DeFi promise is not yet a reality

Decentralized finance offers a new paradigm with direct and transparent access to investment for any investor.

To interact with DeFi protocols today, you have to browse and connect to protocols’ websites one by one in order to invest in DeFi pools, and connect again to different services to track these positions.

Due to the profusion of protocols and underlying pools, the experience is far from what was hoped for. The promised composability gives way to fragmentation.

This problem persists at every level:

• For wallets or investment platforms, it takes a huge amount of time to integrate with smart contracts and test them with dozens of DeFi protocols and thousands of pools.

• For protocols themselves, the integration work with these distribution platforms or with other protocols is colossal too (i.e. curve / convex integrations).

DeFi is great but too fragmented for a coherent UX that reaps the most benefits to users.

Enters Valha.

Valha: DeFi made easy

We are building a DeFi abstraction layer to facilitate interaction with protocols and pools. Our goal is to help distribute the yield to the masses.

Valha implementation

Valha is composed of two main elements: a github repository and an API built on top of it.

Github repository

As a DeFi protocol builder, to integrate into Valha and maximise distribution, you only have to to follow the steps precised in our Github:

1. List your pools

2. Code your analytics connector

3. Code your interaction connector

4. Test and merge

API

We built an API on top of the github repository. This API allows to agnostically interact with DeFi pools in the exact same way. The API ignores differences in function names, arguments and requirements by creating a rigorous standardization process.

Protocols supported

Today, we support 9 protocols with more than 30 pools on 5 different chains (Mainnet, Polygon, BSC, Arbitrum, Optimism).

Use cases

For wallets and investment platforms: support DeFi opportunities natively.

POV: You have built a wallet which is the main gateway into the DeFi ecosystem. You are certain that you will be the vector of a massive adoption for non savvy-users.

The problem? You have a shiny user interface but your users need to click on external links in order to access investment pools. Setting up an external link to investment pools is not the most exciting user experience.

You and your developer team have created a few direct plug-ins within your app but they are time-consuming to build and maintain and it is not your priority.

Only DeFi-savvy people have the expertise to explore the ecosystem by hand, we want to help everyone to do it as well. The majority of users will mainly interact only with a single interface.

With Valha, we propose a method to do this shadow work agnostically.

For protocols: reduce integration time and maximise visibility

POV: You have designed a protocol that has just launched on Mainnet. You’re certain that your protocol is offering innovative financial products that will undoubtedly be useful for a lot of users.

The problem? Word of mouth and 1-to-1 partnerships are time-consuming and expensive because relationships are not built overnight.

Once you have connected with your partners, it is time for technical integration, and every developer on both sides is overloaded with 187 integrations on the board.

In short, it is no easy task.

Otherwise, you can integrate Valha and its connectors seamlessly.

Valha offers a new DeFi integration paradigm

1. A protocol deploys its vaults.

2. It lists the vault by creating its own Valha connectors: interaction and position adapters.

3. We automatically test all the integrations to ensure they work as expected for end-users.

4. The integration is now instantly accessible across chains with standardized access through an API. End-users are only a single transaction away from depositing and staking funds.

And, what about the ERC-4626 standard?

Valha is looking to continue the revolution initiated by the ERC-4626.

The ERC-4626 standard consists in providing a standard API for tokenized yield-bearing vaults (Maple, Yearn or Morpho use the standard). It is a great step forward DeFi composability. We are big fans of the standard and eager to use it extensively.

But.

Standards are immovable and always lag behind implementation. It takes time to spread accross the whole ecosystem and the effort to adapt to the standard is quite significant for developers as it requires a custom wrapper as well as implementation checks and audits.

There is also no guarantee that a standard will keep up-to-date with the evolution of the ecosystem.

Valha wants to complement ERC-4626:

• First, by enabling the construction of ad-hoc connectors to protocols instead of time-consuming ERC wrappers.

• Second, by abstracting away the complexity to other on-chain interactions: stake, unstake, claim rewards, boost.

Join the Movement 🦫

• Join our community on Discord

• Follow us on Twitter @ValhaHQ

• To dive deeper into our connectors, you can look at our Github

Our goal is to help structure and distribute financial assets in a more efficient, transparent and secure way than TradFi will ever be capable of.

DeFi won’t be built in a day or alone. So, let’s connect!

If you want to partner with Valha to give feedback on the abstraction layer and to work for your protocol discovery, please reach out to us on Twitter or in the #partnerships channel in Discord.
This is still a work in progress so any feedback or constructive critics are welcome.