mpckit

name: mpckit description: Build with the MPCKit SDKs (@mpckit/sdk for TypeScript, @mpckit/react for React + TanStack Query, and the mpckit crate for Rust). Use when integrating MPCKit hosted MPC signing, onboarding dWallets, producing signatures across Bitcoin / Ethereum / Solana / Sui, or wiring billing and introspection from any of those three languages. Triggers on tasks involving @mpckit/sdk, @mpckit/react, the mpckit Rust crate, the MPCKit class, MPCKit::builder, useMPCKit, useOnboard, useSign, useDWallets, the OnboardArgs / SignArgs types, MPCKit API keys, or the api.mpckit.xyz / api.testnet.mpckit.xyz endpoints. Use when this capability is needed. metadata: author: Iamknownasfesal

MPCKit

Build cross-chain signing applications against the MPCKit hosted MPC API. One backend handles every chain that ECDSA secp256k1 / Taproot, Ed25519, ECDSA P-256, or Schnorrkel covers. Three SDKs are first-party.

When to use

• Calling api.mpckit.xyz or api.testnet.mpckit.xyz from any language with a published SDK.
• Onboarding a zero-trust dWallet end-to-end (DKG + accept-share) from a 32-byte seed.
• Signing a message with api.sign(...) (TypeScript / Rust) or useSign() (React).
• Reading health, network, protocol-parameters, billing, or dWallet state.
• Picking the right SDK for a given app shape (Node service, browser, native binary, React UI).

When NOT to use

• Self-hosting the backend. That lives in apps/backend; consult apps/docs/content/docs/self-hosting/**.
• Direct upstream @ika.xyz/sdk work. MPCKit re-implements the public surface so consumers never take a transitive @ika.xyz/sdk dependency. If the task is about Sui PTBs, Ika coordinator objects, or IkaTransaction, use the ika-sdk skill instead, not this one.
• Bitcoin / Solana / Ethereum transaction assembly. MPCKit produces the raw signature only; broadcasting it to the destination chain is the consumer's responsibility.
• Move contract authoring against mpckitcore. That is a Move package under packages/mpckitcore_move; use the ika-move skill.

Pick by language

The Rust crate ships with default = [] features (HTTP only). Add features = ["crypto"] to opt into the high-level onboard / sign ceremonies. Without the crypto feature the crate exposes only sign_prepare + sign_submit and expects the caller to drive the WASM-equivalent centralized signature themselves.

Hosts and API keys

API keys are scoped per network. The base URL is auto-derived from the Network enum value if you do not pass baseUrl / .base_url(...); override only for self-hosted backends or local development.

Sign-up at https://app.mpckit.xyz to issue keys.

Install

At a glance

import { MPCKit, Curve, Hash, SignatureAlgorithm } from "@mpckit/sdk";
import { randomBytes } from "node:crypto";

const api = new MPCKit({
  apiKey: process.env.MPCKIT_API_KEY!,
  network: "testnet",
});

const seed = randomBytes(32);
const { dwallet, userSecretKeyShareHex } = await api.onboard({
  seed,
  curve: Curve.SECP256K1,
});

const { signature } = await api.sign({
  seed,
  dwalletId: dwallet.id,
  curve: Curve.SECP256K1,
  signatureAlgorithm: SignatureAlgorithm.ECDSASecp256k1,
  hashScheme: Hash.SHA256,
  message: new TextEncoder().encode("hello mpckit"),
  userSecretKeyShareHex,
});

The seed is the only thing you must safeguard between onboard and sign. Anything that derives 32 bytes deterministically works: a passkey PRF output, an env-stored secret, a KMS-released key. The userSecretKeyShareHex returned from onboard() is the encrypted user share; persist it next to the dWallet record so future signs can recover it from your DB.

Crypto constants

Curves, signature algorithms, and hash schemes are string enums in TypeScript and numeric enums in Rust. Valid combinations:

Passing an invalid (curve, signatureAlgorithm, hashScheme) triple is rejected by the backend before any crypto runs; the error surfaces as MPCKitError with a clear message, not a thrown WASM panic.

References (load on demand)

Quick decision flow

1. What language are you in? Pick the SDK from the table above.
2. Do you have an API key? If not, sign up at app.mpckit.xyz and grab one for the right network.
3. Server-only or browser? Server / Node: default InlineCryptoEngine is fine. Browser: WebWorkerCryptoEngine (TS) or useWorker: true on MPCKitProvider (React). Otherwise the WASM-heavy DKG blocks the main thread for several seconds.
4. Need a stable signing identity across reloads? Persist the seed somewhere durable (passkey PRF, OS keychain, KMS). onboard() returns userSecretKeyShareHex and userPublicOutputHex; persist both alongside dwallet.id.
5. Onboard once, sign many. Onboard produces a dWallet. Each subsequent sign() is one HTTP roundtrip plus the centralized-signature math. There is no per-request presign management for the consumer; the backend warms a presign pool.

Common mistakes

Build verification

After integrating, check that:

• health() / health()-equivalent returns { ok: true } against the right base URL.
• networkInfo() reports the network you expected.
• balance() is non-zero (deposit if needed; see references/flows.md).
• A small SECP256K1 + ECDSASecp256k1 + SHA256 sign round-trips, returning 65 bytes and a non-null signature.

If sign() returns but signature is zero-length, the dWallet was not yet Active; that means onboard() did not wait for acceptUserShare. Re-run onboard or call getDwallet() until state.kind === "Active" before signing.

Source: Iamknownasfesal/mpckit — distributed by TomeVault.