A51 Carbon Docs
  • ๐Ÿ“„A51 Finance Thesis
    • โš™๏ธAMM With Liquidity Shaping Intents
    • ๐Ÿ—บ๏ธOur Roadmap
    • ๐ŸŒOur Ecosystem
  • ๐Ÿฆ„A51 Carbon
    • ๐Ÿ’ŽWhat is A51 Carbon?
    • ๐ŸŸ Key Features
    • ๐Ÿ—๏ธArchitecture
    • ๐ŸŽฎKey Intents
      • ๐ŸคฟPool
      • ๐Ÿ’ตFee
      • ๐Ÿ“ˆMarket Shifting
      • Price Range
      • ๐Ÿ“ŠLDFs (coming soon)
      • ๐ŸŸฃAuto-Rebalance
      • Auto-Exit
      • ๐Ÿ’ฐUse Idle Liquidity
      • Hedging
      • ๐ŸŽIncentivization
    • ๐ŸงฉExample Auto-Pools
      • wstETH-ETH - Minimum LVR
      • ETH-USDC - JIT Liquidity While Lending on AAVE
  • ๐Ÿ‘พA51 V3
    • Architecture
    • Intents
      • Auto-Rebalance
        • Market Modes
          • โ“How to Select a Market Mode
        • Auto-Rebalance Types
        • Rebalance Triggers
        • Rebalance Count
      • Fees Intents
      • Single-Asset Deposit
      • Zap In
    • Guides
      • Carbon Glossary
      • How to Define a Market Shifting Intent?
      • How to Create an Auto-Pool?
      • How to Deposit Liquidity
      • How to Manage Your Strategy
  • ๐Ÿช™$A51 Token
    • $A51 & Its Utility
    • $A51 Token Stats
    • FOO Tokenomics
      • ๐Ÿ“ฐBackground
      • ๐Ÿ—ณ๏ธBecome a Voter
      • ๐Ÿช™What is $oA51?
      • ๐ŸชœVoting Mechanism
      • ๐Ÿ’ฐEarn Revenue in $ETH
      • ๐Ÿ“ˆMaximize Your Rewards
    • A51 Bridge
  • ๐Ÿ‘ฅA51 Community
    • ๐ŸSocial Links
  • ๐Ÿฆ•Brand Assets
    • A51 Logo Variations
Powered by GitBook
On this page
  • Base Vault
  • Strategy
  • ID Representation of Intents in Base Vault
  • Fee-Sharing Mechanism For Common Strategies
  • Hierarchy Followed in Contracts:
  • HODL Inside Strategy
  • Governance Fee
  1. A51 V3

Architecture

PreviousETH-USDC - JIT Liquidity While Lending on AAVENextIntents

The underlying protocol has a main base vault and module contracts that manage the userโ€™s liquidity according to the intents selected by the user.

Base Vault

Base contract has the integration with concentrated AMM and it implements the basic required actions to move the userโ€™s liquidity for the intent selected by the user. Since all AMMs have some common functionalities e.g. mint, burn, collect & swap, all these functions are integrated in the base contractโ€™s library PoolActions.sol.

All pools are managed in the base vault and it deploys strategies for each pool and multiple strategies can be created for each pool. Each strategy has multiple states which is explained in Strategy section below.

Base vault has separate fee-sharing mechanisms for compounding strategies and non-compounding strategies. All the data of users will be stored on the base vault i.e. mode selected by the user, liquidity delta, upper tick, lower tick, and fees earned by the user. NFT will be minted to users against all the above details since each user has custom strategies every time when they deposit a new strategy.

Strategy

The strategy could be considered as a separate vault inside the base. Strategy owners can only select a single mode out of four rebalance intents (bull, bear, dynamic, static) during strategy creation. Strategy creators can also select other liquidity intents:

  1. Auto-exit and Reinvest

  2. Liquidity Distribution

  3. Hedging

Rebalance intents have a variety of actions e.g. Rebase Inactivity, Price Preference, Active Rebalance. Similarly every intent can introduce new liquidity actions.

Strategy also has position ticks and preferences (depending on other intents) which are selected by owners. Soon after the current price goes outside the desired price range a new position will be minted with new ticks and the transaction is triggered by the bot (off chain bots are monitoring the modes of all the strategies).

Note: Bot does not have access to the funds of users inside any strategy; all the validation is handled in smart contract they are only used to initiate the transaction when specified prices are hit.

The identities of the strategies are set by their respective hashes. The users can create their own strategy or they can select any of the previously created strategies. A single strategy will have multiple users and fees will be distributed among them according to the compounding or non-compounding fee-sharing mechanism.

If any change happens in ticks of the strategy it will be reflected to all users having the same strategy ID. The state for the strategy consists of:

  1. The hash of all mode IDs selected in this strategy

  2. The hash of all inputs of their respective intent

  3. The hash of additional data required for tracking any detail for intents

  4. Compounding or no compounding

  5. Balances left of users who joined this strategy

  6. Total shares minted through this strategy

  7. FeeGrowth for tracking of fees for non-compounding strategy

ID Representation of Intents in Base Vault

Every intent has some logic e.g. intent 1 implements the shifting of liquidity to the left with respect to current tick so this custom logic of Intent 1 will be in the modules contract that will perform actions according to the conditions of given intent.

Logic of all intents is implemented on chain. New actions for any intent could be introduced by governance. Every time any intent action is introduced through governance itโ€™s respective ID will be stored in a base vaultโ€™s module contract that contains the logic for that particular ID.

Fee-Sharing Mechanism For Common Strategies

When LPs directly deposit on AMM they only have a single position that is earning the fees so all the fees will be collected by that specific user only. In our architecture every user has a unique position and distribution of fees might be a hectic task.

Base vault has the feature that any user can join any strategy and there could be a higher probability that more than two strategies share the same ticks so in this case fee sharing is handled accordingly for compounding or non-compounding.

Hierarchy Followed in Contracts:

Single pool => contains multiple strategies => single strategy contains multiple users

So we need to take care the fee mechanism according to above hierarchy:

Single pool => fee will be distributed among each strategy => strategy will distribute the share of earned fee to their users

Base Vault Methods:

  1. Create Strategy

  2. Deposit

  3. updatePositionLiquidity (increase liquidity)

  4. collect (only non-compounders can call)

  5. shiftLiqudity (re mint or hodl liquidity of strategy)

HODL Inside Strategy

Strategy owner has the right to HODL the liquidity inside contract. For example, if market is very volatile then the assets of all the users in that strategy will sit idle in contract until the strategy owner unHODL the strategy with new ticks on AMM.

Note: Users have full authority to withdraw the strategy any time during the HODL period as well.

Governance Fee

Protocol has different fee charge mechanisms that could be applied.

  1. Protocol fee on strategy creation.

  2. Protocol fee on automation on every rebalance of strategy (public & private strategies could have different fee percentage).

  3. Protocol fee on strategy creator's performance fee.

  4. Protocol fee on strategy creator's management fee.

All these fee percentages are handled by the GovernanceFeeHandler.sol contract. Protocol fee is not applied on any chain but can be activated any time.

๐Ÿ‘พ