Protocols Overview

This section covers the core protocols that power dWallet operations. Understanding these protocols is essential for building robust Move contract integrations.

Protocol Lifecycle

DKG

Create dWallet and receive DWalletCap

DWalletCap

(store permanently)

▼

PRESIGN

Pre-compute cryptographic material for signing

UnverifiedPresignCap

(store in pool)

VerifiedPresignCap

(ready to use)

▼

Signing Options

SIGN

(Direct signing)

approve_message()

request_sign()

FUTURE SIGN

(Two-phase signing)

Phase 1: Commit

Phase 2: Execute

Protocol Overview

Protocol	Purpose	When to Use
DKG	Create a new dWallet	Once per dWallet
Presigning	Pre-compute signing material	Before each signature
Signing	Create a signature immediately	Direct signing without governance
Future Signing	Create signature in two phases	Governance, multisig, delayed execution
Key Importing	Import existing private key	When migrating existing keys
Converting to Shared	Make user share public	Converting zero-trust to shared mode

Choosing Between Sign and Future Sign

Use Direct Signing When:

You need the signature immediately
No approval workflow is required
The signer has full authority

Use Future Signing When:

You need governance approval before signing
Multiple parties must approve the transaction
You want to separate commitment from execution
Building multisig or DAO treasury systems

dWallet Types

Ika supports two types of dWallets based on how user shares are handled:

User secret share is made public
Network can sign without user interaction
Best for: DAOs, treasuries, automated systems, Move contract integration

// Create shared dWallet
let (dwallet_cap, _) = coordinator.request_dwallet_dkg_with_public_user_secret_key_share(
    // ... parameters
);

User secret share remains encrypted
User must participate in every signature
Best for: Personal wallets, maximum security

// Create zero-trust dWallet
let (dwallet_cap, _) = coordinator.request_dwallet_dkg(
    // ... parameters including encrypted share
);

Converting Between Modes

You can convert a zero-trust dWallet to shared mode later using request_make_dwallet_user_secret_key_shares_public(). This is irreversible - see Converting to Shared for details.

For Move Contracts

Most Move contract integrations use shared dWallets because they allow the contract to sign without external user interaction.

Protocol Constants

These constants identify curves, algorithms, and hash schemes:

Curves

const SECP256K1: u32 = 0;  // Bitcoin, Ethereum
const SECP256R1: u32 = 1;  // WebAuthn
const ED25519: u32 = 2;    // Solana, Substrate
const RISTRETTO: u32 = 3;  // Privacy applications

Signature Algorithms

IDs are relative to the curve:

// For SECP256K1:
const ECDSA_SECP256K1: u32 = 0;
const TAPROOT: u32 = 1;
 
// For SECP256R1:
const ECDSA_SECP256R1: u32 = 0;
 
// For ED25519:
const EDDSA: u32 = 0;
 
// For RISTRETTO:
const SCHNORRKEL_SUBSTRATE: u32 = 0;

Hash Schemes

IDs are relative to the curve + signature algorithm:

// For SECP256K1 + ECDSA:
const KECCAK256: u32 = 0;  // Ethereum
const SHA256: u32 = 1;
const DOUBLE_SHA256: u32 = 2;  // Bitcoin
 
// For SECP256K1 + Taproot:
const SHA256: u32 = 0;
 
// For SECP256R1 + ECDSA:
const SHA256: u32 = 0;
 
// For ED25519 + EdDSA:
const SHA512: u32 = 0;
 
// For RISTRETTO + Schnorrkel:
const MERLIN: u32 = 0;

Example: Bitcoin Taproot Configuration

For Bitcoin Taproot signatures, use:

module my_protocol::constants;
 
/// Bitcoin uses secp256k1 curve
public macro fun curve(): u32 { 0 }
 
/// Taproot signature algorithm
public macro fun signature_algorithm(): u32 { 1 }
 
/// SHA256 hash for Taproot
public macro fun hash_scheme(): u32 { 0 }

Next Steps

Start with DKG to create your first dWallet
Learn Presigning to prepare for signatures
Choose between Signing or Future Signing based on your use case

Protocol Lifecycle

On this page