# Staking in Proof-of-Stake Blockchain Protocols ## Overview In Proof-of-Stake (PoS) blockchain protocols, network security is achieved by allowing token holders to **lock up** (or “stake”) their assets in exchange for staking rewards. This lock-up mechanism helps protect the chain against certain types of attacks, as validators must act responsibly or risk having a portion of their staked assets **slashed** in the event of misbehavior. While essential for security, staking in its basic form prevents the staked capital from being used for other purposes, such as participating in decentralized finance (DeFi). This results in **capital inefficiency**: the majority of staked tokens remain **illiquid** until they are unstaked and pass through an unbonding period. *** ## Validators and Delegators Most PoS blockchains—including those built using the Cosmos SDK—feature two primary parties in the staking process: **validators** and **delegators**. ### Validators * **Responsibilities**: Validators maintain server infrastructure and operate software to propose and validate blocks. They work in consensus with other validators to secure the chain. * **Security Bond**: Validators must lock up a certain amount of the network’s native staking token as collateral. This deposit can be **slashed** (burned) if they act maliciously or fail to meet network requirements. ### Delegators * **Role**: Delegators stake their tokens by “delegating” them to a chosen validator, effectively granting that validator more voting power in block validation. * **Security Deposit**: The delegator’s staked tokens also serve as a security bond; if the validator misbehaves, a portion of the delegator’s stake may be slashed as well. * **Risk/Reward**: In return for helping secure the network, delegators earn **staking rewards** proportional to the value of their staked assets. However, they may face penalties if their chosen validator is penalized for downtime or double signing. *** ## Slashing Conditions Slashing is a penalty applied when validators (and indirectly their delegators) fail to follow protocol rules. The penalty reduces a percentage of the staked tokens: * **Persistent Downtime**\ A lower slashing penalty (e.g., 0.1%) occurs when a validator fails to participate in consensus for a significant period. * **Double Signing**\ A higher slashing penalty (e.g., 5%) occurs when a validator signs multiple blocks at the same block height, threatening chain security. *** ## Staking Rewards and Commissions As a reward for securing the network, each validated block generates **staking rewards**. These rewards are distributed in proportion to the amount staked. Validators typically charge a **commission** on these rewards—usually a percentage—compensating them for operating and maintaining the validator infrastructure. The remainder of the rewards is then distributed to the delegators who have staked with that validator. *** ## Unbonding Period A key feature of many PoS chains, including those that utilize Tendermint consensus, is the **unbonding period**. After a delegator decides to unstake (or “unbond”) their tokens, those assets remain locked for a duration—often between 14 and 28 days—before they become transferable again. This mechanism: * **Mitigates the “Nothing at Stake” Problem**: By locking tokens after unstaking, the protocol ensures that participants cannot instantly switch between multiple competing chain forks without consequence. * **Introduces Capital Inflexibility**: During the unbonding period, tokens cannot be traded or otherwise used in DeFi activities, creating an additional window of capital inaccessibility beyond the normal staking lock-up. *** ## Validator Incentives Since validator rewards (commission) scale with the amount of stake delegated to them, it is in a validator’s best interest to: 1. Behave reliably (no downtime). 2. Ensure secure and honest participation (avoid double-signing). 3. Maintain a strong reputation to attract more delegations, thus increasing their share of block rewards. *** ## Current Limitations On most Cosmos SDK chains, delegators face a maximum penalty of **5%** of their staked assets in the worst-case scenario (e.g., double-signing). Even though the penalty is relatively small, the **majority of staked capital remains illiquid** (up to 95%) and cannot be utilized for other blockchain activities, including DeFi. This leads to an **opportunity cost** for participants who wish to both secure the network and engage with DeFi protocols. *** #### Further Reading & References 1. Cosmos SDK Documentation – Learn more about how Cosmos-based chains implement staking. 2. Tendermint Core – In-depth explanation of how Tendermint consensus (and the unbonding mechanism) works. 3. [Slashing in PoS Networks](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-008-slashing.md) – Technical detail on how slashing is designed and enforced in the Cosmos SDK. Feel free to explore Quicksilver’s documentation to dive deeper into its liquid staking mechanics, security models, and integration options. # The Inefficiency of Proof-of-Stake Mechanism ## Capital Inefficiency In Proof-of-Stake (PoS) networks, **delegators** lock up their tokens to secure the chain and earn rewards. However, the capital committed to staking remains **illiquid** during the bonding period and throughout the unbonding phase. Although 100% of a delegator’s assets are locked, on average only about **5%** of that capital effectively contributes to network security (for instance, by incurring risk of slashing events or active participation in consensus). This discrepancy results in **capital inefficiency**: token holders are unable to leverage their staked assets elsewhere (e.g., in decentralized finance, or DeFi). This creates a significant opportunity cost for delegators who wish to both: 1. Support network security through staking. 2. Earn additional yields or participate in liquidity provisioning, lending, borrowing, and other DeFi activities. *** ## Opportunity Cost and Unbonding #### Returns Comparison When the yields available through DeFi products (e.g., liquidity pools or yield farms) exceed staking rewards by a wide margin, asset holders may prefer to **unbond** their staked tokens. Although unstaking can incur penalties and involves waiting through an **unbonding period** (often 14–28 days), the higher returns in DeFi may justify this action. #### Impact on Network Security The **opportunity cost** of keeping tokens staked (i.e., foregoing higher yields elsewhere) can encourage delegators to leave the network. This exodus can adversely affect network security: * Fewer staked tokens mean lower overall collateral backing the chain. * Lower collateral heightens the risk of governance attacks or malicious validator behavior. *** ## Case Study: Osmosis Launch A notable example of capital migration occurred in **June 2021**, when **Osmosis**, an IBC-connected automated market maker (AMM) protocol, launched on the Cosmos ecosystem. This event showcased how significant DeFi incentives can draw staked assets away from PoS networks: * **2.5% of bonded ATOM** (valued at approximately $61.7M at the time) **unbonded** in the days following the Osmosis launch. * The sudden outflow from staked to unstaked positions **reduced the overall security** of the Cosmos Hub, as fewer tokens remained bonded to validators. This scenario illustrated the practical effect of **higher DeFi returns** on PoS staking participation, emphasizing the vulnerability of PoS chains to capital flight when alternative yield opportunities arise. *** ## Implications 1. **Reduced Network Security**\ A decrease in staked tokens undermines the chain’s resilience against misbehavior or attacks. If too many stakers unbond, the chain’s security and long-term sustainability are jeopardized. 2. **Limited DeFi Participation**\ Asset holders seeking to secure the network often sacrifice the possibility of using those same assets in lending, liquidity pools, or other DeFi activities. This choice can stifle innovation and liquidity in the broader ecosystem. 3. **Balancing Yield Opportunities**\ PoS networks must offer competitive staking rewards or alternative mechanisms to retain delegators. Otherwise, staked assets may continue to flow into DeFi protocols with superior returns. *** ## Addressing Capital Inefficiency **Liquid Staking** solutions have emerged as a primary strategy to resolve this tension between network security and DeFi participation. By issuing **staked derivatives** or representative tokens, liquid staking protocols allow users to: * **Retain Staking Rewards**: The underlying tokens remain staked, contributing to network security. * **Unlock Liquidity**: Users receive a liquid token that can be deployed in DeFi for liquidity provisioning, lending, borrowing, and more. #### Quicksilver’s Role **Quicksilver** is one such solution in the Cosmos ecosystem, aiming to provide a seamless experience for Cosmos SDK-based chains: * **Security + Flexibility**: Delegators can keep their tokens staked while still accessing DeFi opportunities through **liquid staking derivatives**. * **Minimizing Opportunity Cost**: By enabling staked assets to remain productive in other protocols, Quicksilver helps reduce the incentive to unbond. * **Supporting Growth**: As more delegators stake with Quicksilver, the overall security of PoS networks can improve, while DeFi ecosystems benefit from increased liquidity. *** ### Conclusion Capital inefficiency in PoS networks arises from the trade-off between locking up tokens for network security and seeking higher yields in DeFi. Events like the Osmosis launch exemplify how quickly tokens can migrate when alternative opportunities offer superior returns. # Liquid Staking: Unlocking Liquidity in Proof-of-Stake Blockchains ## Overview **Liquid staking** is a mechanism that transforms staked tokens in Proof-of-Stake (PoS) blockchains from locked, illiquid assets into **transferable** or **tradable** tokens. By issuing a representative asset (often called a **liquid staked token** or LST) for the original bonded token, delegators can continue securing the network while simultaneously leveraging their capital in decentralized finance (DeFi) activities. *** ## Goal of Liquid Staking The primary objective of liquid staking is to empower delegators to **maintain their staked position** and earn staking rewards, **while** seeking additional yields or opportunities for their capital. This is typically accomplished by: 1. **Bonding** native tokens to a validator. 2. **Minting** a representative (derivative) token proportional to the staked amount. 3. **Using** that derivative within the DeFi ecosystem—whether for liquidity provision, lending, borrowing, or other yield-generating strategies. This process allows token holders to avoid the **opportunity cost** normally associated with locking up their assets for staking, thus bridging the gap between network security and active participation in DeFi. *** ## Opportunities and Potential Impact ### Unleashing Billions in Liquidity As of Q4 2022, approximately **$5.3 billion** worth of tokens was staked across **46 IBC-connected chains**, with an average bonded ratio of about **60%**. Traditional staking rules mean these billions in staked tokens remain locked and **illiquid**. * **Unlocked Liquidity**: By implementing liquid staking, analysts estimate up to **$5 billion** could be unlocked and redirected into DeFi protocols, providing a massive injection of liquidity across the Interchain ecosystem. * **Incentivizing Non-Stakers**: Users who have not yet staked their tokens may be encouraged to start staking if they can do so without sacrificing access to DeFi yields. ### Convergence to Higher Bonded Ratios With widespread adoption of liquid staking, it is conceivable that bonded stake levels could **approach 100%** of circulating supply. This outcome would have two major effects: 1. **Security at Theoretical Maximum**: A higher bonded ratio means more assets are securing the network, making it increasingly difficult and costly to mount an attack. 2. **Maintaining Liquidity**: Even as more tokens become bonded, liquid staking derivatives keep the supply circulating in DeFi markets, preserving user flexibility. *** ## Benefits of Liquid Staking 1. **Increased Liquidity**\ By tokenizing staked assets, liquid staking protocols give delegators the ability to deploy their “bonded” capital into various DeFi applications—such as automated market makers (AMMs), lending, or yield farming—without waiting for unbonding periods. 2. **Enhanced Security**\ When staking is made more attractive through liquid staking, more users are likely to participate. This expansion of staked tokens strengthens the overall security of the PoS network. 3. **Improved Capital Efficiency**\ Liquid staking frees delegators from the binary choice of “stake OR use in DeFi.” Instead, users can **stake AND use** their derivative tokens to earn additional returns, maximizing capital deployment. 4. **Greater Participation**\ Lowering the barrier to entry for staking—by ensuring users do not miss out on DeFi yields—encourages more users to stake. This supports both ecosystem security and liquidity. 5. **Flexibility and Portfolio Diversification**\ Stakers can rebalance their derivative tokens or change strategies in real time, giving them the freedom to pursue various opportunities within the Interchain ecosystem. *** ## Key Considerations & Potential Risks While liquid staking offers significant benefits, several considerations must be addressed: * **Slashing and Derivative Risk**: If a validator is slashed, both the staked token and its corresponding derivative can lose value. Proper risk management and validator selection remain crucial. * **Protocol Complexity**: Liquid staking protocols add layers of smart contracts and mint/burn mechanisms, introducing potential smart contract risks. * **Market Dynamics**: The value of liquid staking derivatives can fluctuate based on supply, demand, and underlying protocol incentives. Nonetheless, leading projects—like **Quicksilver**, amongst others in the Cosmos ecosystem—are actively refining their models to mitigate these risks while maximizing benefits. *** ## Conclusion **Liquid staking** represents a significant leap forward in **unlocking liquidity**, **enhancing capital efficiency**, and **strengthening security** for PoS blockchains. By enabling delegators to maintain a staked position while simultaneously participating in DeFi activities, liquid staking can **drive widespread adoption** and contribute to the growth and sustainability of the **Interchain ecosystem**. As this new paradigm continues to gain traction, the **potential impact**—in terms of billions of dollars in newly unlocked liquidity, a near-100% bonded ratio, and heightened security—could redefine how we think about securing and growing PoS networks for the long term. # Protocol Architecture ### Overview **The Quicksilver protocol** is a sovereign blockchain (zone) built with the Cosmos SDK. It introduces custom modules that enable **liquid staking** functionality within the Cosmos ecosystem, addressing the inherent capital inefficiency of Proof-of-Stake (PoS) networks. By offering a **tokenized representation of a delegator’s stake**, Quicksilver allows users to maintain staking rewards while retaining liquidity in the form of **qAssets**. *** ### How the Quicksilver Protocol Works #### Increasing Capital Efficiency * **Delegate on Behalf of Users**: Quicksilver delegates tokens to validators on **remote chains** (e.g., Cosmos Hub, Osmosis) for users who choose to stake via Quicksilver. * **Mint qAssets**: In return, the protocol mints a **tokenized representation** of the user’s delegated stake, called a **qAsset**. For instance, if the staked asset is **ATOM**, the corresponding qAsset would be **qATOM**. Because qAssets are **liquid** and **fungible**, they can be transferred or traded via Inter-Blockchain Communication (IBC) to other chains and applications. This liquidity is what enables delegators to earn both **staking rewards** and **DeFi yields** without sacrificing one for the other. #### Value Proposition of qAssets The value of each qAsset reflects: 1. The **underlying bonded asset** (e.g., ATOM, OSMO), 2. **Accumulated staking rewards** since minting, minus any slashing penalties, and 3. A **redemption rate** that increases over time, aligning with additional rewards. As network risk remains relatively constant, qAssets are expected to appreciate in price against their underlying asset over time, since they incorporate the accumulating staking rewards. *** ### Architecture & Functionality The Quicksilver architecture utilizes Cosmos SDK modules and **Interchain Accounts (ICA)** to manage staking on remote chains securely and transparently. #### Interchain Staking Module 1. **Deposit Account** * Each **onboarded chain** (e.g., Cosmos Hub) has a deposit account on Quicksilver. * When a user transfers their native tokens from the remote chain X to Quicksilver, those tokens land in this deposit account. 2. **Delegation Account** * The delegation account holds **delegation shares** corresponding to the user’s stake on chain X. * These delegation shares represent the staked position and capture the proportional ownership of the original assets plus any rewards accrued. #### Steps in the Staking Flow 1. **Transfer & Mint** * The user sends native tokens (e.g., ATOM) from chain X to the Quicksilver deposit account via IBC. * Quicksilver **mints** qAssets (e.g., qATOM) and credits them to the user’s address on the Quicksilver chain, reflecting a staked position. 2. **Redeem for Delegation** * The delegation shares move from the **deposit account** into the **delegation account**, effectively converting them into a natively delegated position on chain X. * From this point, **Quicksilver** collects and compounds any staking rewards associated with these shares. 3. **Reward Accrual & Restaking** * At the end of each **Epoch** (set to 3 days), Quicksilver calculates the rewards accrued in the delegation account. * These rewards are **restaked** to increase the total amount of tokens securing the network, thereby boosting future rewards. * The **redemption rate** (Asset : qAsset) is updated to account for the newly staked rewards, raising the value of each qAsset. 4. **Rebalancing** * At each epoch boundary, the Quicksilver protocol **rebalances** delegation shares to align with delegators’ preferences— for example, adhering to certain validator weightings or allocation strategies. *** ### Redemption Process When users wish to redeem their qAssets for the underlying tokens, the protocol enforces a sequence to ensure proper unbonding and staking rules: 1. **Redemption Request** * The user sends a `MsgRequestRedemption` transaction on the Quicksilver chain, specifying how many qAssets they want to redeem. * Those qAssets become **locked**, and an **unbonding record** is created to track the corresponding native assets on chain X. 2. **Unbonding** * At the end of the current **Epoch**, Quicksilver aggregates redemption requests and submits them to the remote chain (chain X). * The protocol initiates the **unbonding period** on chain X (e.g., 14–28 days for some networks). 3. **Final Settlement** * Once unbonding completes on chain X, the previously staked tokens become liquid again. * Quicksilver **burns** the locked qAssets and **transfers** the unbonded native tokens back to the user’s account on chain X. This approach respects the underlying chain’s unbonding rules while giving qAsset holders a clear path to reclaiming their staked tokens. *** ### Key Benefits & Highlights 1. **Capital Efficiency** * Delegators earn **staking rewards** while maintaining liquidity for **DeFi activities**, maximizing the utility of their capital. 2. **Security Maintenance** * By encouraging more users to stake (through liquid staking), PoS blockchains can maintain or increase their **bonded ratio**, bolstering security. 3. **IBC Compatibility** * qAssets can be freely transferred across different Cosmos IBC-enabled chains, unlocking broader use cases in lending, DEXes/AMMs, yield aggregators, and more. 4. **Automated Rewards & Rebalancing** * Quicksilver automatically **redeems** and **restakes** rewards each epoch, compounding returns for delegators over time. * The protocol **rebalances** delegations to ensure they conform to user preferences or governance mandates. 5. **Transparent & Modular** * Built on the Cosmos SDK, Quicksilver leverages established, modular components like **Interchain Accounts** for secure multi-chain staking operations. *** ### Conclusion The **Quicksilver protocol** leverages the Cosmos SDK’s modularity and the power of IBC to deliver a robust **liquid staking** experience. By issuing qAssets for delegated positions, it frees users from the traditional lock-up of staked tokens, increasing overall **capital efficiency** while preserving (and even boosting) **network security**. **Key Takeaway**: Quicksilver’s architecture not only enables continuous compounding of staking rewards but also opens up new realms of DeFi possibilities for liquid staking tokens. As the Cosmos ecosystem grows and interconnectivity strengthens, Quicksilver stands at the forefront of advancing **capital efficiency**, **stakeholder flexibility**, and **chain security** in the Interchain. *** #### Further Resources * Cosmos SDK – Learn more about the framework for building sovereign blockchains. * [Interchain Accounts Module](https://ibcprotocol.org/) – Technical details on how accounts are controlled across multiple chains using IBC. * [Staking & Unbonding](https://github.com/cosmos/cosmos-sdk) – Understand the fundamental mechanics of delegation, rewards, and slashing. # Quicksilver Features ### Quicksilver’s Objectives Quicksilver aims to **solve the Staker’s Dilemma**—the trade-off between securing the network by staking and participating in DeFi for potentially higher yields. By **facilitating DeFi participation** through liquid staking, Quicksilver: 1. **Enables Higher Yields**: Users can earn staking rewards while also leveraging their assets in DeFi. 2. **Increases Liquidity**: More capital remains available in the Cosmos DeFi ecosystem, supporting growth across interconnected chains. 3. **Maintains Chain Security & User Sovereignty**: Key design choices ensure that security and users’ autonomy over their assets remain uncompromised. *** ### Unrestricted Validator Choice **Decentralization** is a guiding principle of Quicksilver. Consequently, the protocol employs **Unrestricted Validator Choice**, empowering delegators to stake with **any validator** on a target chain. This flexibility: * **Prevents Validator Centralization**: Distributing stake across many validators helps avoid excessive concentration of power. * **Ensures User Autonomy**: Delegators retain the freedom to choose validators who align with their preferences (performance, governance stance, etc.). *** ### Scalability Quicksilver integrates **Interchain Accounts (ICA)** and **Interchain Queries (ICQ)** to achieve seamless scalability: * **Expanding to Any IBC-Connected Chain**: Any blockchain that supports ICA and is connected via the Inter-Blockchain Communication (IBC) protocol can be “onboarded” to Quicksilver. * **Governance-Driven Onboarding**: To add a new chain (or “zone”), the Quicksilver community simply passes a governance proposal, keeping the decision-making **in the hands of token holders**. This approach allows Quicksilver to grow alongside the broader Cosmos ecosystem without sacrificing operational efficiency or decentralization. *** ### Governance by Proxy Quicksilver introduces **Governance by Proxy**, enabling users to retain their voting rights when liquid staking through the protocol. As a result, delegators can: * **Continue Participating in Governance**: Even while assets are staked via Quicksilver, users maintain their voice in proposals on the native chain. * **Safeguard Community Decision-Making**: By distributing governance power across all stakers, Quicksilver helps ensure that the community’s interests guide network upgrades and policy choices. **Note**: Governance by Proxy is still under development, but its implementation reflects Quicksilver’s commitment to upholding active governance as a cornerstone of the ecosystem. *** ### Participation Rewards To encourage **decentralized staking** and support smaller, high-performing validators, Quicksilver allocates part of its **QCK token inflation** to **Participation Rewards**. Specifically: * **Reward Distribution**: At each epoch (every 3 days), QCK tokens are distributed to delegators who stake with smaller, reliable validators that actively participate in governance. * **Enhanced Security**: Dispersing stake across many validators helps protect chains from attacks and reduces the risk of censorship. * **Fostering Decentralization**: Rewarding delegators for supporting smaller validators counters the natural tendency toward staking with only a few large validators. *** ### Frictionless User Experience Quicksilver is designed to deliver a **simple, seamless** journey for users: * **Auto-Compounded Rewards**: The protocol automatically compounds staking rewards every epoch, eliminating extra steps for users. * **Minimized Complexity**: Liquid staking becomes as straightforward as transferring assets and receiving the corresponding qAssets in return. By reducing operational overhead and streamlining processes, Quicksilver lowers barriers to entry, facilitating broader participation in liquid staking and Cosmos DeFi. *** ### Conclusion Through **Unrestricted Validator Choice**, **scalable** architecture, **Governance by Proxy**, **Participation Rewards**, and a **frictionless user experience**, Quicksilver directly addresses the Staker’s Dilemma. The protocol not only boosts **capital efficiency** and **network security** but also preserves and even amplifies **user sovereignty** and **decentralization** across the Cosmos ecosystem. # Quicksilver Fee Structure ### **3.5% Fee on Staking Rewards** Quicksilver charges a **3.5%** fee on staking rewards, applied automatically at the end of every **epoch** (3 days). *** ### **Native Token Fees** The protocol collects fees in each onboarded chain’s native token (e.g., **ATOM**, **STARS**) when compounding rewards. *** ### **Redistribution to QCK Stakers** All fees collected by the protocol are redistributed to **QCK stakers**, aligning community incentives and supporting ongoing protocol development. *** ### **Token Transfer Mechanism** The Quicksilver application provides a user-friendly feature to **send tokens back to their origin chain** or directly to **Osmosis** via the appropriate IBC routes. This ensures seamless movement of assets within the Cosmos ecosystem. # Calculating Your Liquid Staking Returns How are staking rewards calculated on the Quicksilver protocol? When estimating the number of **Assets** you’ll receive after a certain period of liquid staking, only a few parameters are required: 1. **D** = Your initial deposit size (in Assets) 2. **r₁** = The redemption rate at the moment you convert **Assets** to **qAssets** 3. **r₂** = The redemption rate at the time you redeem your **qAssets** back into **Assets** Your expected earnings (**E**) can be calculated as follows: $$ E = D \times \left( \frac{r\_{2}}{r\_{1}} - 1 \right) $$ This formula indicates that if the redemption rate **r₂** is higher than **r₁**, you will receive more Assets than you originally deposited (plus any compounded returns). #### Tracking the Redemption Rate The **current redemption rate** for each onboarded chain is published here:\ #### Important Note on qAsset Balances After you initially deposit Assets and receive **qAssets** (e.g., 10,000 qSTARS), your **qAsset balance** remains the same in your wallet. The **value** of those qAssets, however, increases over time due to accumulated staking rewards, which is reflected in the changing redemption rate rather than the token count itself. $$ E = D \times \left( \frac{r\_{2}}{r\_{1}} - 1 \right) $$ # Redelegating & Signalling Intent ### Signalling Intent Overview **Signalling Intent** is a core feature of the Quicksilver protocol that empowers delegators to specify which validators should receive their stake. By collecting these individual “Intents” from all users, Quicksilver can accurately align staking distributions with the community’s preferences while maintaining **user sovereignty**. *** ### Initial Deposit When a user makes a **first-time deposit** to Quicksilver: 1. **Validator Selection** * Users can select **up to 8 validators** on the target chain to delegate their stake. * They can choose **equal stake** distribution (automatically dividing the stake equally across the chosen validators) or **custom allocations** (assigning specific percentages to each validator). 2. **LSM Integration** * If depositing from an **existing delegation** using **Liquid Staking Module (LSM)**, Quicksilver adopts the composition of that pre-existing delegation as the user’s **initial Intent**. This initial configuration forms the baseline preferences for where a user’s stake should be allocated—referred to as the **Intent**. *** ### Further Deposits When a user makes **subsequent deposits**, they can again specify validator preferences. However, these preferences only apply to the **newly deposited amount**. Quicksilver then blends the existing Intent with the newly stated one: $$ Overall Intent=(Existing Intent×Existing Delegation Weight)+(New Intent×New Delegation Weight) $$ This ensures every deposit updates a delegator’s total Intent in proportion to the amount deposited. *** ### Changing Signal Delegators can adjust their validator preferences at any time by submitting a **`MsgSignalIntent`** transaction on the Quicksilver chain. Key points to remember: * The updated Intent applies to the **entire weight** of the user’s delegated stake (not just the new deposit). * By issuing this message, the user effectively signals that they wish to reallocate existing delegations to new validators or adjust allocations among current validators. *** ### Epochly Rebalancing Quicksilver performs **rebalancing** at regular intervals (known as **epochs**, typically every 3 days). During this process: 1. **Aggregate Intent Calculation** * The protocol aggregates all users’ Intents for a specific chain, creating a collective picture of the **preferred validator set** and allocation. 2. **Redelegations** * Quicksilver initiates redelegation transactions to align actual staking distribution with the aggregate Intent. * **Concurrent Redelegation Constraints**: Cosmos PoS imposes limits on how many redelegations can happen at once. 3. **Eventual Consistency** * Rebalancing may take up to **one unbonding period** (14–28 days) to fully converge on the desired distribution. * Quicksilver gradually moves delegations over time to comply with user preferences without violating chain-level redelegation constraints. *** ### Limitations 1. **Concurrent Redelegation Limits** * Cosmos consensus limits the number of simultaneous redelegations per validator, so rebalancing must proceed **incrementally**. 2. **Extended Completion Window** * Achieving complete alignment with the aggregate Intent can take **up to an unbonding period** (14–28 days) due to these redelegation constraints. 3. **Moving Target** * Because new deposits and changing signals can occur at any time, the aggregate Intent itself is **dynamic**, meaning the “perfect” distribution is continuously evolving. *** ### Key Takeaways * **User Autonomy**: Delegators keep full control of how their stake is allocated, reflecting both initial deposits and any subsequent changes. * **Responsive Protocol**: Quicksilver collects Intents, aggregates them each epoch, and steadily redelegates funds to align with evolving user preferences. * **Decentralized Staking**: By encouraging users to select various validators, Quicksilver supports broader validator participation and robust network security. Through Signalling Intent, Quicksilver strikes a balance between **flexible user choice** and **orderly, protocol-driven rebalancing**, ensuring staking decisions reflect the collective will of the Cosmos community without sacrificing sovereignty or security. # Reward Socialization ## Why Reward Socialization? On many Proof-of-Stake (PoS) networks, individual validators can set their own **commission rates**, meaning that delegations to different validators may generate **varying yields** over the same time period. This variation can undercut the **fungibility** of tokenized staked assets: if two users hold the same number of qAssets, they should ideally receive the same rewards, regardless of their validator choices. To achieve this uniformity, **Quicksilver** employs a **reward socialization** mechanism. This mechanism ensures that: * **All qAsset holders** receive the **same Asset rewards**—i.e., the **collective Asset/qAsset redemption rate** increases at the same pace for everyone. * The inherent **value** of qAssets remains **equal** across all delegators, preserving their fungibility. ## User-Directed Staking Despite socializing rewards at the protocol level, Quicksilver still allows **delegators** to choose or influence which validators their stake supports—referred to as **Signaling Intent**. This approach: * **Empowers Users**: They can specify their preferred validator(s) and maintain sovereignty over their staking decisions. * **Retains Fungibility**: Users continue to receive the same **proportional** share of rewards through Quicksilver’s socialization mechanism, regardless of which validators they choose. By combining **reward socialization** with **Signaling Intent**, Quicksilver offers both **equal reward opportunities** and **individualized validator choice**. *** ## Non-Staking Denominations When rewards arrive in **non-staking denominations** (e.g., **ICS rewards** from the Cosmos Hub, **USDC rewards** from DyDx), they are distributed in proportion to each user’s **qAsset ownership** for the relevant chain, determined by **claims** (once fees have been deducted). * **Unclaimed Portion**: Any rewards tied to unclaimed qAssets (e.g., those not yet claimed by depositors) go to **QCK token holders**, ensuring no rewards remain idle. This design ensures a fair, transparent distribution of rewards—both for the **primary staking token** and any **additional** or **external** reward tokens. *** ## Key Takeaways 1. **Universal Reward Distribution**\ All users benefit from a shared reward pool, guaranteeing **equal access** to staking yields. 2. **Preserving Fungibility**\ Because every qAsset holder’s redemption rate adjusts uniformly, qAssets remain **interchangeable**, regardless of validator selection. 3. **Aligned with User Preferences**\ **Signaling Intent** allows delegators to direct the protocol’s staking choices while still receiving **equalized rewards**. 4. **Comprehensive Reward Coverage**\ Non-staking rewards—such as ICS incentives or tokens from other ecosystems—are distributed **proportionately**, ensuring no user is left behind. Through **reward socialization**, **Quicksilver** provides a **holistic** liquid staking experience that balances **fairness**, **fungibility**, and **staker autonomy** within the expanding Cosmos ecosystem. # Risk Socialization ## Why Risk Socialization? Validators in the Cosmos ecosystem can carry varying degrees of risk due to differences in hardware, software configurations, operational expertise, and independence. This variability could, in theory, result in **unequal** outcomes for delegators, depending on which validator they choose. To maintain **qAsset fungibility**—where each qAsset has the same value regardless of its associated validator—Quicksilver employs **risk socialization**. * **Shared Impact**: If one validator faces a slashing event, **all** holders of that corresponding qAsset share the impact. * **Equal Distribution**: Instead of burdening only those delegating to a problem validator, the protocol adjusts the **Asset : qAsset redemption rate** negatively, spreading the effect **evenly** among holders. ## Minimizing Risk Through Decentralization While slashing events affect the entire qAsset supply, their impact can be **mitigated** if the protocol’s delegations are sufficiently **decentralized**. By distributing stake across multiple validators: * The failure or misbehavior of any single validator has a **reduced overall impact**. * Users benefit from a more **robust** network, strengthening both security and reliability. *** ## Slashing Events and Redemption Rate Impact ### Severity and Validator Size The effect of a slashing event on the **redemption rate** depends on: 1. **Type of Infraction** * **Double Sign**: Typically a 5% slash. * **Downtime**: Often a 0.1% slash. 2. **Validator’s Share of Total Stake** * An “average” validator managing around **1%** of the network’s total stake has a proportionate effect on the redemption rate. ### **Examples** * **Double-Sign Slash (5%)** * For a validator with 1% of the total supply, the **redemption rate** decreases by **0.05%**. * **Downtime Slash (0.1%)** * For the same validator (1% of total supply), the **redemption rate** drops by **0.001%**. These percentages reflect how slashing, though serious, is **diluted** among all qAsset holders in proportion to how much stake that validator manages. *** ## Protocol Response to Double-Sign Infractions When a validator is **tombstoned** (permanently barred) after a **double-sign** offense, Quicksilver moves to preserve network health and maintain balanced validator distribution: 1. **Redelegation** * Subject to the **redelegation limits** of the Cosmos network, Quicksilver reassigns the tombstoned validator’s delegation to the **next eligible validator** in the active set. 2. **Network Stability** * This smooth transition **minimizes disruption** to users’ staked positions and helps maintain a **secure** and **well-functioning** network. *** ## Key Takeaways 1. **Unified Risk Profile** * By socializing risk, Quicksilver ensures that **all qAsset holders** share in potential losses, preserving the **fungibility** of qAssets. 2. **Incentive for Decentralization** * Broad validator distribution decreases the probability and severity of a single validator’s slash event impacting the protocol. 3. **Adaptive Protocol Response** * In the event of severe infractions like double-signing, Quicksilver **redelegates** to uphold network security and maintain a healthy validator set. Through **risk socialization**, Quicksilver remains committed to **equalizing staking outcomes** for qAsset holders while supporting **robust** and **diversified** validator infrastructure across the Cosmos ecosystem. # Designed to Support Cosmos and Beyond Quicksilver is designed to be the **liquid staking standard** in the Cosmos ecosystem by emphasizing **decentralization**, **security**, and **community** at every level. Its unique mechanisms and modules protect assets, anchor the protocol in Inter-Blockchain Communication (**IBC**), and expand the possibilities of **DeFi** across interconnected chains. *** ### 1. Safe, On-Chain Deposits * **Native Chain Custody**\ When users liquid-stake assets through Quicksilver, their tokens never leave the **native chain**. Instead, the protocol utilizes **deposit accounts** on that chain, to which users send tokens **directly** from their personal wallets. * **Security & Sovereignty**\ Because assets remain on their origin network, users retain the robust security and governance guarantees of the native chain itself. Quicksilver’s mechanisms simply help transform staked assets into **liquid representations** (qAssets), without sacrificing sovereignty. *** ### 2. Staking Rewards Fees & Distribution * **Fees on Staking Rewards**\ Quicksilver charges a **staking reward fee** for maintaining and compounding user delegations, collected on an **epochly** basis (typically every 3 days). * **QCK Token Staker Incentives**\ The fees accrued from staking rewards are distributed to **QCK stakers**, incentivizing them to support the protocol and aligning the interests of the Quicksilver community. *** ### 3. Evolution from Airdrops to Participation Rewards * **Original Airdrop Intention**\ Initially, Quicksilver planned to **airdrop** tokens to users on all onboarded chains (a popular model in 2022). However, changing market conditions at launch made this approach less suitable. * **Expanded Participation Rewards**\ The protocol has since evolved to reward users for **holding and using qAssets**—an expanded participation mechanism that incentivizes active engagement within the Cosmos ecosystem, rather than simple snapshot-based airdrops. *** ### 4. Cross-Chain Smart Contracts * **CosmWasm Enablement**\ Quicksilver plans to enable **CosmWasm** in the future, inviting developers to build **cross-chain** DeFi applications on the Quicksilver Zone. * **Leveraging Unique Features**\ Builders can take advantage of Quicksilver’s implementations of **Interchain Accounts (ICA)**, **Interchain Queries (ICQ)**, and the evolving participation rewards module, creating an **interchain DeFi hub** powered by Quicksilver’s secure architecture. *** ### 5. Expanding Beyond Cosmos * **Support for Non-ICA Chains**\ Quicksilver is developing a trustless system to onboard **IBC-connected chains** that do not implement **Interchain Accounts (ICS27)**. This will open the door for **many more chains** beyond traditional Cosmos SDK networks. * **Larger Interchain Vision**\ By expanding its liquid staking services beyond the current IBC landscape, Quicksilver aims to **unify** DeFi liquidity and security across a broader range of blockchains. *** ### Conclusion With a focus on **safety**, **community-driven design**, and **cross-chain interoperability**, Quicksilver is set to become a **cornerstone** of the Cosmos ecosystem—offering robust liquid staking, fostering DeFi innovation, and pushing interchain boundaries for **years to come**. # Supported Wallets The following wallets are supported on the Quicksilver dApp: ### KEPLR Site: Extension Link: ### LEDGER Connect to the Quicksilver protocol using Ledger via the Keplr wallet integration. ### COSMOSTATION Site: Extension Link: ### LEAP Site: Extension Link: # Unbonding ### Initiating an Unbonding 1. **Open the Staking Section**\ From the **Quicksilver WebApp**, navigate to the **Staking** area and select the network (or zone) from which you wish to unbond. 2. **Connect Your Wallet**\ Ensure your wallet is connected (e.g., Keplr or another supported wallet) to authorize the unbonding transaction. 3. **Choose the Amount** * If you hold **qATOM**, for instance, you may choose the **full** or **partial** amount you wish to unbond. * The **“half”** shortcut button automatically populates half of your available qAssets. * An **indicative** estimate of the **final returned amount** in native tokens is shown (based on the **current redemption rate**). 4. **Confirm the Transaction** * When ready, click **“Unstake”** (or the equivalent UI button) and **sign** the transaction in your connected wallet. * The transaction is queued for processing, typically **triggered** at the **next epoch boundary** (every 3 days by default). #### Important Details * **Redemption Rate Variations**\ The **final** amount of native tokens you receive is determined by the **redemption rate** **at the time** the unbonding is actually processed—this could differ slightly from the initial estimate if the redemption rate changes. * **Queue Mechanics** * Normally, unbondings are processed at the **next epoch**. * If your unbonding remains queued due to network constraints (e.g., heavy redelegation activity), the system will **retry** it in the **following epoch**.

