Design Principles
Requirements that specify how the protocol can operate.
The success of the Dexible Proof of Trade (aka "PoT") protocol requires a set of well-defined requirements for its smart contracts. These requirements are categorized as follows:
Security
To ensure the security and stability of the upgradeable smart contracts, the following measures must be implemented:
All PoT protocol contracts MUST NOT be upgradeable or changeable by a single EOA wallet.
All PoT protocol contracts MUST enforce a grace period for changes to take effect. This allows the community to review the changes being made.
All PoT protocol contracts, at a minimum, MUST be reviewed by community members to uncover gross oversights or mistakes. Ideally, an audit would be performed on all contracts as budgets allow.
All PoT protocol contracts, except the token contract, MUST be pausable in case of emergencies.
Trading
Previous Dexible contracts were known as "Settlement" contracts, accessible only through Dexible's "relay" wallets. This hybrid solution offered on-chain settlement for privately managed trades. That trading information was held off-chain, thereby concealing the intention of the traders. Dexible had a secure process for handling sensitive information and preventing alpha from leaking, including fee computations. The drawback of this approach meant there could be no public direct interaction with the protocol. The hybrid approach also resulted in inaccurate gas estimates, leading to uneven fee earnings and the trader paying more in expected gas than they would come time of execution.
To mitigate these challenges, the following measures will be implemented in Dexible version 2.0:
The Dexible contract MUST allow public access so anyone can submit trades to mine $DXBL tokens.
The Dexible contract MUST also support restricted "relay" submissions containing affiliate and other sensitive information.
Gas Fees
The oldest approach to fee management, developed in the Dexible Alpha in January 2021, resulted in serious friction. The Alpha used a Gas Tank model, where every trader would need to predeposit assets for fees. At the same time, accurate fee estimations were challenging. This resulted in thousands of dollars sitting idly in a Gas Tank contract until the trader would submit orders.
The Settlement contract was adjusted in Dexible version 1.0 to rely on fees from the swap pair. To do this, Dexible selected the token from the swap pair with the highest liquidity to draw fees from and apply the bps fee. However, this method resulted in higher on-chain computation costs. Moreover, it relied on the accuracy of asset pricing from 3rd parties to validate the appropriate fee.
To improve this process, the following requirements will be implemented in Dexible version 2.0:
The PoT protocol contracts MUST use on-chain pricing to convert gas fees to fee-token units.
Because of the previous requirement, the contracts MUST restrict vault tokens to only those with an on-chain price feed.
Community Vault
The Community Vault is an integral component for ensuring effective management of the supply and price of the $DXBL token. To fulfill this objective, the following requirements must be met:
The Vault MUST maintain an accurate 24-hour rolling window of trade volume
The Vault MUST compute the USD value of all Approved Vault Token assets (AUM)
The Vault MUST compute the current NAV of each $DXBL using AUM / $DXBL supply
The Vault MUST allow $DXBL owners to burn tokens for equivalent vault tokens based on current NAV and vault-token price
The Vault MUST reward traders with $DXBL tokens according to the Volume Curve outlined in the DXBL litepaper and only allow these requests from the Dexible contract
The Vault MUST adjust the minting rate according to 24hr trade volume
Token
As a standard ERC20 token, many of the requirements have already been established by the Ethereum community. However, the $DXBL token has unique characteristics that must be taken into consideration, as follows:
The token contract MUST allow for minting and burning, but only from the Community Vault contract
The token MUST maintain and apply a discount rate per token owned
The token SHOULD compute and adjust fees according to a trader's balance
It's not critical for the token to compute fees. It's an additional feature that has already been implemented but is not required. The token operates just fine without a function to compute fees. It's a convenient function for traders to apply token-balance discounts to fees.
Last updated