Automated Dynamic Market Maker (ADMM)
Last updated
Last updated
Portal's Automated Market Maker (AMM) protocol introduces a new paradigm shift from the current industry conventions, primarily in handling complex cross-chain transfers. The Portal AMM brings a set of unique traits that redefine the optimal liquidity provider strategy. These distinctive features offer significant advantages in terms of capital efficiency and pricing accuracy for our users. This groundbreaking AMM approach, known as "ADMM" (Automated Dynamic Market Maker), stands out in the market, with only a few comparable trading products currently in operation. Thus, highlighting the innovative nature of Portal's ADMM methodology.
The generalized flow of a swap of two crypto-assets is depicted in the schematic above. In the case of swapping ETH/ERC-20 with BTC, ETH/ERC-20 is transacted on the Ethereum L1 and BTC is transacted on the Lightning L2. For crypto assets being transacted on L1s capable of supporting smart contracts and persistent storage (Ethereum in this case) there is a “DEX Contract” account that manages the initiation and execution of swaps and also manages compensation paid to validators and LPs.
Portal DEX implements non-custodial, atomic swap of two cryptocurrencies residing on different L1s or L2s. “Non-custodial” means that, until successful completion of a swap, custody of a trader’s assets are not transferred to any parties. “Atomic” means that, for the scenario of trader Alice swapping with trader Bob, the only possible outcomes are: (1) Alice gets Bob’s asset AND Bob gets Alice’s asset (i.e. the swap occurs); or (2) both Alice AND Bob retain their original assets (i.e. no swap occurs).
The first version of the Portal DEX implements swaps of BTC (via the Lightning L2) and ETH/ERC20 (via the Ethereum L1). The components of, and participants in, the Portal DEX are depicted in Figure above.
Traders initiate the sale of a cryptocurrency they currently own in order to buy another cryptocurrency, i.e. a “swap”. Traders do not trade directly with each other but with Liquidity Pools managed by a Dynamic Market Maker (ADMM) smart contract that executes on the Notary Chain. The Notary Chain operates in parallel with all L1s and L2s involved in swaps. The nodes of the Notary Chain are run by Validators. Liquidity Providers (LPs) commit to being counterparties to specific swaps by depositing cryptocurrencies into liquidity pools.
The operational logic of the Portal DEX is distributed across smart contracts executed on both the Notary Chain and the respective Layer 1 (L1) chains hosting the swapped assets.. Smart contracts on the Notary Chain oversee Liquidity Pools and pair LP pools for each swap. Concurrently, smart contracts or scripts on L1s implement escrow mechanisms, predominantly in the form of Hashed TimeLock Contracts (HTLCs), to govern asset transfers. HTLCs are configured with the hash of a secret generated by the trader. To obtain the counterparty's asset, the trader must disclose the secret, enabling the counterparty to retrieve the trader's asset. If either party fails to reclaim the counterparty's asset within the timelock duration, both parties gain the ability to retrieve their original assets.
Automated Dynamic Market Maker (ADMM) controls all the trades on the Portal Network. In essence, it is a decentralized protocol responsible for overseeing trades across various blockchains without relying on any central party. Some key features of ADMM are listed below.
ADMM's implementation is similar to Uniswap V3, offering support for market orders, range orders, and limit orders.
Liquidity Providers (LPs) have the flexibility to establish range orders at their discretion, introducing a specified quantity of a particular asset into the corresponding liquidity pool. ADMM verifies the LP's financial capacity to meet the commitment and subsequently updates the caller's liquidity commitment in a global data structure.
The price range, spanning from the lower to the upper bounds, is divided into increments known as ticks. The total allocated liquidity for the range order is evenly distributed across each of these ticks. Consider the following example:
Range Order: Consider a range order with 10,000 units of liquidity, specified for a price range between 1 and 2.
Conversion into Limit Orders: This range order will be transformed into multiple limit orders, each positioned at a distinct tick within the range.
Liquidity Allocation: Given our tick spacing of 0.0001, each tick between 1 and 2 will have an associated limit order with 1 unit of liquidity allocated to it. This ensures that the total liquidity is evenly spread across the entire price range.
Swap transactions incur lower costs on the Notary Chain and can leverage liquidity positions for each trade, a feature that proves prohibitively expensive in Uniswap.
Swap transactions are also grouped together to be processed per block on the Notary Chain, this mitigates the risk of swaps being front run by a participant.
User Alice has ETH and wants to sell for BTC using the Portal Network
Alice creates a swap intent with the DEX CA on Ethereum by time-locking ETH and specifying the swap conditions
Validators register the swap intent on the coordination chain
LPs can provide custom concentrated positions
LPs and trader Alice gets matched for the HTLC swap with the quoted price from the coordination chain
LPs create the second leg of the HTLC by time-locking the BTC
Alice uses the atomic swap secret to withdraw BTC, and LP gets ETH
LP Bob wants to earn yield from providing liquidity for PORTAL cross chain swaps
LP creates a multisig with validator network with time-lock till end of epoch
LP time-locks BTC and stakes 2% of total liquidity with validators
LP commits liquidity positions on the coordination chain
If LP backs out of a trade after matching with trader then 2% of the trade amount from the stake will be slashed
LP withdraws at the end of epoch or continues to the next epoch
LPs receive a cut of the swap fee for each trade, paid in native swapping tokens.
Swap fees for client: 0.3% (TBD) of Client’s token
LP facilitating the trade gets 50% of the fees and the DEX Contract Account (CA) receives 50% of the fees which is distributed among validators
