Native MPC Wallets

MPC wallet infrastructure.
Control how assets move.

Build wallet operations around distributed signing and customer authorization. Define who may request a transfer, which approvals it needs, and how your team will handle recovery—before enabling value movement on a supported network.

See how it works ↓Discuss your deployment

Network-gated · Check the exact operation and deployment.

Customer authorityWho can authorize the next move?
  1. Request
  2. Customer control
  3. Signing boundary
Illustrative workflow · availability and access controls apply
A familiar challenge

A customer needs a wallet. Your team needs to know who can use it, recover it, and authorize an operation.

A more useful way forward

Start with authority, not just an address. Evaluate the wallet lifecycle and the signing route separately.

See a practical example ↓
Why it matters

Give wallet operations clear responsibilities.

For wallet builders, treasury teams, and security architects.

Separate the roles

Customer authorization, signing participants, and validator acceptance have different responsibilities. A website login is not permission to move funds.

Make control reviewable

Evaluate which credentials, policies, and participants an operation requires—before integrating a funds-moving workflow.

Keep useful evidence

Inspect public-safe commitments and receipts without exposing signing shares, passwords, or private customer information.

Core capabilities

The capabilities behind the outcome.

Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.

  • Distributed signing

    Review how key shares and signing participants work together, rather than placing the complete signing key in one application.

  • Customer authorization

    Separate a request from the approvals and customer authority required to sign it.

  • Network and portfolio discovery

    Inspect supported token-import networks and wallet portfolio data through documented read APIs.

  • Recovery and key lifecycle

    Plan admission, key epochs, rotation, and recovery with the people responsible for each operation.

Inspect public records Review documented operations

Public records illustrate inspectable data; they are not customer results or confirmation of production activation.

How Native MPC Wallets works

From customer intent to a verifiable result.

  1. 01
    Authorize an exact operation

    Bind the customer’s approval to the wallet, network, purpose, and relevant key epoch. Apply the required device and credential checks.

  2. 02
    Coordinate admitted participants

    Only the admitted signer set may take part. The threshold protocol distributes the signing work; it does not replace customer authorization.

  3. 03
    Validate and retain the outcome

    Independent acceptance and operation-specific activation gates determine what may proceed. Retain the permitted evidence for later inspection.

Where this fits

Separate the business decision from the signing ceremony.

A treasury process needs more than a wallet address. It needs an understandable division of responsibility: who requests the action, who approves it, which participants can sign, and who reviews the resulting evidence. MPC concerns distributed signing authority; your business approval policy, network readiness, and recovery procedure still need explicit owners.

Evaluation checklist

Suggested tests—not recorded customer results. Run them only with agreed access and representative non-production data.

Discover the wallet

Expected result
Identify the wallet and its selected network. Separate a visible wallet record from operational readiness.
Evidence to retain
Wallet/network references and the readiness evidence for the exact operation.

Test access controls

Expected result
Without required authority, the operation stays unavailable or denied; a visible balance is not sufficient authority.
Evidence to retain
The denied case and the permission/readiness condition that blocked it.

Review signing & recovery

Expected result
Identify every required participant and gate before a separately authorized test.
Evidence to retain
An agreed authority/recovery map and remaining dependencies; no claim of activation from documentation alone.
Start with this guide

Plan MPC wallet authority, signing, and recovery

Build an MPC wallet authority map, verify the exact network and operation, and define signing and recovery acceptance tests before moving funds.

One useful first evaluation.

Follow the worked example, inspect the current contracts, and use the failure cases and checklist to review your own results.

Read the practical guide
Network-gated

Plan your first deployment.

The published fresh-fleet posture is staged. The architecture describes first-valid 7-of-13 signing after all-13 admission; staging alone grants neither key nor value authority. Confirm current per-network activation before a pilot.

Before your first integration

  • Identify the target network and confirm its current signing activation.
  • Assign request, approval, customer authorization, and recovery responsibilities.
  • Demonstrate denied requests and recovery before testing any enabled value movement.
Review the integration Check the API contract
Open workspace
Questions before you build

Native MPC Wallets, explained.

Does MPC replace customer approval?

No. MPC distributes cryptographic signing work. Customer credentials, operation-bound authorization, policy, and validation remain separate requirements.

Are Bitcoin, EVM, and Solana operations all enabled?

Signature-profile compatibility is not an availability promise. Check the exact network, adapter, wallet generation, and operation in the current contract and deployment evidence.

