Ika Decentralized MPC Signature Network

The ika-types crate provides core cryptographic primitives used within the Ika ecosystem. Currently, the package focuses on signature and hashing functionality implemented across three primary modules:

• crypto.rs: The central library for cryptographic structs and functions, including signing, verification, and hashing.
• signature_seed.rs: Provides deterministic signer functionality using a seed, a domain, and a key identifier. This is particularly useful for custodial services where keys are derived from identifiers like usernames or email addresses rather than standard BIP44/BIP32 paths.
• messages.rs: Handles the logic for adding and verifying signatures to transactions for both account holders and validators.

For details on supported signature schemes and requirements for user and authority signatures, refer to the Sui Cryptography documentation. The underlying implementations leverage fastcrypto.

The dev-docs/ directory serves as the engineering context for both humans and AI agents. It is organized into several functional areas to help developers navigate the protocol's complexity:

• specs/: Protocol behavioral contracts. These define actors, messages, decision rules, invariants, and failure modes. Crucial: Read the relevant spec before changing any subsystem it covers.
• playbooks/: Operational guides for running, debugging, and diagnosing the system (e.g., MPC stalls, localnet setup, production alerts).
• conventions/: Repository-specific procedures and rules (e.g., naming, logging, Sui versioning, metric naming).
• learnings/: Documentation of non-obvious failure classes and pitfalls encountered during development.
• reference/: Pointers to external sources, such as the pinned Sui upstream source.
• plans/: Active implementation plans for multi-PR/multi-session efforts. Once a plan is implemented, its behavior moves to specs/ and the plan is moved to plans/archive/.
• reviews/: Point-in-time records of PR and design reviews. These are not maintained truth; for current behavior, refer to specs/.

When integrating Ika dWallet into Move smart contracts, there are two primary patterns depending on whether the contract needs to sign autonomously or manage a pool of pre-authorized signatures. Most production contracts combine these patterns to ensure continuous, automated signing capabilities.

Available Patterns

1. Shared dWallet for Smart Contracts: The contract owns a shared dWallet and controls signing through its internal business logic. This is ideal for DAOs, treasuries, or automated systems where the network can sign without direct user interaction.
2. Presign Pool Management: Since presigns are consumed upon use, this pattern involves maintaining a vector of UnverifiedPresignCap objects to ensure the contract always has available signatures for frequent operations.

Combining Patterns

Real-world implementations typically combine both patterns by storing a DWalletCap for authorization and a vector<UnverifiedPresignCap> for signature availability, alongside payment balances and network encryption keys.

Ika is a decentralized, zero-trust MPC (Multi-Party Computation) signature network. It allows developers to create protocols that operate natively across multiple blockchains (such as Bitcoin, Ethereum, and Solana) without the need for bridging, wrapping, or trusted intermediaries.

At the core of the network is the dWallet, a decentralized and programmable signing mechanism.

Key characteristics of dWallets:

• Noncollusive: A signature requires both the user's consent and a 2/3 threshold of the Ika network. No single party, including the network itself, can sign alone.
• Multi-chain: dWallets support ECDSA and EdDSA, allowing them to natively control assets and accounts on various chains (e.g., Bitcoin, Ethereum, Solana).
• Massively Decentralized: The network scales to hundreds of nodes to provide the required threshold for signing.
• Cryptographically Secure: Security is derived from cryptography rather than hardware or trust assumptions.