Unstaking Interface

### Monitoring Active Unbondings After submitting an unbonding transaction, you can track its **status** in the **Assets** section of the Quicksilver WebApp: * **QUEUED**: The unbonding request has been recognized but not yet processed. * **PENDING**: The system is awaiting the next epoch boundary to finalize your redemption time. * **COMPLETION TIME**: This field will remain **PENDING** until the unbonding is processed and a final completion time is confirmed. Once the unbonding is completed, you will receive the corresponding **native tokens** in your wallet on the **origin chain**.

Active Unbondings on the Assets page

### Key Takeaways 1. **Unbonding Flow**: Submit a request → Wait for the next epoch → Tokens are converted according to the current redemption rate. 2. **Redemption Rate Dynamics**: The actual number of native tokens received depends on the redemption rate at processing time, not at the initial request. 3. **Queued Transactions**: In rare cases of heavy network usage, unbondings may remain in the queue through multiple epochs, but typically process promptly at the **very next** epoch boundary. This unbonding mechanism respects the **native chain’s rules** while providing a clear, straightforward path to reclaim your staked assets via **Quicksilver’s** liquid staking protocol. # Chain Onboardin ## Overview **Quicksilver** can onboard any **IBC-enabled chain** that supports **Interchain Accounts (ICA)** as a **host zone**, granting token holders on that chain access to **liquid staking**. This onboarding process expands the Quicksilver ecosystem, allowing users to earn staking rewards while retaining the flexibility of **liquid** (or “tokenized”) representations of their staked assets. *** ## Technical Requirements To be recognized as a **host zone**, a chain must enable ICA and support the following **message types**, which Quicksilver needs to perform essential staking and delegation operations: 1. **Bank** * `"/cosmos.bank.v1beta1.MsgSend"` 2. **Distribution** * `"/cosmos.distribution.v1beta1.MsgSetWithdrawAddress"` * `"/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward"` 3. **Governance** * `"/cosmos.gov.v1beta1.MsgVote"` * `"/cosmos.gov.v1beta1.MsgVoteWeighted"` 4. **Staking** * `"/cosmos.staking.v1beta1.MsgDelegate"` * `"/cosmos.staking.v1beta1.MsgUndelegate"` * `"/cosmos.staking.v1beta1.MsgBeginRedelegate"` 5. **IBC Transfer** * `"/ibc.applications.transfer.v1.MsgTransfer"` Enabling these message types ensures Quicksilver can **send**, **delegate**, **redelegate**, **claim rewards**, **vote**, and **transfer** tokens via ICA—covering the full lifecycle of liquid-staked tokens on the host zone. *** ## Prerequisites for Onboarding 1. **Active IBC Connection & ICS20 Channel** * The chain must maintain a valid **IBC connection** with Quicksilver and have a recognized **ICS20** token transfer channel established. 2. **ICA Host Zone Configuration** * The chain’s configuration must permit Quicksilver to **open** and **control** Interchain Accounts, with the **msg types** listed above enabled. *** ## Governance-Controlled Onboarding Although Quicksilver’s architecture allows for **permissionless** onboarding of new chains, the **back-end integration** often involves technical collaboration to deliver a **seamless user experience**. Consequently, **QCK token holders** must **govern** and **approve** each new zone. **Step-by-Step Onboarding Proposal** 1. **Signal Proposal on Commonwealth** * The requesting party (or a community member) creates a **discussion thread** on Quicksilver’s Commonwealth forum:\ [**https://commonwealth.im/quicksilver-protocol/discussions**](https://commonwealth.im/quicksilver-protocol/discussions) * This thread remains open for **5 days** to collect **community feedback** and **technical input** from the Quicksilver team. 2. **On-Chain Governance Proposal** * After the **discussion period** ends, a formal **governance proposal** is posted on the Quicksilver chain. * The proposal must include **all necessary** technical details, such as chain ID, IBC connection/channel info, unbonding period, and other **host zone** configurations. 3. **Voting & Approval** * **QCK token holders** vote to **approve** or **reject** onboarding. * If the proposal **passes**, Quicksilver automatically initiates the **zone registration** process, configuring ICA controller accounts and ICS20 transfers for that chain. *** ## Execution & Activation Upon **successful** governance approval: 1. **Zone Registration** * Quicksilver **registers** the new zone, enabling deposit accounts and **Interchain Accounts** to manage staking operations (delegation, undelegation, reward claiming). 2. **Verification & Testing** * Quicksilver verifies the chain’s **ICA** capabilities and ensures all required **msg types** work correctly. 3. **Front End** * The Quicksilver team needs to update the front end with the required information in order to open deposits to the protocol's users. 4. **Liquidity Unlock** * Once confirmed, users from the newly onboarded chain can **deposit** their native tokens to Quicksilver, **mint qAssets**, and enjoy **liquid staking** benefits. *** ## Benefits of Onboarding * **Expanded DeFi Opportunities**\ Users can **stake** their tokens while participating in DeFi across Cosmos, leveraging **qAssets** in DEXs, lending protocols, or yield aggregators. * **Strengthened Security**\ The onboarded chain potentially gains additional **stakers**, which can increase its overall **bonded ratio** and network resilience. * **Community Growth**\ More chains in Quicksilver’s ecosystem translate into **greater cross-chain liquidity** and a more vibrant, interconnected Cosmos network. *** ## Key Takeaways * **ICA Host Zone Support**: The target chain must **enable** Interchain Accounts with specific **msg types** to accommodate Quicksilver’s staking, distribution, governance, and IBC transfer operations. * **Governance Process**: QCK token holders manage and **approve** zone onboarding. Interested parties or communities must **discuss** proposals on Commonwealth before finalizing an on-chain vote. * **Technical Collaboration**: While the process is permissionless, close coordination with the Quicksilver team and the host chain developers helps ensure **smooth** integration. By following this **Zone Onboarding Process**, Quicksilver remains a **secure**, **community-driven** protocol, continuously broadening the reach of **liquid staking** in the Cosmos ecosystem. # Design Philosophy ### Tokenomics Overview **QCK** is the native token of the Quicksilver Zone, designed to align the interests of the protocol’s stakeholders, maintain strong governance, and adapt over time to changing market conditions. *** ### Adaptive Tokenomics Rather than implementing a **fixed inflation schedule** or strict issuance rules, Quicksilver’s token model remains **flexible**: * **Governance-Driven Adjustments**\ Major decisions around inflation rates, issuance, and strategic allocations are made through **protocol governance**. This ensures the token evolves in response to **community feedback** and **ecosystem needs**. * **Periodic Reviews**\ The community is encouraged to host **regular discussions** to review the token’s performance, propose enhancements, and adopt changes to maintain a **resilient, market-aligned token economy**. *** ### Distribution #### Ownership & Incentives Since the **QCK** token embodies ownership of the Quicksilver protocol, it’s essential that it remains well-distributed among stakeholders across the onboarded chains. The protocol employs several mechanisms to encourage overlapping **incentives** and **ownership** between **QCK holders** and **active users** of the Quicksilver protocol: 1. **Participation Rewards** * A portion of **QCK inflation** or allocated rewards is distributed to users who actively engage with the protocol (e.g., those who hold qAssets or stake with diverse validators). 2. **Community Incentives** * Specific incentive programs may be introduced to **reward beneficial behaviors**, such as providing liquidity, bootstrapping network security, or contributing to Quicksilver’s ecosystem. 3. **Airdrops** * While the original intent was to conduct extensive airdrops across onboarded chains, the model has evolved. Nevertheless, **targeted airdrops** may still be used when it aligns with community and governance decisions, ensuring a broad and **equitable** distribution of QCK. *** ### Key Takeaways * **Dynamic & Governance-Led**: QCK’s tokenomics adapt based on feedback, proposals, and **on-chain governance**, ensuring the token remains relevant and flexible. * **Stakeholder Engagement**: Mechanisms like **Participation Rewards** and **Community Incentives** align user interests with the health and success of the protocol. * **Broad Ownership**: By encouraging stakeholders from each onboarded chain to hold QCK, Quicksilver fosters a truly I**nterchain community** that supports ongoing growth and innovation. Through its **adaptive tokenomics** and **community-focused distribution** strategies, QCK is positioned to serve as a unifying asset within the Quicksilver ecosystem, promoting both network **security** and sustainable **economic growth**. # $QCK Token: Utility, Role and Function ## Governance Governance is a fundamental aspect of the Quicksilver network. **QCK token holders** can use their assets to **vote** on critical decisions: * **Onboarding New Zones & Incentivization**\ Proposals related to adding new chains (zones) to the Quicksilver ecosystem, as well as establishing incentive structures for their delegators and validators. * **Community Fund Spending**\ Allocation and deployment of community-controlled funds to support development, marketing, or other ecosystem initiatives. * **Network Parameter Changes**\ Adjustments to the chain’s core parameters (e.g., block time, inflation rates, upgrade schedules) for protocol optimization. * **Network Upgrades**\ Approving major protocol upgrades and improvements via governance proposals. Through on-chain governance, **QCK** holders shape Quicksilver’s growth, ensuring decisions reflect the broader community’s interests. *** ## Economic Security **QCK tokens** can be **delegated** to validators who stake them to secure the Quicksilver network through **Proof-of-Stake (PoS)** consensus. This delegation process: * **Strengthens Network Resilience**\ More QCK staked means higher security against malicious behavior or potential attacks. * **Rewards Delegators**\ Stakers receive rewards in return for their role in maintaining consensus and validating transactions. *** ## Fee Payment **Transaction fees** on the Quicksilver chain are **paid in QCK**. These fees: * **Compensate Block Producers**\ Validators and their delegators earn fees for securing the network and including transactions in blocks. * **Maintain Network Operations**\ Transaction fees help prevent spam and ensure that network resources are utilized efficiently. *** ## Conclusion The **QCK** token is central to Quicksilver’s governance, security, and economic model. By **voting on proposals**, **staking** to secure the network, and **paying transaction fees**, QCK holders play a pivotal role in shaping the future of the Quicksilver protocol and ensuring its long-term success. # Genesis Token Allocation The initial token allocation of the Quicksilver native token, QCK is 200 million. Initial allocation:
AllocationTokensVesting
Community Incentives (Airdrops & Liquidity Incentives)102.7MNone - Controlled solely by governance.
Testnet Incentives10M3-month lockup after Genesis, then 16.66% liquid. The remaining allocation will then vest monthly over 15 months.
Development team (including present DevCompany contributors, and an allocation for future DevCompany contributors and third-party dev teams)21M6 months lockup after Genesis, then monthly vesting over a period of 30 months
Investors (including potential future investments)*26.3M6 months lockup after Genesis, then monthly vesting over a period of 30 months
Foundation (Future Ecosystem Development and grants)40MNone, controlled by a multisig wallet.
# Inflation **QCK token inflation** is designed to promote **decentralization**, boost **liquid staking adoption**, and strengthen **community ownership** of the Quicksilver protocol. By creating incentives for validators, delegators, and protocol users, inflation helps align interests across the ecosystem and fosters sustained growth. *** ### Four Pillars of QCK Inflation 1. **Secure the Quicksilver Chain**\ Inflation rewards validators and delegators who stake QCK, ensuring the network remains resilient against attacks and continues operating efficiently. 2. **Support Decentralization on Native Chains**\ The Quicksilver protocol encourages diverse validator sets on the onboarded chains. By distributing rewards, Quicksilver helps those chains maintain robust security through liquid staking. 3. **Incentivize Protocol Adoption & Usage**\ QCK tokens are used to reward users who actively participate in the protocol—such as by minting and holding qAssets—which increases liquidity and engagement in the Quicksilver ecosystem. 4. **Empower the Community**\ A portion of inflation is allocated to a **Community Pool**, where governance can decide how to spend funds for the protocol’s and community’s benefit. *** ### Year 1 Inflation Distribution During the **first year**, Quicksilver’s inflation rate is **25%**. The newly minted QCK tokens are allocated as follows: * **80%: Staking Rewards**\ Distributed to **validators and delegators** who stake QCK to secure the Quicksilver chain. * **10%: Participation Rewards**\ Granted to **active users** of the Quicksilver protocol (e.g., those who hold or mint qAssets). * **7%: Incentive Pool**\ Used to **attract new users** and incentivize liquidity providers, continuously growing and diversifying the network. * **3%: Community Pool**\ Controlled by **governance**, these funds can be used to support developer grants, community events, marketing, and other initiatives that benefit Quicksilver. *** ### Governance-Driven Inflation All parameters of QCK inflation—such as **total inflation**, **yearly inflation targets**, and **emissions allocations**—are **configurable through on-chain governance**. The Quicksilver community retains full authority to: * **Adjust the Annual Inflation Rate**\ Based on market conditions, protocol needs, or the evolving DeFi landscape. * **Revise Distribution Percentages**\ Modify how the newly minted QCK tokens are divided among staking rewards, participation incentives, liquidity incentives, and the community pool. * **Manage Supply & Emissions**\ Monitor the overall token supply and guide protocol sustainability over the long term. *** ### Inflation Trajectory & Max Supply * **Year 1**: 25% inflation * **Subsequent Years**: Expected to drop by **25% per year** until it reaches **zero**. * **Max Supply**: Under this schedule, the **maximum supply** of QCK is projected to reach approximately **400 million** tokens before inflation ceases. These decreasing rates aim to balance early-growth incentives with longer-term sustainability for the QCK token economy. *** ### Key Takeaways 1. **Ecosystem Growth**\ Inflation-focused distributions promote broader adoption of liquid staking and active governance participation. 2. **Sustainable Tokenomics**\ Gradually lowering inflation aligns with the protocol’s goal of rewarding early contributors without compromising long-term token value. 3. **Community-Centric Governance**\ By empowering QCK holders to control inflation parameters, Quicksilver ensures the protocol remains flexible and responsive to community needs over time. Through its carefully designed **inflation model**, Quicksilver aligns incentives among validators, delegators, and protocol users, reinforcing **decentralization**, **security**, and **ongoing innovation** in the Cosmos ecosystem. # Interchain Accounts (Cosmos) The application-level IBC protocol known as Interchain Accounts (ICS27) allows for accounts on network A to be controlled by network B. It consists of the concepts of Controller chain and Host chain. The Controller chain is able to register an account on the Host chain by way of opening a dedicated IBC channel between the two chains. The Controller chain is able to compose transactions for execution on the Host chain on behalf of the Interchain account, encapsulate them in an IBC packet, and send them over the dedicated channel. The transaction is relayed to the Host chain, unencapsulated, and executed as if it were a local transaction. {% embed url="" %} # Liquidity Staking Module (Iqlusion) The Liquid Staking Module (LSM) is built and maintained by Iqlusion, and will become a core Cosmos-SDK module. The LSM will be supported by Quicksilver when it is enabled across Cosmos chains. It enables delegators to tokenize their staked position without the need for unbonding. The tokenized positions, or ‘shares’, are non-fungible between validators and are limited in functionality to facilitate the transfer of bonded positions. Protocols can utilize LSM in order to onboard existing delegators of a network onto the protocol without the need to unbond, and by extension, without the delegator losing rewards *nor* diminishing the security of the network. Shares are deposited with the protocol and the corresponding representative token is then minted. # Mint Module (Osmosis) Osmosis’s `mint` module is responsible for creating tokens in a flexible way to reward validators, incentivize providing pool liquidity, provide funds for Osmosis governance, and pay developers to maintain and improve Osmosis. The module is also responsible for reducing the token creation and distribution by a set period until it reaches its maximum supply (see `reduction_factor` and `reduction_period_in_epochs`) The module uses time basis epochs supported by the `epochs` module. The Quicksilver development team used the Mint Module to distribute inflation issuance, and has refactored it to support the protocol’s specific needs, such as participation rewards. # Epochs Module (Osmosis) Osmosis’s epochs module defines on-chain timers that execute at fixed time intervals. Other SDK modules can then register logic to be executed at the timer ticks. We refer to the period in between two timer ticks as an "epoch". Every timer has a unique identifier. Every epoch will have a start time, and an end time, where `end time = start time + timer interval`. On Osmosis mainnet, we only utilize one identifier, with a time interval of `one day`. The timer will tick at the first block whose blocktime is greater than the timer end time, and set the start as the prior timer end time. (Notably, it is not set to the block time!) This means that if the chain has been down, you will get one timer tick per block, until the timer has caught up. The Quicksilver development team used the Epochs Module as it is, with some parameter changes to better suit the protocol’s needs. A Quicksilver epoch is 3 days. # Claim Module (Stargaze) The Quicksilver team used Stargaze’s Claim Module as a starting point for the development of the Protocol’s Airdrop Module. # Miscellaneous The Quicksilver team vendored the Osmosis type definitions for Pools and Lockups. # Interchain Staking ## Interchain Staking Module Overview The **Interchain Staking (ICS) Module** is the core component in **Quicksilver** that enables **liquid staking** for external blockchains. By utilizing this module, users can deposit native assets from **IBC-connected** chains and receive tokenized representations of their staked positions (i.e., **qAssets**). The ICS module then manages the lifecycle of these staked tokens—from **deposits** and **auto-compounding of rewards** to **unbonding and redemption**—all while allowing users to choose their preferred validators through **intent signaling**. ### Key Objectives 1. **Liquid Staking on Remote Chains**\ Allow users to stake assets on an external chain—such as Cosmos Hub (ATOM), Osmosis (OSMO), or Stars (STARS)—while retaining **liquidity** in the form of qAssets on Quicksilver. 2. **User Sovereignty & Validator Choice**\ Grant users control over **which validators** secure their tokens, preserving **decentralization** and avoiding validator centralization. 3. **Efficient & Transparent Rewards**\ Automate **reward accrual and distribution** so that qAsset holders benefit from staking yields, minus protocol fees or slashing events. 4. **Simplified Deposit & Redemption**\ Provide a **straightforward** deposit process and a **clear path** to redeem qAssets for the underlying assets, respecting each chain’s unbonding rules. *** ## Core Functions 1. **Deposits** * **IBC Transfer**: Users initiate a **deposit** by sending native tokens (e.g., ATOM) from the external chain to a **deposit account** controlled by the Quicksilver chain. * **qAsset Minting**: Once tokens arrive, the ICS module **mints** the corresponding qAsset (e.g., qATOM) to the user’s Quicksilver address, reflecting their newly staked position. 2. **Rewards Accrual & Auto-Compounding** * **Interchain Queries & Accounts**: The ICS module interacts with the remote chain via **Interchain Accounts (ICA)** and **Interchain Queries (ICQ)** to track delegations and collect rewards. * **Epoch-Based Compounding**: At regular intervals (epochs), the module **redeems** staking rewards from the remote chain and **restakes** them, increasing the user’s total staked position and adjusting the redemption rate to reflect these new rewards. 3. **Redemption (Unbonding)** * **Redemption Request**: When users wish to reclaim their native tokens, they submit a **MsgRequestRedemption** transaction on Quicksilver. The ICS module locks the corresponding qAssets and initiates the **unbonding** process on the external chain. * **Unbonding Period**: Once unbonded on the remote chain, the ICS module returns the redeemed tokens to the user’s wallet on that chain, **burning** the qAssets on Quicksilver. 4. **Intent Signaling & Delegation Strategy** * **Validator Selection**: The ICS module incorporates Quicksilver’s **Signaling Intent** feature, letting users specify a list of validators and desired allocation percentages on the remote chain. * **Rebalancing**: At each epoch, the module **aggregates** user preferences and **redelegates** as needed—within the limits of the remote chain’s redelegation constraints—to keep actual delegations aligned with users’ stated Intents. *** ## ICS Lifecycle & Architecture 1. **Interchain Accounts (ICA)** * **Control**: The ICS module uses ICA to establish and manage one or more **controller accounts** on the remote chain. * **Actions**: These accounts perform **delegation**, **redelegation**, **claiming rewards**, and **unbonding** operations on behalf of Quicksilver users. 2. **Interchain Queries (ICQ)** * **Data Collection**: ICQ allows the ICS module to **query** chain-specific information—such as a validator’s total stake, slashing status, or reward balance—without requiring direct user intervention. * **Dynamic Adjustments**: The module uses query results to **rebalance** staking, apply **reward socialization**, and issue or burn qAssets. 3. **Redemption Rate & Reward Socialization** * **Redemption Rate**: Each qAsset tracks an ever-increasing redemption rate to reflect **auto-compounded** staking rewards. * **Socialized Outcomes**: If slashing occurs, or if a validator is tombstoned, the ICS module adjusts the redemption rate for **all qAsset holders** to maintain **fungibility**. 4. **Epochly Rebalancing** * **Intent Aggregation**: Each epoch, the ICS module calculates an **aggregate intent** (i.e., combined user preferences). * **Gradual Redelegation**: Because remote chains often limit how many redelegations can happen within a given time, the module migrates stake **incrementally** until it reaches the target distribution. *** ## Benefits & Use Cases 1. **Liquid Staking on Any IBC-Connected Chain**\ By leveraging Interchain Accounts, Quicksilver extends liquid staking capabilities to any **IBC-enabled** chain that supports **ICA** and **ICQ**. 2. **Enhanced DeFi Utility**\ Users can **hold**, **trade**, or **deploy** qAssets across Cosmos DEXes, lending protocols, and more—**all while still earning** staking rewards. 3. **Improved Validator Decentralization**\ The **Signaling Intent** feature nudges users to select diverse, high-performance validators, helping mitigate centralization risk and **strengthen network security**. 4. **Transparent, Automated Rewards**\ The ICS module seamlessly handles **reward accrual** and **auto-compounding**, freeing users from the complexities of manual claiming or re-staking. *** ## Future Developments * **Support for Non-ICA Chains**\ Quicksilver aims to **expand** ICS-like functionality to **IBC-connected chains** that don’t yet implement Interchain Accounts, broadening the reach of liquid staking beyond the Cosmos SDK ecosystem. * **Integration with CosmWasm**\ A forthcoming **CosmWasm** implementation on Quicksilver could enable **cross-chain smart contracts** that build on ICS logic—e.g., novel DeFi applications that manage multi-chain staking strategies automatically. *** ## Conclusion The **Interchain Staking (ICS) Module** is the backbone of Quicksilver’s **liquid staking** solution, providing a streamlined method for users to deposit tokens, earn rewards, and access liquidity—all while preserving **decentralization** through user-driven validator preferences. Through its integration with **ICA** and **ICQ**, Quicksilver’s ICS Module empowers a wide range of **cross-chain DeFi** possibilities, fostering a more secure and interconnected Cosmos ecosystem. # Participation Rewards ## Participation Rewards Module Overview The **Participation Rewards Module** lies at the heart of Quicksilver’s commitment to **responsible delegation** and **decentralized validator sets**. By incentivizing users to select **performant** and **community-active** validators, it fosters a healthy ecosystem and encourages qAsset holders to align with network best practices. *** ## Core Objectives 1. **Reward Positive Delegation Choices** * Each **epoch** (a set period, typically **3 days** in Quicksilver), qAsset holders receive a **portion of QCK inflation** as a reward. * **Positive delegation choices** include signaling intent for validators that: * Deliver strong performance (e.g., minimal downtime, consistent block production). * Are part of a **decentralized validator set** (not overly concentrated). * Actively participate in governance (e.g., voting on proposals). 2. **Encourage Decentralization & Governance Participation** * By rewarding stakers who support **smaller** or less-concentrated validators—especially those engaged in governance—Quicksilver promotes **validator diversity** and **community empowerment**. 3. **Adapt to Future Use Cases** * The module is **designed to evolve**. As new DeFi opportunities or governance initiatives emerge, the Participation Rewards logic can be updated to incorporate additional parameters for “positive” behavior. *** ## How It Works 1. **Signal Submission & Tracking** * Users indicate their **validator preferences** (i.e., which validators they consider “positive” targets) via the **Signaling Intent** feature. * The module **records** these signals to evaluate how closely users’ choices align with desired validator behaviors (decentralization, performance, governance engagement). 2. **Reward Allocation** * A **portion of QCK inflation**—determined by protocol governance—is allocated to **Participation Rewards**. * The module calculates each user’s share based on: * Their **qAsset balance**. * The **quality** of their signaled validator selections. * The **validator performance** data gathered over the epoch (e.g., reward generation, governance participation). 3. **Distribution** * At the end of each epoch, the module **distributes QCK** to eligible users’ wallets as **Participation Rewards**. * This distribution reflects both the **quantity** of a user’s stake and the **quality** of their delegation signals. *** ## Benefits & Impact 1. **Validator Performance & Reliability** * Delegators are incentivized to choose validators who **maximize** staking rewards, fostering a highly **efficient** validator set. 2. **Enhanced Network Decentralization** * Rewarding delegators for spreading stakes among diverse validators reduces centralization risks and helps maintain strong **network security**. 3. **Active Governance** * Validators that vote consistently and act responsibly on governance proposals are **rewarded** and thus more likely to receive delegations, fueling an active, community-led decision process. 4. **Future-Proof Design** * As **qAsset** use cases expand (e.g., new DeFi integrations, advanced governance mechanisms), the Participation Rewards Module can be **extended** to accommodate updated incentive logic, ensuring longevity and flexibility. *** ## Ongoing Development * **Additional Reward Criteria**\ Future updates may incorporate more nuanced metrics—such as validator uptime, commission rates, or advanced governance signals—to refine “positive” behavior definitions. * **New qAsset Use Cases**\ As **qAssets** become integrated into more DeFi applications (e.g., DEX liquidity, lending protocols, cross-chain yield strategies), the module’s incentive criteria may expand to recognize contributions that benefit the broader **Cosmos** and **Interchain** ecosystems. *** ## Conclusion The **Participation Rewards Module** is a pivotal component of Quicksilver’s **liquid staking** offering, ensuring that **qAsset holders** not only enjoy the flexibility of staked asset liquidity but also contribute meaningfully to **network decentralization**, **validator performance**, and **governance engagement**. By rewarding **positive delegation choices**, the module aligns individual user incentives with the **long-term health** and **sustainability** of the Quicksilver protocol and its partner chains. # Claim Manager ## Claims Manager Module Overview The **Claims Manager Module** is designed to **store** and **retrieve** proof-based claims, which are then consumed by other Quicksilver modules (e.g., **Participation Rewards**, **Governance by Proxy**, and other incentive or governance-related structures). By centralizing the management of these proofs, the module ensures **efficient**, **trust-minimized** claim verification across the protocol. *** ## Key Responsibilities 1. **Storage of Claims** * The module maintains a **secure database** of user claims, enabling other modules to reference **proofs** for eligibility or reward distribution (for instance, verifying whether a user participated in certain on-chain actions or governance processes). 2. **Proof Retrieval** * When another module needs to confirm a claim’s **validity**, the Claims Manager Module provides the relevant proof and associated metadata. 3. **Flexibility & Scalability** * Because the module is designed to handle a **broad range of proof types**, it can be extended to support **new** or **evolving** use cases over time, including inter-module communications or **cross-chain** proofs. *** ## Use Cases 1. **Participation Rewards** * Proof-based claims (e.g., a user’s validator selection or DeFi engagement) can be **stored** here and verified to determine **reward eligibility** under Quicksilver’s incentive structures. 2. **Governance by Proxy** * Quicksilver’s upcoming module uses **proofs** from the Claims Manager to **determine voting power** for native chain proposals. For example, it confirms a user’s staked position or delegated power on the originating chain to ensure accurate and **fair** representation of votes. 3. **Cross-Module Coordination** * By centralizing proof data, the Claims Manager simplifies collaboration between Quicksilver’s **other modules**, reducing overhead and maintaining **consistent** verification logic. *** ## Benefits * **Single Source of Truth**\ A unified, secure module for handling the **proof** layer of on-chain processes. * **Enhanced Efficiency**\ Streamlines claim validation by eliminating the need for repeated proof submissions or **duplicate** storage. * **Future-Proof Design**\ Supports **varied** proof structures, giving Quicksilver the flexibility to accommodate **new incentives** or cross-chain verifications as the ecosystem evolves. *** ## Conclusion The **Claims Manager Module** underpins the **proof-based** functionalities of Quicksilver, providing a robust and **scalable** framework for storing and retrieving claims. By serving as a central repository for all proof-related data, it **empowers** other modules—like **Participation Rewards** and **Governance by Proxy**—to operate more efficiently and **consistently**, ensuring a reliable, trust-minimized user experience across the Quicksilver protocol. # Interchain Queries ## Interchain Queries Module Overview The **Interchain Queries (ICQ) Module** facilitates **asynchronous** query-callback interactions between Quicksilver and remote blockchains, enabling Quicksilver to **request**, **receive**, and **verify** specific data from those chains. Quicksilver’s ICQ is the **original** implementation—predating more recent “IBC-baked” standards—using an **external relayer** rather than official ICS (Interchain Standards) for data packet transmission. Despite this, it still provides **trust-minimized** data retrieval, relying on **Merkle tree proofs** (or equivalent verification methods) to ensure data integrity. *** ## Key Objectives 1. **Secure Cross-Chain Data Retrieval** * Provide a reliable mechanism to **fetch** and **verify** chain-specific data (e.g., account balances, validator statuses) without relying on centralized intermediaries. * Rely on **cryptographic proofs** (such as Merkle proofs) to validate the authenticity and integrity of the data. 2. **Asynchronous Query-Callback Workflow** * Requests for information are **dispatched** to the remote chain via an **external relayer**, allowing Quicksilver to continue processing without waiting for immediate responses. * When the remote chain (or the relayer) returns data and proofs, the ICQ Module **invokes** a callback in the requesting module to handle that data. 3. **Broad Adoption Across Cosmos** * Quicksilver’s original ICQ architecture has been **used** and **adapted** by multiple protocols in the Cosmos ecosystem, proving both **flexible** and **resilient** over time. *** ## How Quicksilver’s ICQ Works 1. **Query Creation** * A Quicksilver module (e.g., **Interchain Staking**, **Participation Rewards**) crafts a **query request**, specifying the **remote chain**, the **target data** (e.g., delegation amounts), and **callback** details for when data returns. 2. **External Relayer Transmission** * The request is **forwarded** to an external relayer (rather than being included in an IBC packet). * This **relayer** is responsible for routing the query to the **target chain** and listening for the response. 3. **Remote Chain Processing & Proof Generation** * The remote chain **executes** the query, collects the requested data, and builds a **cryptographic proof** (often a **Merkle branch**) attesting to the correctness of that data relative to the chain’s **state root**. 4. **Response & Proof Validation** * The external relayer **delivers** the data and proof back to Quicksilver’s ICQ Module. * Quicksilver **verifies** the proof against a **trusted** header or light-client state for the remote chain, ensuring the data has not been tampered with. 5. **Callback Invocation** * Once verified, the ICQ Module **calls back** into the requesting module, which then processes the data (e.g., updating delegations, distributing rewards, or adjusting redemption rates). *** ## Why an External Relayer? * **Historical Context**\ Quicksilver’s ICQ implementation **predates** newer ICS-based query methods (sometimes referred to as “IBC-baked” queries) by approximately 18 months. * **Proven Effectiveness**\ Despite not conforming to newer ICS standards, Quicksilver’s external-relayer approach has been thoroughly **battle-tested** and **adopted** by various protocols, demonstrating its reliability and **scalability**. * **Community Collaboration**\ Multiple projects in the Cosmos ecosystem have worked to **refine** and **extend** Quicksilver’s ICQ approach, building a vibrant ecosystem of cross-chain tools around it. *** ## Merkle Tree Proofs & Cryptographic Security Although Quicksilver’s ICQ does not rely on standard IBC channels for communication, it still preserves a **trust-minimized** model via **Merkle tree proofs** (or analogous cryptographic structures): * **Consistency with Remote Consensus**\ If the remote chain attests that a given piece of data (e.g., account balance, validator performance) is included in its **state root**, that data becomes **verifiable** on Quicksilver’s side. * **No Centralized Oracles**\ Because the proof is tied to the remote chain’s **consensus** state, there is no single point of trust or third-party oracle controlling data validity. *** ## Use Cases 1. **Interchain Staking** * Retrieving **delegator balances**, **rewards**, and **slashing information** from a remote chain ensures accurate management of Quicksilver’s liquid staking positions. 2. **Participation Rewards** * Queries can verify validator performance or governance participation, enabling Quicksilver to distribute **QCK incentives** to users aligning with network goals. 3. **Governance by Proxy** * Verifying user stake or voting data on the remote chain ensures cross-chain voting power is accurately reflected within Quicksilver’s governance processes. 4. **General Cross-Module Needs** * Any module that requires **trusted** data from external chains (e.g., for bridging assets, verifying identity, or orchestrating multi-chain DeFi) can leverage Quicksilver’s ICQ approach. *** ## Future Directions * **Harmonization with Emerging Standards**\ While Quicksilver’s ICQ implementation is distinct from newer ICS query specifications, future updates may explore partial or full **integration** with standard IBC-based solutions for increased cross-chain compatibility. * **Extended Data Formats**\ As remote chains introduce more complex state structures, Quicksilver’s ICQ may expand to accommodate **advanced** or **custom** proof types. * **Further Ecosystem Adoption**\ Continued collaboration and contributions across the Cosmos community can help **refine** the external relayer approach and open up new interchain functionalities. *** ## Conclusion Quicksilver’s **original Interchain Queries (ICQ) Module**, supported by an **external relayer** mechanism, has been a **pioneering** force in cross-chain data retrieval. It provides asynchronous, **cryptographically secured** queries that enable safe and efficient **interchain** operations—from liquid staking to governance management. Though newer ICS-based solutions exist, Quicksilver’s ICQ remains a **robust**, widely adopted model, continuously **evolving** with the support of the Cosmos community. # Validator Documentation Mainnet: Testnet: # IBC Channels This page lists all the supported IBC clients, connections and channels for IBC relayers. ## stargaze-1
Typestargaze-1quicksilver-2
Client07-tendermint-22507-tendermint-0
Connectionconnection-159connection-0
Channel (transfer)channel-124channel-0
Channel (deposit)channel-126channel-3
Channel (delegate)channel-400channel-212
Channel (withdrawal)channel-129channel-4
Channel (performance)channel-130channel-5
## cosmoshub-4
Typecosmoshub-4quicksilver-2
Client07-tendermint-101807-tendermint-2
Connectionconnection-709connection-1
Channel (transfer)channel-467channel-1
Channel (deposit)channel-529channel-12
Channel (delegate)channel-1142channel-202
Channel (withdrawal)channel-531channel-13
Channel (performance)channel-896channel-194
## osmosis-1
Typeosmosis-1quicksilver-2
Client07-tendermint-240007-tendermint-6
Connectionconnection-1889connection-2
Channel (transfer)channel-522channel-2
Channel (deposit)channel-701channel-25
Channel (delegate)channel-17604channel-160
Channel (withdrawal)channel-698channel-26
Channel (performance)channel-700channel-27
## regen-1
Typeregen-1quicksilver-2
Client07-tendermint-11307-tendermint-16
Connectionconnection-102connection-9
Channel (transfer)channel-62channel-17
Channel (deposit)channel-65channel-18
Channel (delegate)channel-174channel-213
Channel (withdrawal)channel-63channel-19
Channel (performance)channel-168channel-190
## sommelier-3
Typesommelier-3quicksilver-2
Client07-tendermint-5707-tendermint-79
Connectionconnection-59connection-54
Channel (transfer)channel-59channel-101
Channel (deposit)channel-60channel-103
Channel (delegate)channel-83channel-225
Channel (withdrawal)channel-61channel-104
Channel (performance)channel-62channel-105
## juno-1
Typejuno-1quicksilver-2
Client07-tendermint-37907-tendermint-68
Connectionconnection-373connection-50
Channel (transfer)channel-272channel-86
Channel (deposit)channel-277channel-90
Channel (delegate)channel-643channel-239
Channel (withdrawal)channel-274channel-91
Channel (performance)channel-560channel-191
## dydx-mainnet-1
Typedydx-mainnet-1quicksilver-2
Client07-tendermint-2007-tendermint-90
Connectionconnection-25connection-62
Channel (transfer)channel-32channel-164
Channel (deposit)channel-33channel-165
Channel (delegate)channel-85channel-205
Channel (withdrawal)channel-34channel-166
Channel (performance)channel-36channel-167
## ssc-1
Typessc-1quicksilver-2
Client07-tendermint-807-tendermint-91
Connectionconnection-8connection-63
Channel (transfer)channel-18channel-170
Channel (deposit)channel-22channel-173
Channel (delegate)channel-34channel-224
Channel (withdrawal)channel-20channel-174
Channel (performance)channel-21channel-175
## agoric-3
Typeagoric-3quicksilver-2
Client07-tendermint-8507-tendermint-84
Connectionconnection-85connection-60
Channel (transfer)channel-68channel-125
Channel (deposit)channel-91channel-177
Channel (delegate)channel-149channel-240
Channel (withdrawal)channel-92channel-178
Channel (performance)channel-148channel-227
## celestia
Typecelestiaquicksilver-2
Client07-tendermint-9207-tendermint-97
Connectionconnection-60connection-65
Channel (transfer)channel-36channel-207
Channel (deposit)channel-41channel-208
Channel (delegate)channel-44channel-209
Channel (withdrawal)channel-42channel-210
Channel (performance)channel-43channel-211
## archway-1
Typearchway-1quicksilver-2
Client07-tendermint-10707-tendermint-93
Connectionconnection-95connection-64
Channel (transfer)channel-132channel-171
Channel (deposit)channel-197channel-214
Channel (delegate)channel-200channel-217
Channel (withdrawal)channel-198channel-215
Channel (performance)channel-199channel-216
## centauri-1
Typecentauri-1quicksilver-2
Client07-tendermint-3107-tendermint-78
Connectionconnection-16connection-53
Channel (transfer)channel-9channel-94
Channel (deposit)channel-82channel-220
Channel (delegate)channel-85channel-223
Channel (withdrawal)channel-83channel-221
Channel (performance)channel-84channel-222
## xion-mainnet-1
Typexion-mainnet-1quicksilver-2
Client07-tendermint-607-tendermint-102
Connectionconnection-7connection-67
Channel (transfer)channel-8channel-229
Channel (deposit)channel-channel-
Channel (delegate)channel-channel-
Channel (withdrawal)channel-channel-
Channel (performance)channel-channel-
## omniflixhub-1
Typeomniflixhub-1quicksilver-2
Client07-tendermint-7607-tendermint-101
Connectionconnection-57connection-66
Channel (transfer)channel-51channel-228
Channel (deposit)channel-channel-
Channel (delegate)channel-channel-
Channel (withdrawal)channel-channel-
Channel (performance)channel-channel-
## injective-1 | Type | injective-1 | quicksilver-2 | | --------------------- | ----------------- | ----------------- | | Client | 07-tendermint-282 | 07-tendermint-105 | | Connection | connection-286 | connection-68 | | Channel (transfer) | channel-394 | channel-234 | | Channel (deposit) | channel-403 | channel-235 | | Channel (withdrawal) | channel-404 | channel-236 | | Channel (performance) | channel-405 | channel-237 | | Channel (delegate) | channel-406 | channel-238 | ## umee-1 | Type | umee-1 | quicksilver-2 | | ------------------ | ----------------- | ---------------- | | Client | 07-tendermint-183 | 07-tendermint-27 | | Connection | connection-122 | connection-13 | | Channel (transfer) | channel-53 | channel-49 | ## secret-4 | Type | secret-4 | quicksilver-2 | | ------------------ | ----------------- | ---------------- | | Client | 07-tendermint-138 | 07-tendermint-28 | | Connection | connection-99 | connection-14 | | Channel (transfer) | channel-65 | channel-52 | # Testnet IBC Channels This page lists all the supported IBC clients, connections and channels for IBC relayers. ## elgafar-1 | Type | rhye-2 | elgafar-1 | | --------------------- | --------------- | ----------------- | | Client | 07-tendermint-1 | 07-tendermint-653 | | Connection | connection-1 | connection-664 | | Channel (transfer) | channel-1 | channel-700 | | Channel (deposit) | channel-25 | channel-717 | | Channel (delegate) | channel-21 | channel-708 | | Channel (withdrawal) | channel-36 | channel-751 | | Channel (performance) | channel-9 | channel-704 | ## provider
Typerhye-2provider
Client07-tendermint-007-tendermint-54
Connectionconnection-0connection-37
Channel (transfer)channel-0channel-71
Channel (deposit)channel-3channel-75
Channel (delegate)channel-28channel-78
Channel (withdrawal)channel-38channel-90
Channel (performance)channel-5channel-73
## osmo-test-5 | Type | rhye-2 | osmo-test-5 | | --------------------- | --------------- | ------------------ | | Client | 07-tendermint-9 | 07-tendermint-1853 | | Connection | connection-4 | connection-1778 | | Channel (transfer) | channel-39 | channel-5196 | | Channel (deposit) | channel-40 | channel-5199 | | Channel (delegate) | channel-43 | channel-5200 | | Channel (withdrawal) | channel-41 | channel-5197 | | Channel (performance) | channel-42 | channel-5198 | ## regen-redwood-1 | Type | rhye-2 | regen-redwood-1 | | --------------------- | --------------- | ---------------- | | Client | 07-tendermint-2 | 07-tendermint-16 | | Connection | connection-2 | connection-14 | | Channel (transfer) | channel-2 | channel-45 | | Channel (deposit) | channel-11 | channel-47 | | Channel (delegate) | channel-26 | channel-50 | | Channel (withdrawal) | channel-12 | channel-46 | | Channel (performance) | channel-29 | channel-51 | # Foundation Delegation APPLICATIONS ARE NOW OPEN - 08/12/2023 - 18/12/2023 ### Introduction to the Foundation Delegation Program The Quicksilver Foundation believes that the long-term success of the Quicksilver chain goes hand-in-hand with fostering a vibrant and resilient validator ecosystem. Validators are the backbone of the Proof-of-Stake environment and play a critical role in ensuring the performance and security of the network. The key objective of the Foundation Delegation Program is to delegate the Foundation tokens to active validators who make significant contributions to support the Quicksilver chain and ecosystem. Each iteration of the Foundation Delegation Program is considered independently of previous rounds. Delegations from previous rounds will not automatically carry over to the new period; therefore, validators who received tokens in the past must apply in this round to continue to receive delegations. Based on scoring, grantees from previous rounds may receive more or fewer tokens than before. New validators and validators who did not receive Foundation Delegations in the previous round are encouraged to apply. ***Disclaimer:*** Please be advised that all decisions made by the Quicksilver Foundation regarding the Foundation Delegation Program, including but not limited to the selection of validators, allocation of delegations, and any other related determinations, are final. These decisions are made at the sole discretion of the Quicksilver Foundation and are not subject to negotiation or appeal. By participating in the program, applicants acknowledge and accept that the Quicksilver Foundation’s decisions are conclusive and binding. The Quicksilver Foundation reserves the right to make these decisions based on its assessment criteria and organizational priorities, ensuring the best interests of the Quicksilver ecosystem. ### Guiding Principles for Our Validators 1\. Decentralization: Diversifying Data Centers and Locations In the spirit of blockchain's foundational principle, we expect our validators to actively pursue decentralization in their operations. This means avoiding concentration with specific data center providers and geographic locations. By diversifying operational infrastructure across various data centers and locations, validators contribute to the network's resilience and uphold our vision of a truly distributed blockchain ecosystem. 2\. Operations & Security: Maintaining High Standards Effective and secure operations are fundamental. Validators must ensure their configuration and architecture are robust, with server specifications that meet our high standards. Monitoring tools should be employed to maintain network health and security. Key management and security setups must be top-notch, and hosting providers should be chosen with care to ensure reliability and security. Validators are responsible for maintaining an operational environment that safeguards the network against threats and ensures continuous, stable performance. ### Prerequisites & Ongoing Requirements The following are must-have requirements in order to receive and keep a Foundation Delegation. Failing to maintain any of these requirements may result in the removal of a Foundation Delegation. * Ongoing participation in the active Quicksilver Testnet. * Maintaining commissions at or below 15%. * Cloaking of RPC endpoints (as in, RPC endpoints are not exposed to the public). * The validator’s security address on-chain is set. * After the distribution of Foundation Delegations, a validator becoming jailed will result in the removal of Foundation Delegations. A validator who received a Foundation Delegation and had it removed due to being jailed will be ineligible for the next round of Foundation Delegations. In the spirit of decentralization, the top 5 validators (thanks to self-bonded assets or delegated assets besides Foundation Delegations) will not be eligible for Foundation Delegations. ### Judgment Criteria * **Mainnet Requirement**: Validators must be actively running a validator on Quicksilver’s mainnet. This applies to validators both inside and outside the active set. * **Validator Uptime**: During Quicksilver’s evaluation period, validator uptime must be 95% or greater for those in the active set. Validators moving inside and outside the active set due to stake size will be considered on a case-by-case basis. * **Commission Rate**: Validators must have a commission rate set no higher than 15%. * **Quicksilver Ecosystem Contributions**: Active participation in governance, community and marketing contributions, business development contributions, and influencers with large communities are highly valued. Contributions made to growing the Quicksilver ecosystem, such as building, maintaining, or administering IBC relayers, public RPC nodes, testnet nodes, dashboards, explorers, developer resources, and community tools; supporting other validators; creating educational content, actively contributing to the community, etc. * **Behavioral Standards**: After securing delegation, validators must maintain compliance with the mainnet criteria (uptime, commission rate) to keep their delegation. If a validator misbehaves, becomes slashed or jailed, or is not keeping up with the mainnet parameter requirements, the Quicksilver Foundation reserves the right to undelegate previously granted stake. Additionally, if a validator operator acts in such a way that is considered by the Foundation to be against the interests of the ecosystem, the Foundation reserves the right to withdraw delegations. ### Scoring System - Ecosystem Contributions In the Quicksilver Foundation Delegation Program, we recognize the importance of validators' contributions to the Quicksilver ecosystem. To evaluate these contributions, we employ a scoring system ranging from 1 to 5 points. It's important to understand that the assessment of Quicksilver Ecosystem Contributions is inherently subjective. While we strive for objectivity and fairness, the nature of these contributions often requires a nuanced evaluation that goes beyond mere quantitative analysis. Factors such as the complexity of the contribution, the time and resources invested, and the overall enhancement to the Quicksilver ecosystem are taken into account. Contributions that demonstrate a significant positive impact, foster community growth, or enhance the network's capabilities are likely to score higher. Validators are encouraged to provide detailed information and context about their contributions to enable a comprehensive evaluation. This approach ensures that each validator's unique efforts are recognized and rewarded appropriately, fostering a vibrant and collaborative Quicksilver ecosystem.

