Core Concepts

Pre-Alpha Disclaimer: This is an early pre-alpha release for exploring the SDK and starting development only. There is no real MPC signing — all signatures are generated by a single mock signer, not a distributed network. Do not submit any real transactions for signing or rely on any security guarantees. The dWallet keys, trust model, and signing protocol are not final; do not rely on any key material until mainnet. All interfaces, APIs, and data formats are subject to change without notice. The Solana program and all on-chain data will be wiped periodically and everything will be deleted when we transition to Ika Alpha 1. This software is provided “as is” without warranty of any kind; use is entirely at your own risk and dWallet Labs assumes no liability for any damages arising from its use.

dWallet

A dWallet is a distributed signing key controlled by a Solana account. The on-chain DWallet account stores the public key, curve type, and authority. The private key never exists in one place – it is split between the user and the Ika validator network via 2PC-MPC (two-party computation with multi-party computation).

DWallet account (on Solana):
  authority(32)        -- who can approve signing
  public_key(65)       -- the dWallet's public key (padded to 65 bytes)
  public_key_len(1)    -- actual public key length (32 or 33)
  curve(1)             -- Secp256k1(0), Secp256r1(1), Curve25519(2), Ristretto(3)
  is_imported(1)       -- whether the key was imported (vs created via DKG)

A dWallet can sign transactions on any blockchain – Bitcoin, Ethereum, Solana, etc. The curve and signature algorithm determine which chains are compatible.

Authority

The authority of a dWallet controls who can approve messages for signing. It can be:

• A user wallet (direct signer) – the user calls approve_message directly
• A CPI authority PDA – a program controls the dWallet and approves messages via CPI

Transferring authority is done via the TransferOwnership instruction.

CPI Authority PDA

Every program that wants to control a dWallet derives a CPI authority PDA:

Seeds: [b"__ika_cpi_authority"]
Program: YOUR_PROGRAM_ID

When a dWallet’s authority is set to your program’s CPI authority PDA, only your program can approve messages for that dWallet. The dWallet program verifies the CPI call chain to ensure the correct program is calling.

Message Approval

A MessageApproval is a PDA that represents a request to sign a specific message. When your program calls approve_message, it creates this PDA:

MessageApproval PDA:
  Seeds: ["message_approval", dwallet_pubkey, message_hash]
  Program: DWALLET_PROGRAM_ID

Fields:
  dwallet(32)            -- the dWallet to sign with
  message_hash(32)       -- hash of the message to sign
  user_pubkey(32)        -- user's public key
  signature_scheme(1)    -- Ed25519(0), Secp256k1(1), Secp256r1(2)
  caller_program(32)     -- which program approved this
  cpi_authority(32)      -- the CPI authority PDA that signed
  status(1)              -- Pending(0) or Signed(1)
  signature_len(2)       -- length of signature bytes
  signature(128)         -- the produced signature (padded)

The Ika network monitors for new MessageApproval accounts and produces signatures for those with status = Pending.

NOA (Network Operated Authority)

The NOA is a special keypair operated by the Ika network. In the pre-alpha, this is a single mock signer. In production, the NOA’s actions are backed by MPC consensus across all validators.

The NOA:

• Initializes the dWallet program state (DWalletCoordinator, NetworkEncryptionKey)
• Commits new dWallets after DKG (CommitDWallet)
• Commits signatures after signing (CommitSignature)
• Allocates presigns

Presign

A presign is a precomputed partial signature that speeds up the signing process. Presigns are generated in advance and consumed during signing.

There are two types:

• Global presigns – can be used with any dWallet (allocated via Presign request)
• dWallet-specific presigns – bound to a specific dWallet (allocated via PresignForDWallet request)

Presigns are managed via the gRPC API and are invisible to on-chain programs.

Gas Deposit

Programs that use dWallet instructions need sufficient SOL for rent. The payer account in each instruction pays for PDA creation rent. There is no separate deposit system in the pre-alpha – standard Solana rent rules apply.

Supported Curves and Signature Algorithms

Note: In the pre-alpha mock, signature_algorithm and hash_scheme are accepted in the BCS payload but the mock ignores them — it signs directly with the raw key. The full Ika network will enforce the correct algorithm and hash scheme.

DKG (Distributed Key Generation)

DKG is the process of creating a new dWallet. The user and the Ika network jointly generate a key pair such that:

• The user holds one share of the private key
• The network collectively holds the other share
• Neither party alone can produce a signature

The on-chain flow:

1. User submits DKG request via gRPC
2. Network runs 2PC-MPC DKG protocol
3. NOA calls CommitDWallet to create the on-chain dWallet account
4. The dWallet’s authority is set to the requesting user