LogoLogo
  • Imua
    • About
  • Manifesto
    • The Problems
    • The Principles
  • Architecture
    • Imua Design Principles
    • Imua Network
    • Imua Modules
    • Client Chain Bridges
      • Trustless Verification of Client Chain State
      • Handling Race Conditions between Imua and Client Chains
    • Client Chain Contracts
  • Concepts
    • Ecosystem
      • Re/stakers
      • Operators
      • Services (AVS)
        • Service Integration with Imua
        • Service Committee
        • Service Integration Details
    • restaked Proof-of-Stake (rPOS)
    • Multi-Token Restaking
    • Multi-Chain Restaking with Trustless Bridging
    • Voting Power
    • Price Oracle
    • Flexible Integration with AVS
    • Tribe Staking
  • Governance
  • Risk Management
    • Risk Analysis
      • Risk Modeling
      • Risk Parameters
      • Crypto-Economic Risk
      • Unintended Slashing
      • Black Swan Events
    • Risk Mitigation
      • Smart Contract Simplicity
      • Audits
      • Slashing Prevention
      • Slashing Vetos
      • Insurance Pools
      • Circuit Breakers
  • Components
    • Testnet
    • Oracle Module
      • Reaching Consensus on Asset Prices
      • Penalty
      • Implementation Detail
    • Smart Contracts
    • Explorer
    • Registry
  • Validator Setup
    • Prerequisites
    • Node Install
    • Compiling Binary from Source
    • Oracle Price Feeder
    • Running the Node
    • Snapshot
    • Register Option 1 (Bootstrap)
    • Register Option 2 (Post Network Launch)
    • Deposit Tokens
    • Delegating Tokens
    • Confirm Election Status
    • Faucets
    • Managing The Validator
    • Security Best Practices
    • Risks & Mitigation
    • Participation in Governance
    • FAQs & Resources
    • Testnet v7 to v8 upgrade
  • Testnet Upgrade to v1.1.1
  • AVS Setup
    • AVS Overview
    • Prerequisites
    • Building the AVS in Imua
    • Hello-World-AVS Example
    • Becoming AVS Operator
    • AVS Register and Deploy
    • AVS Task Example
    • Enhanced and Automated Edition of hello-avs integration guide&example
  • Whitepaper (2023)
    • .pdf
  • FAQ
    • What problems is Imua solving?
    • What are the main design trade-offs that had to be made with an omnichain design?
    • Does the omnichain design imply added trust assumptions (relative to a single-chain design)?
    • What concurrency-related challenges would you face with a different design?
    • How does Imua integrate with new chains?
    • Do specific chains prove unique challenges w.r.t. integration?
    • How is the cross-chain communication is achieved?
    • What are the known attack / censorship vectors here, if any?
    • Are the restaked tokens being pooled in a centralized account?
    • Who will run the validators in the Imua network?
    • Is Imua an AVS?
    • How does Imua address the risks of overloading L1 social consensus?
    • Does the Imua queuing system raise concerns around latency?
    • What are the main benefits of an omnichain design?
Powered by GitBook
On this page
  1. Concepts
  2. Ecosystem

Re/stakers

PreviousEcosystemNextOperators

Last updated 15 days ago

Re/stakers are token holders on external client chains, who wish to engage with the Exocore network. They pledge their tokens for re/staking and earn yields. The term "re/stakers" is used because the token holders can both stake and restake dependin on the client chain. Re/stakers interact with the client chain contracts on their native chains, allowing them to use their existing accounts to initiate Imua system actions such as depositing and delegation. While re/stakers aren’t required to directly interact with the Imua network for actions like delegation, they have the option to do so if they want to avoid the costs of cross-chain messages.

The typical flow of re/staker actions involves three main steps, illustrated in Figure 2:

  1. Request – Re/stakers send requests to client chain contracts for actions like depositing, delegating, and withdrawing.

  2. Relay – A cross-chain message is relayed from the client chain to Imua network. Imua network then verifies this message and executes the corresponding updates in the Imua accounting system.

  3. Respond- A response message is dispatched back to the client chain to confirm the action, prompting the client chain to carry out follow-up procedures such as locking the tokens.

For example, when a deposit request is initiated on the client chain, the tokens will be held in pending state waiting for confirmation. After receiving the cross-chain message, the Imua accounting system will mark the tokens as deposited and ready for delegation. Afterwards, the client chain smart contracts will lock the deposited tokens upon receiving the confirmation message from Imua.

In Imua, re/stakers can perform the following actions:

1. Deposit: Re/stakers deposit their tokens into the Imua system for re/staking. Successfully deposited tokens are locked and made available for delegation. Note that tokens never leave the client chain and are not bridged nor wrapped on Imua.

2. Delegation: Re/stakers delegate their deposited tokens to certain registered operators. Delegated tokens are staked to the AVS that the operators have opted in and are subject to slashing if the operator violates the AVS’s slashing rules. Delegated tokens cannot be withdrawn.

3. Undelegation: Re/stakers undelegate their restaked tokens from operators. Undelegated tokens remain locked during an unbonding period specified by the AVS. After this unbonding period, the undelegated tokens become available for withdrawal.

4. Withdrawal: The procedure to check the eligibility of token withdrawal (i.e. not slashed or actively staked) is executed on the Imua network. If a tokens qualifies for withdrawal, the Imua system will label the token as withdrawn and dispatch a cross-chain message to the client chain, prompting it to unlock the native tokens. Once unlocked, these tokens can only be transferred to the address specified by the original restaker for best security.

Figure 2: Restaker deposit flow. Restakers deposit their tokens into client chain contracts which interact with Imua network through the trustless bridging mechanism to record the deposit within the Imua accounting system.