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

Voting Power

PreviousMulti-Chain Restaking with Trustless BridgingNextPrice Oracle

Last updated 15 days ago

In traditional single-token staking schemes, such as ATOM staking in the Cosmos hub, the voting power of stakers is determined based solely on the sheer number of tokens they’ve staked. This model is effective because each staked token is homogeneous, holding the same value. The actual value of the token becomes irrelevant as it’s cancelled out during the voting power calculation.

However, in the multi-token re/staking model offered by Imua, the actual values of the different types of tokens become important. For the same unit of token, tokens with a higher value per unit incur a higher cost of attack. Therefore, voting power calculations should be based on the actual value of the re/staked tokens rather than just their quantity. In Imua, the voting power is determined as the fraction of value that this operator holds with respect to the entire pool of value in Imua.

Namely, in an AVS with n types of tokens re/staked, the voting power of an operator is:

where count-i is the number of tokens of type i that this operator has re/staked (which could be zero), value-i is the value of a token of type i, and total_count-i is the total number of tokens of type i re/staked across all the operators in the AVS.

For instance, consider an operator who has re/staked 5 ETH and 1,000 ATOM in an AVS. Let’s assume the AVS currently has a total of 50 ETH and 50,000 ATOM re/staked. If the current price of ETH is $1600 and ATOM is priced at $10, then the voting power of the operator is:

Based on the real value of the re/staked tokens, the operator’s voting power for the AVS would be 3.1%. With this approach, the token’s real value plays an important role in determining how much voting power it represents.