What should we test before moving funds?

Validate authorization, recovery, participant failure, activation gates, and the receipts you expect to retain. Public records complement a scoped security review; they do not replace it.

What should we agree before starting a pilot?

Use the product-specific checklist above to define scope and acceptance tests. Ask the team to confirm the deployment environment, access, supported operations, integration responsibilities, support arrangements, and commercial terms. Availability labels are not a pricing quote or a service-level commitment.

Explore the technical architecture and walkthroughs

Optional deeper reading. Demonstrations are illustrative, not live operational status or a promise of activation. Use the availability guidance above and the current API contract for integration decisions.

FRESH FLEET STAGEDFIRST VALID 7 OF 13ALL-13 ADMISSION REQUIREDKEYS + VALUE DISABLED

SECURITY IN ACTION

Eight gates.
One exact authority.

The experience stays approachable because the complexity is engineered into explicit boundaries. Select a gate to see what it gives the customer, what becomes verifiable, and what never leaves its protected domain.

EIGHT INDEPENDENT GATESNothing activates on a partial proof.
01 / 08
WHAT IT MEANS FOR YOU

Native credential.

Your Hybrid wallet begins with a device-held authorization key—not an account password stored by the platform.

PUBLICLY PROVABLE
Public-key commitment and enrollment binding
NEVER EXPOSED
Private authorization key
FAIL-CLOSED POLICYNO KEY AUTHORITY · NO WALLET ACTIVATION · NO VALUE MOVEMENT UNTIL EVERY REQUIRED BOUNDARY PASSES

THE NON-CUSTODY BOUNDARY

Security is defined by what the system cannot do.

Hybrid-Chain separates customer authorization, distributed signing, validation, settlement, and public evidence. A compromised web session, coordinator, signer, or database is not enough to move funds.

Inspect public settlement proofs
THE COMPLETE KEYDOES NOT EXIST IN ONE PLACE
×
No exportable platform key

No coordinator, API, employee, or database can retrieve a complete customer signing key.

×
No password surrender

OPAQUE proves the correct master password without transmitting it or retaining a recoverable verifier.

×
No unilateral withdrawal

Customer intent, policy, threshold participation, validator finality, and burn-before-release remain independent gates.

ONE AUTHORITY · MULTIPLE SIGNATURE PROFILES

Native first.
Cross-chain by design.

The Hybrid wallet is not a wrapper around another chain. It is a first-class public-key identity and settlement wallet that can also authorize chain-specific signatures through isolated, policy-governed adapters.

HYBRID

Native Ed25519

First-class identity, authorization, transfer, and settlement on Hybrid-Chain.

THRESHOLD-CONTROLLED
BITCOIN

secp256k1 / ECDSA

Threshold-controlled Bitcoin signatures without routing custody through another smart-contract chain.

THRESHOLD-CONTROLLED
EVM

secp256k1 / ECDSA

Ethereum and compatible network operations through separately governed chain adapters.

THRESHOLD-CONTROLLED
SOLANA

Ed25519

Solana-compatible signing from the same customer authority model and proof boundary.

THRESHOLD-CONTROLLED

External-chain availability advances separately by network, adapter audit, signer policy, reserve controls, and governance approval.

HIGH-SPEED SETTLEMENT

Move at Hybrid speed.
Touch Layer 1 only when it matters.

External assets can be observed and locked against reserve-backed Hybrid balances. Users then transfer, trade, and reserve value inside the settlement layer without waiting for an external block on every action.

01 · LAYER 1Observe & lock

Watch-only evidence and finality establish external collateral.

→
02 · HYBRIDIssue & transact

Attested balances move between native public keys at application speed.

→
03 · EXITBurn & release

Hybrid value is burned before MPC authorization releases Layer-1 funds.

FRESH-FLEET SAFETY POSTURERUNTIMES MAY BE STAGED WITHOUT KEYS OR AUTHORITY. NETWORK ACTIVATION AND EXTERNAL VALUE REMAIN SEPARATELY GATED.

WHAT IT ENABLES

Custody-grade control.
Product-grade usability.

First-class Hybrid wallets with threshold-controlled cross-chain signing. The same authority model can serve individuals, trading platforms, treasury teams, applications, and regulated operators.

01SELF-CUSTODIAL FINANCE