# Audits Quicksilver’s code has been extensively audited by two security firms. Audit reports can be found in the following Repository: # Bug Bounty and reporting of issues Quicksilver recognizes the importance and value of security researchers’ efforts in improving community safety. We reward ***responsible disclosure*** of security vulnerabilities via our bug bounty program. The bug bounty program covers all the code and services associated with Quicksilver. Taking part in the Bug Bounty Program policy requires researchers to adhere the following rules: 1. Providing Quicksilver with a reasonable amount of time to fix the vulnerability prior to sharing details of the vulnerability with any other party. 2. Preserving the confidentiality and integrity of any data acquired during the security research process. 3. Not defrauding Quicksilver in the process of participating in this program. 4. Not profiting from or allowing any other party to profit from a vulnerability outside of Bug Bounty Program payouts from Quicksilver. 5. Reporting vulnerabilities with no conditions, demands, or ransom threats. 6. Complying with and passing a KYC or KYB process Social Engineering attacks are a violation of the rules of the program. ### Bug submission format Bug submission reports must be done in a secure way. We use PGP encryption to communicate with our security researchers. Before you submit a report you will need to have a PGP keypair for secure communication with Ingenuity. You can find the [Ingenuity public key on Github](https://github.com/ingenuity-build/quicksilver/blob/develop/SECURITY.md) and instructions to generate and use your keys [here](https://web.pa.msu.edu/reference/pgpdoc1.html). All submissions must be provided using the template below: **Contact information** * Email address * PGP public key **Issue Description** Add a detailed description of the issue, including but not limited to, the impact on the network or end users, the software version(s) affected, current vs. expected behaviour, likelihood of exploit, alternatives or workarounds to the vulnerability, etc. **Affected URL/Area** The affected URLs or area of the application where the issue exists. **Risk Rating** * Risk: * Difficulty to Exploit: * CVSS3 Score * Authentication The Quicksilver team will be reevaluating this after the submission of the report and the reproduction of the steps provided. **Impact** * What kind of attacker? * Do they need authentication? * Who else does it affect? **Steps to reproduce/PoC** A clear outline of the steps required to execute the payload as an attacker, this can include how to set up the payload and launch it. * Request * Response * Show, Introduce, Discuss * Screenshots If applicable, please include a list of all the prerequisites for reproducing the vulnerability (eg: software used for debugging, special node configurations, etc). **Affected Demographic/User Base** * Explain who this issue affects * Is it everyone or just a select number of users? * How can this occur? **Recommended Fix** * How do you fix the issue? * What are the recommended remediation actions required to successfully fix issue x? **References** Include additional reading for the client to further backup the issues explained or elaborate more on other potential issues chained to the one identified. **KYC / KYB requirement** Quicksilver requires KYC / KYB to be done for all researchers submitting a report and wanting a reward above a certain dollar level. The information required (photographic ID, utility bill) is assessed by a third party (Synaps). Researchers that are business entities will have to provide additional information (e.g., directors, owners). Please anticipate that Synaps might require documentation in English, or in certified translations to it. The collection and assessment of this information will be done by Synaps - Quicksilver will not have access to KYC / BYB info. ### Bug Bounty Program Rewards Above a certain dollar level, payouts are contingent on successfully passing a KYC or KYB process. Payouts will be handled by the Quicksilver team directly and are denominated in USD. However, payouts are done in QCK or USDC. Please note that this is the first iteration of the Bug Bounty Program Rewards and that it might evolve in the future - the payout ranges below are for informational purposes only. **Scope** All vulnerabilities marked in the Security Audit reports by Halborn Security and Orijtech are not eligible for rewards. Vulnerabilities associated with chains connected to quicksilver should be reported to the specific chains’ security teams. **Payout ranges** **Blockchain (quicksilverd)** Low level: Up to USD 500 Medium level : Up to USD 2,500 High level : Up to USD 20,000 Critical level : Up to USD 50,000 **Applications and websites (quicksilver webapp, icq, xcclookup, authz-pusher)** Low level: Up to USD 100 Medium level : Up to USD 500 High level : Up to USD 1,000 Critical level : Up to USD 2,500 **Other infrastructure and services** Low level: Up to USD 200 Medium level : Up to USD 1,000
# Miscellaneous Validators will be contacted for patches and hot fixes on the Mainnet Validators channel on the Quicksilver Discord Server. Node operators are also expected to ensure that `security_contact` validator field is up to date, and periodic tests will be run to ensure these addresses are reachable. # Links & Resources ## Business Development, Partnerships, Marketing & Collaborations Email with your proposal. ## Get Involved with Quicksilver * Quicksilver Liquid Staking Protocol: * Official Website: * Discord Server: * Telegram: * Medium: * Zealy Questboard: * Explorer: