✨The Quicksilver architecture
The Quicksilver protocol enhances capital efficiency by delegating tokens on behalf of users and, in turn, mining a tokenised representation of user delegation, hereafter referred to as a qAsset. A qAsset takes the form of a native zone asset prefixed with q, such as qAtom or qOsmo.
The qAsset assets are liquid, fungible and transferable via an IBC transaction outside the Quicksilver zone. The underlying value of qAsset is the value of the original bond asset, plus any rateable interest earned since the mint, minus any potential losses. Thus, the value of qAsset is expected to increase over time relative to the original bond asset because the risk remains largely unchanged and the rewards increase over time.
The Quicksilver protocol is a sovereign blockchain (or zone) Cosmos SDK. Custom modules add Quicksilver-specific functionality.
The basic functionality of Quicksilver is to allow delegates to move delegations on a remote X-chain in such a way that the Quicksilver protocol controls them, and in return issues qAsset tokens that represent that position. The qAsset tokens represent the user’s claim to their original own assets — plus net rewards earned over time — and must be burned at maturity.
The interchain module for each enabled chain will generate and monitor a deposit account and delegation bucket through the Interchain Accounts IBC module.
The deposit account is designed to receive transfers of liquid own assets. When a transfer is received in the deposit account, the appropriate qAsset for the amount of delegation shares transferred will be credited to the appropriate Quicksilver chain address.
Delegation shares are then transferred to the delegation bucket and redeemed back to the delegated position so that the Quicksilver protocol receives the remuneration relating to that delegation.
At the end of each epoch (3 days), the delegation redeems the accumulated rewards and takes them back. At the border of each epoch, the redemption ratio for the “asset:qAsset” pair is adjusted to reflect the new rewards. In addition, each epoch a redistribution between the delegation packages takes place to ensure that the delegates’ wishes are properly represented in the chain.
When a user sends a redemption request with a MsgRequestRedemption transaction on the chain, qAssets are locked and a record is recorded to unlock the appropriate number of native assets. At the end of the epoch, the redemption requests are aggregated and transferred to the remote chain. At the end of the unlocking period, the locked assets are burned and the unlocked native tokens are transferred to delegator accounts on the native X chain.
