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 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
  • Overview
  • Design Principles
  • Why a New L1
  • How Imua Works
  • Use Cases
  1. Imua

About

NextThe Problems

Last updated 23 days ago

Imua is the universal protocol for shared security.

Overview

Imua is the universal protocol for shared security. Implemented as a purpose-built L1 protocol for shared security, Imua aggregates economic security from multiple blockchains via re/staking, normalizes it across USD price via an enshrined price oracle, and extends it to off-chain services. This technique helps to unify fragmented liquidity across many different blockchains under a common protocol for shared security.

Design Principles

Security First

Good security starts with thoughtful design. The security of the system should be of utmost importance. Imua should prioritize safety over everything at both the protocol and governance levels. Protect the network.

Protocol Agnostic

In unity, there's strength. By being omnichain and protocol agnostic, Imua should extend an olive branch to all blockchain networks and ecosystems, embrace diversity in technology, and foster seamless cooperation and interoperability.

Trust Minimized

Decentralized trust does not always have to be trustless; but it should at least be trust minimized. No third-party trust assumptions should be introduced beyond the Imua protocol and basic cryptographic primitives, such as Zero Knowledge Proofs (ZKP).

Democratically Governed

Imua should be bootstrapped and shaped by its community. Through democratic, consensus-based governance mechanisms, every participant should have a voice in the future of Imua, ensuring adaptability and fair representation.

Permissionlessly Open

Imua should affirm an open-access ethos by allowing anyone, anywhere, to access, use, and build upon it without gatekeepers. This should foster permissionless innovation, inclusivity, and equitability.

Reasonably Decentralized

Decentralization is a progressive spectrum. Imua should be architecturally designed to be reasonably decentralized from inception. Decentralization should be an essential principle for building an open market for decentralized trust.

Modularly Pluggable

Flexibility is the foundation of resilience; hence Imua should be designed with an ever-modern, modular architecture. This should ensure constant evolution, adaptability, and an enduring relevance in the face of rapid technological change.

Why a New L1

How Imua Works

Architecture

Imua is designed with a modular architecture, incorporating a Tendermint-based Byzantine Fault Tolerant (BFT) consensus mechanism, Zero-Knowledge (ZK) light-client bridging, and a fully EVM-compatible execution environment.

This design enables the following:

  • a smooth interactions for restakers

  • a seamless integration for developers

  • a decentralized governance powered by a PoS network of validator operators

Imua introduces a universal protocol for shared security that is comprised of five different layers.

Re/stakers - Re/stakers on Imua provide economic security through various restaked collateral types. These include native tokens, liquid staking tokens (LSTs), liquidity provider (LP) tokens, and stablecoins.

Chains - Chains are Layer 1 (L1) or Layer 2 (L2) blockchain networks. Imua's omnichain design supports multiple execution environments, including UTXO, EVM, Rust, WASM, and MOVE. Client chain contracts contain vaults and controllers—endpoints deployed on each client chain where restakers perform restaking-related actions such as depositing, delegating, and withdrawing collateral. Importantly, collateral remains in the chain vaults and is self-custodied by the restaker.

Communication - The Imua communication layer serves as the messaging conduit for read / write access to the underlying chains. This layer is a modular component within Imua, which uses third-party messaging services such as LayerZero, Axelar, Chainlink, Wormhole and/or IBC. Traditionally, these are used as bridging services, but Imua uses them in a unidirectional format by writing to the underlying chains to lock, unlock and slash, and reading from the underlying chains to update state on Imua. In this sense, the messaging layer acts more like a one-way state peg, than a traditional two-way bridge, which reduces a lot of known security risks.

Coordination - The Imua coordination layer serves as the main control plane and accounting system orchestrating interactions between restakers, messaging, and services. Modules collaboratively execute the core restaking logic, which includes locking, unlocking, slashing and rewarding. A one-way state peg relays restaking actions from the client chain to Imua, which in turn responds with control actions or confirmation messages.

Services - Services on Imua can be cryptographic networks such as ZKP, FHE, MPC and TEEs that run on application specific appchains. Services can also include AVSs or rollups built on various chains.

By aggregating economic security and extending it to off-chain systems, Imua serves as a coordination engine for decentralized compute.

Use Cases

Imua's modular design makes it flexible for developers to build a wide variety of verifiable trust systems using shared security from different blockchain networks.

AI: use Imua to decentralize AI by enabling deterministic, AI networks and systems that can prove task execution, verify outputs, and coordinate activity without relying on trusted intermediaries.

Stablecoins: use Imua to build and launch stablecoins with credible financial incentives backed by shared security.

ZK: use Imua to decentralize ZK verifiers, prover networks, and aggregation layers to ensure honest computation through re/staked collateral and slashing.

Bridges: use Imua to reduce single points of failure by adding verifiable trust through re/staked collateral from multiple chains.

Oracles: use Imua to exogenously increase your security budget and protect against coordinated attacks by verifying off-chain data feeds.

RPC infrastructure: use Imua to bring on-chain verifiability to your service level agreements (SLA) and get rewarded for performance and up-time.

DeFi protocols: use Imua to build off-chain order books with on-chain verifiability making them immutable and censorship resistant to MEV attacks.

GameFi: use Imua to verifiably reward user behavior and validate game-play without having to build your game on-chain.

Imua is the result of evaluating various as to where a universal protocol for shared security should be built. Based on these trade-offs, the decision was made to create a purpose-built layer 1 blockchain optimized for shared security.

trade-offs