I've been building out an MPC wallet specifically designed to address what I see as the biggest UX blocker in the Ark protocol — the interactivity requirement during Batch Swap rounds.
This is still a work in progress, but the core primitives are in place and I wanted to share where things stand and get your feedback on the direction.
Ark scales Bitcoin by batching user payments into Batch Outputs — single on-chain UTXOs partitioned into multiple Virtual Transaction Outputs (VTXOs). Each Batch Output is an n-of-n multisig between all VTXO owners and the Ark Operator (ASP), with two spend paths:
- Collaborative path: VTXO owner + Operator co-signature
- Unilateral exit path: owner-only withdrawal after a CSV timelock
The problem is that every Batch Output has an expiry timestamp. Before it expires, each VTXO owner must do one of the three:
- Participate in a new Batch Swap round — atomically rolling their VTXO into a fresh Batch Output,
- Perform a collaborative exit with the Ark Operator
- Perform a unilateral on-chain withdrawal
If the user does neither, the Ark Operator reclaims the Batch Output to recover their fronted liquidity. The user's VTXO gets swept.
This means users must be online and interactive at regular intervals. For a consumer wallet — where someone might not open the app for weeks — that's a fundamental problem. It effectively limits Ark to power users who are actively managing their VTXOs.
The idea behind this wallet is straightforward: what if a cosigner could handle the Batch Swap on the user's behalf while they're offline?
I have been working on a FROST (Flexible Round-Optimized Schnorr Threshold Signatures) based wallet with a 2-of-3 threshold split between the user's device, a cosigner running as a WASM component inside a secure enclave, and a recovery key. Any two of the three shares can produce a valid BIP-340 Schnorr signature — but no single party can sign alone.
When a VTXO approaches expiry, the cosigner — which is always online — would:
- Detect the approaching expiry window
- Enter the Batch Swap round with the ASP on behalf of the user
- Co-sign the forfeit transaction releasing the old VTXO using its FROST share
- Receive the refreshed VTXO in the new Batch Output
The user's funds roll forward. No app open. No interaction. No swept VTXOs.
This is the thing I keep coming back to — the cosigner cannot unilaterally move funds. It holds one share of a 2-of-3 threshold key. Spending requires any two of the three shares. The security model breaks down like this:
| Scenario | Outcome |
|---|---|
| User online, cosigner online | Normal collaborative signing — payments, batch swaps |
| User offline, cosigner online | Cosigner refreshes VTXOs autonomously — funds safe |
| User online, cosigner offline | Collaborative exit with hardware share |
The cosigner is sandboxed in per-user WASM isolation (Wasmtime). Each user gets their own memory-isolated instance — no shared state, no cross-user leakage.
┌──────────────────────────────────────────────────────┐
│ User's Device │
│ │
│ ┌─────────────┐ ┌──────────────────────────────┐ │
│ │ Client App │ │ FROST Key Share (client) │ │
│ │ (Dart) │───►│ Signs when user is active │ │
│ └─────────────┘ └──────────────────────────────┘ │
└──────────────────────────┬───────────────────────────┘
│ gRPC (authenticated)
▼
┌──────────────────────────────────────────────────────┐
│ Server (Secure Enclave) │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ WASM Sandbox (per-user instance) │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ Cosigner (FROST Key Share) │ │ │
│ │ │ - Produces signature shares │ │ │
│ │ │ - Derives VTXO script pubkeys │ │ │
│ │ │ - Computes forfeit/exit spend info │ │ │
│ │ │ - Participates in Batch Swap rounds │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────┘ │
│ │ │
│ │ │
│ │ |
└──────────────────────────────────────────────────────┘
▼
┌─────────────────────┐
│ Ark Operator / │
│ ASP Interface │
└─────────────────────┘ │\
-
Trust model — Are we comfortable with the cosigner having scoped authority to refresh VTXOs autonomously? The policy engine would strictly limit it to refresh-only signing, but I want to make sure the trust assumptions sit right.
-
Priority — The Ark liveness problem is well-known but no one seems to be solving it at the wallet layer. As far as I can tell, every existing approach either accepts the interactivity burden or falls back to full custody delegation. Is this worth prioritizing?
Would love your thoughts.