D/Bond’s APM Adorns Our Pioneering Bond-Creating ERC-3475 Token Standard
On top of D/Bond’s ERC-3475 innovativeness comes the automated pair maker (APM) method which differs from traditional automated market makers (AMMs) where liquidity pools (LPs) and providers function.
Yes, ours is the first-ever token standard to make decentralised bonds possible.
Woven into the openness and the unstoppable reach that blockchain technology guarantees, we are making bonds accessible to many users across borders — anywhere there is an Internet connection.
Quite innovative, indeed. Thanks to the in-built capabilities rooted in the Ethereum Improvement Proposal (EIP) 3475.
We were able to come up with a layer that’s a notch higher than the current ERC-20 token standard which is limited to only making liquidity pool (LP) be simple fungible proof of loans.
When it comes to issuing bonds with multiple redemption data, as required by any decentralised finance (DeFi) project, ERC-20 LP tokens do not allow for complexity in their data structure. Their standard requires the deployment of token contracts per token type.
In essence, we surmounted the main bottleneck for DeFi not being able to venture into bond-related transactions.
The APM proper
D/Bond’s APM allows an LP to pair only a single token.
It has one address for the “single consolidated pool” to which liquidity is added. Tokens are always sent to this same address to cut unnecessary expenses of gas fees when new tokens are added while consolidating liquidity.
Yet, it makes aggregated token reserves belong to several pools based on the Uniswap-inspired Virtual Liquidity Pools (VLPs) concept which tracks the fraction of reserves of each token for a given pair of tokens.
As a result, it ensures that the price of a token is not directly correlated with the token reserve held by the pool.
The APM serves other functions. They include getting liquidity added by users in the denomination of one type of token only, while an equivalent amount of the other token from the given pair — usually DBIT or DGOV — is minted by the D/Bank. The staking and buying of bonds are linked in the process.
Aside from adding liquidity, the APM also enables swaps like a classical AMM following the formula X×Y = K.
It also ensures the removal of liquidity through the redemption of bonds via D/Bank on or after the maturity date. The redeemed token is deducted from the aggregated APM reserve for that token.
The D/Bond APM functional architecture
1. Total entries for a given token represent the total reserve for that token.
2. Initially, when the token is listed/supported, 1 entry is given for adding 1 token.
3. When the liquidity is removed directly by D/Bank, the entries are not changed but only the reserve of that token changes.
4. This changes the one-to-one peg between the entries and the total reserve for that token as more entries now represent fewer tokens — but point 1 always remains true.
5. After the change, whenever new liquidity is added or removed through a swap, appropriate entries are added or removed.
6. For a given token, the appropriate number of entries to be added/removed becomes: Amount of Entries = Total Entries Total Reserve ×Amount of Token (added/removed) since point 1 is always valid.
What’s more to know
DBIT and DGOV bonds are zero coupon bonds whose face value is repaid at maturity to achieve a positive time value of money. No periodic interest payments are made (no coupon) but buying and staking methods are employed using APM and Collateralized Debt Position (CDP) features. Both features allow adding liquidity to the pool using only one type of token.
The APM system uses the CDP function to automatically mint the needed amount of DBIT to pair up with the staking asset.
While the buying method actually mints new DBIT according to the value of the pledged asset, staking uses the function to transfer the corresponding amount of DBIT from the DBIT LP to the investor. At redemption, investors get the number of DBIT bonds redeemed and the interest and principal will be paid off in DBIT.
We are set for an AMM optimization based on one of ERC-3475’s most obvious use cases: the multilayered pool. The early version of AMM uses a separate smart contract and an ERC 20 LP token to manage a pair. By doing so, the overall liquidity inside of one pool is significantly reduced and thus generates unnecessary gas spent and slippage.
Using ERC-3475, a big liquidity pool can be built with all the pairs inside. Then, with class and nonce, represent what percentage of a given token this address holds. Effectively, the ERC20 LP token is converted, in this case, to ERC 3475 (Multiple Callable Bonds) tokens.