Community Vault Contract
What rules and logic guide the Community Vault.
The Community Vault oversees the administration of Approved Vault Token assets and the supply of DXBL tokens. Following the Proof of Trade ("PoT") protocol contracts, the Design Principles outlined on that page must be upheld.
See the bullet points under the headers titled Security, Trading, Gas Fees, and Community Vault.
This diagram outlines the relationship between several contracts.
At the center is the CommunityVault. This hosts the primary configuration, redemption, and pausing features of the vault. It extends several base contracts that focus on accessing stored properties, computing something based on stored properties, rewarding traders, and migrating to new versions of the vault.
StorageView provides access to the vault’s configuration and storage properties. It’s a read-only contract.
ComputationView uses stored information to compute things like AUM, mint rates, redemption estimates, etc. It too is a read-only contract.
RewardHandler handles rewarding traders with tokens and updating volume metrics to adjust mint rates, etc.
V1Migration is a mechanism used to migrate the vault to a new version if the protocol and community decide a transition is needed.
The following table outlines how each requirement is satisfied by these contracts.
Requirement | Satisfied By | Description |
|---|---|---|
1,2,4 | Gnosis Safe | All approvals for changes are managed by multi sig Safe |
5-8,10 | ComputationView and CommunityVault | Logic to manage asset values and mint rates |
9 | Dexible/Vault | Dexible is allowed to request rewards for traders and the pool computes the rewards |
3 | None | This requires general community involvement and audits |
To maintain the 24-hour volume window, the contract logic works like this:
- Hourly buckets of volume totals are maintained
- On each trade, the USD value of the trade's approved vault token is computed using the Chainlink oracle price feeds
A vault token must be the input or output token in the swap
- The current hour's bucket is incremented with the USD value
- The bucket of the previous 24-hour slot is used to reduce the total 24-hour volume and then reset to 0 to avoid multiple deductions
The following image depicts this a little more clearly:
The rolling 24-hour volume window is maintained as a circular list of buckets. 24-hour reductions are simply the next bucket with wraparound logic to account for 24-hour clock.
Last modified 3mo ago