SDKs
SDK surfaces
iOS and Android provide three coordinated surfaces: Hero for product flows, Expert for inspected execution, and Mobile Node for the local device party.
Hero surface is the default product API inside the SDK. A wallet or treasury app calls a product-level operation, follows a receipt, and persists the public result. Expert surface is the operations API inside the same SDK. It routes through domain namespaces — signatures, wallets, devices, diagnostics, policies, sync, and more — giving engineering and operations teams explicit access to every operation class.
Mobile Node is the local signer runtime used by both surfaces when one quorum participant lives on the device. It owns the platform vault, native FFI call, typed decoding, and protocol binding checks.
This documentation is organized as independent panels. Use the left navigation to open the panel you need; the page stays in place and the central reader changes content.
Runtime contract
Operation contract: act, receipt, evidence
The API surface is one operation contract. SDKs differ by ergonomics, while the lifecycle object stays stable across product, support, and audit.
policyProvider.evaluate(request) — approved or throws policyRejected
createEvmWallet / transfer (Hero) or signatures.signDigest / wallets.create / ... (Expert)
admission, peer coordination, local signer via bridge, publication gate
progress stream: scheduled → waitingForUserPresence → waitingForPeers → executed
operationId, walletId / transactionId, custody, policyReceiptId, terminalCid
The SDK shape
A complete platform SDK has one public client with two API levels and one local runtime adapter. The application chooses Hero or Expert based on workflow depth. Both levels can route through the same local signer when the device is one of the MPC parties.
A device stores one local keyshare for a key. The rest of the quorum runs on peers outside the app. Each operation carries an instance id so peers agree on the same session, participant set, digest, and derivation path.
The iOS SDK provides a Swift Hero surface, a Swift Expert surface, and a Swift actor-based Mobile Node. The Android SDK provides the same surfaces in Java/Kotlin with a JNI-backed Mobile Node. Both share a Rust node ABI, keyshare vault contract, protocol binding, receipts, errors, and evidence.
Config presets and custody
DvmOpenConfig selects the custody profile and participant topology — it is the first decision in any integration. Three factory methods cover common deployments. .duo(appGroup:) is two-party custody where the phone holds one share and a cloud co-signer holds the other: the default for self-custody mobile wallets. .embeddedWallet(appGroup:tenant:) is embedded WaaS where both the phone and a tenant cloud service hold shares. .delegatedWallet(tenant:) is pure cloud custody where the phone holds no share and all signing happens on tenant infrastructure.
The custody field in DvmOpenConfig propagates into every DvmPolicyEvaluationRequest, so the policy provider can branch on deployment model. phoneShare and embeddedWaaSPhoneShare set requireUserPresence: true on wallet creation because the phone is a key-holding party; delegatedWaaS does not. DvmTenant carries a project id, endpoint URL, and deployment kind (managed or selfHosted) — required for embeddedWallet and delegatedWallet presets, absent for duo.