Smart Contract Architecture
What are the various contracts designed for Trading and Redeeming tokens?
The Dexible team engineered the Proof of Trade protocol to incentivize positive feedback loops through deeper engagement with the Dexible platform's functionality.
This protocol rewards traders with a rebate token tied to the volume of trades and a speculative market on the potential for increasing or decreasing trade volume. The rebate token also serves as a discount mechanism for protocol fees.
There are two primary interactions associated with the protocol:
Executing trades.
Redeeming tokens for rewards.
The flow of these interactions is illustrated in the diagram below. The diagram outlines the various stages of the Trading Process and the steps involved in Token Redemption.
The following overview serves as a foundation for a more in-depth examination of each contract and its requirements, which will be addressed in subsequent sections.
Trading Flow
Trader or Dexible relay submits a swap request to the protocol
Dexible contract uses a Swap Router contract to execute instructions in the request
The swap router calls one or more DEXs to execute the swap.
After computing fees, 50% of the bps revenue is sent to the Community Vault.
Dexible requests the vault reward the trader with tokens.
The vault uses the current mint rate against traded volume to compute the number of tokens to reward.
The vault requests $DXBL to mint new tokens to the trader (since it has the "minter" role on the $DXBL token contract).
The other 50% of bps revenue + gas is sent to the Treasury.
Redemption Flow
A. Trader initiates the burn function through the Community Vault. They specify the amount of $DXBL to redeem, their desired vault reward token (one of the Approved Vault Tokens), and their minimum expected amount (in the form of a Slippage Tolerance).
B. The pool determines Net Asset Value (NAV) using the current Assets Under Management USD values from Approved Vault Token price feeds powered by Chainlink oracles, and then computes how many reward tokens to issue to the trader.
C. The Community Vault contract makes a burn request to the $DXBL token contract, since it has "minter" role.
D. The Community Vault sends the reward tokens to the trader.
Note: Using "minimum expected amount" in the Redemption Flow exists because other traders may be burning their $DXBL in the same block, causing the amount of the specific vault assets available to deplete (example: other traders want to withdraw USDC until none is left in the vault). If the expected USDC to redeem drops so much that the amount doesn't meet the trader's expected minimum output, the transaction will fail. The trader can switch their selected reward token or wait until the vault recovers fee tokens to withdraw.
The next sections will dive into each contract in more detail, how the protocol is implemented, and how requirements are satisfied.
Last updated