Give customers usable wallets while removing the single hot-key failure that traditional custody creates.

02GLOBAL SETTLEMENT

Move Hybrid-native value between public wallet keys at application speed, then settle external rails only when required.

03INSTITUTIONAL TREASURY

Replace one administrator or signing appliance with policy-bound, threshold-authorized operating control.

04TRADING & EXCHANGES

Reserve balances and authorize high-frequency internal settlement without waiting for an external block on every action.

05EMBEDDED WALLETS

Bring the native authorization flow into a browser, mobile app, device, or white-label financial product.

06AUDITABLE CUSTODY

Prove who authorized, which signer set participated, and what validators accepted—without publishing secret material.

DESIGNED TO EVOLVE

From a retired pilot
to globally distributed authority.

The historical 3-of-5 pilot is closed and its keys are never reused. The fresh topology requires all 13 AWS, GCP, and Azure hosts to pass installation and admission before three isolated network enrollments can be created; later signing uses whichever seven valid participants respond first.

RETIREDHISTORICAL PILOT · 3 OF 5

Evidence remains auditable, but enrollment, signing, broadcast, and key reuse are permanently closed.

STAGEDMULTI-CLOUD FLEET · 13 HOSTS

Immutable non-starting runtimes are admitted only by complete all-13 evidence; staging grants no key or value authority.

ACTIVATEDEVNET · TESTNET · MAINNET

Separate generations, DKG results, keys, balances, capabilities, and evidence prevent any network context from crossing another.

FIT · READINESS · NEXT STEP

Is this the right MPC wallet infrastructure?

Align the evaluation with your launch requirements before choosing an integration path.

For treasury and platform teams

Evaluate Hybrid-native wallet authorization when policy ownership, signing participants, and public evidence must be reviewed together. Start with one concrete operation and its exact network.

For security and implementation teams

Request an authority map covering customer credentials, signer operators, admission gates, recovery, and validator acceptance. Inspect public records alongside the implemented API contracts.

Before a funds-moving pilot

Confirm activation, supported operations, recovery procedures, and acceptance criteria for your deployment. The published fresh-fleet posture remains staged; architecture alone does not enable key or value authority.

DOCUMENTED WORKFLOW · CHECK THE BOUNDARIES

From wallet discovery to verifiable evidence.

These are integration walkthroughs based on published contracts, not customer case studies or live execution results. Confirm scopes, network readiness, and deployment availability before use.

  1. Discover the supported import networks

    Read the authoritative network catalog before choosing a contract asset. Bind its address to the selected network; never guess a default chain.

    GET /api/v2/wallets/token-import-networksNetwork discovery contract

  2. Read the scoped portfolio

    Inspect the portfolio through its documented owner and workspace context. Portfolio metadata does not create a chain wallet or enable signing, withdrawals, or value movement.

    GET /api/v2/wallets/portfolioPortfolio read contract

  3. Inspect the evidence separately

    Compare public commitments and lifecycle state in the selected network. A directory entry or completed historical ceremony does not establish current signing authority.

    Public wallet lifecycle evidence Public ceremony evidence

EVALUATE · INTEGRATE · VERIFY

MPC wallet infrastructure
Questions worth asking.

Connect the product architecture to its current API contract and the evidence your team can inspect.

What is MPC wallet infrastructure?

MPC wallet infrastructure coordinates distributed signing participants alongside wallet creation, authorization, policy, and recovery. A threshold of participants contributes to signing; the surrounding controls determine who may request and approve each operation.

Which networks can I use?

Check the current wallet module and network evidence for your exact deployment. Signature profiles describe cryptographic compatibility. They do not mean deposits, signing, or withdrawals are enabled on every compatible chain.

How do I evaluate recovery and proof?

Ask which credentials and participants are required to recover access, who can change policy, and what happens during a provider outage. Inspect the wallet and settlement records for the operation you are evaluating. Public records complement, but do not replace, a scoped security audit.

Start with one useful result

Your evaluation should produce…

An operation-specific authority map, tested readiness and denied-access cases, and an agreed signing/recovery evaluation with unresolved dependencies made visible.

Suggested evaluation goals—not a pre-packaged service commitment. Agree access, scope, and responsibilities with the team.

Discuss your deployment
Build the next part of your workflow

Connected products.

Start with Native MPC Wallets. Review these adjacent capabilities when your requirements call for them.

Plan your integration Discuss a scoped pilot All products