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.

Design Principles

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.