• Multi-party
  • Bitcoin · RGB
  • USDC · EURC · USDT

One multi-party secret. Many devices. One signed spend.

Co-sign Bitcoin and stablecoins—no shared seed.

The secret is split so no wallet holds the full key. Humans and agents co-sign under rules you set—limits, allowlists, policy checks. Enough parties must join (e.g. 2-of-3). One compromised party is never enough to move Bitcoin, USDC, EURC, or USDT.

  • Split secret · many devices
  • 2-of-3 to sign a tx
  • Agent + humans in the loop
How it works Security model Roadmap
2-of-3 · MPC Sign transaction 120 USDC · 80 EURC · XRPL
Agent proposes · parties co-sign
Account balance 2-of-3

6,156.40 USD

rhzrbb…VVdQ ↗ Synced
  • BTC native 12.000000 BTC
  • RLUSD issued · Ripple 4,820.00 RLUSD
  • USDC issued · Circle 1,250.00 USDC
  • EURC issued · Circle 820.00 EURC
  • USDT issued · Tether 640.00 USDT
Account balance 2-of-3

1,312.50 USD

rPa…9mF ↗ Synced
  • BTC native 48.200000 BTC
  • USDC issued · Circle 1,250.00 USDC
  • RLUSD issued · Ripple 0.00 RLUSD
Account balance Agent

500.00 USD

rAg…7kP ↗ Synced
  • BTC native 20.000000 BTC
  • USDC issued · Circle 500.00 USDC
  • RLUSD issued · Ripple 0.00 RLUSD

Three devices · multiparty 2-of-3 · one signed spend

ClientChrome MV3 extension
CoreRust compiled to WASM
VaultEncrypted at rest
ProxyWCA v1, no custody

01 · Why

Inspectable steps before irreversible actions.

A wallet send path includes network identity, destination, amount, fee, inputs, outputs, signing, and result state. Gandalf keeps those steps visible instead of compressing them into a single ambiguous confirm control.

01

Local signing

Seeds, passwords, and private keys stay inside the extension and Rust/WASM runtime. Only signed transactions cross the network boundary.

02

Inspectable effects

Network, destination, amount, fee, and (where applicable) inputs, outputs, and change are shown before the password is requested.

03

Distinct outcomes

Pending, confirmed, rejected, offline, and wrong-network outcomes remain separate instead of collapsing into a generic failure.

02 · How it works

Architecture and transfer path.

The browser extension owns vault state, review UI, and signing. The proxy normalizes provider APIs. Network infrastructure never receives signing material. 

Browser extension (React UI · encrypted vault · transaction review)
  └─ Rust core → WebAssembly (derive · plan · authorize · sign · zeroize)
        │  Wallet Chain API v1 — public data or signed payloads only
        ▼
Gandalf Proxy (capabilities · identity checks · adapters · broadcast · status)
        │  provider-specific APIs
        ▼
Network infrastructure (Esplora · Horizon · gateways · …)
  1. 1

    Create or import

    Create a wallet or import supported material into an encrypted local vault. Set a password and account name.

  2. 2

    Receive and prepare

    Show a receive address. For send, enter destination and amount with field-level validation.

  3. 3

    Review and sign

    Confirm network, destination, amount, fee, inputs, and outputs. Unseal only at the signing boundary in WASM.

  4. 4

    Broadcast and verify

    Submit the signed payload. Track pending, confirmed, and rejected outcomes separately.

03 · Scope

What is implemented.

Bitcoin is the immediate product focus. Catalog presence or design-system colors do not imply a live signing path. Experimental ledger adapters in the repository are not part of the current public product promise.

Area Current implementation
Vault BIP39 and supported key imports; Argon2id and XChaCha20-Poly1305 envelope with authenticated public metadata; multi-account metadata
Bitcoin BIP84/86 derivation, WIF import, P2WPKH and P2TR planning/signing; Esplora and development adapters
Client Chrome Manifest V3 popup, onboarding, account and network switching, receive and send flows, pending transaction tracking
Proxy Rust/Axum WCA v1 service: network registry, health, state, validation, broadcast, and status routes
Protocol Versioned JSON schemas, network registries, and cross-language cryptographic/transaction fixtures
In repository, not product promise Experimental adapters (for example Stellar and primary development-ledger paths) used for research and local stacks
Not complete Chrome Web Store distribution; Cardano, XRPL, and EVM-family product paths; full release-stage security review

04 · Proxy

Wallet Chain API v1.

The proxy sits outside the custody boundary. It translates upstream infrastructure into one versioned contract and never receives private signing material. Direct provider paths can remain available for debug or environment-specific use when configured.

proxy ready chain-api/v1
Contract
WCA v1
Example network
bitcoin testnet
Read
available
Broadcast
available
Signing
local only
Capability before action. The interface enables only what the selected network reports as available.

Versioned contract

Stable client edge

Wallet surfaces consume a deliberate schema instead of each provider’s private API shape. Amounts cross the API as decimal strings in the smallest unit.

No secret transit

Public data only

The proxy reads network state and submits signed payloads. It does not hold seed phrases, passwords, or private keys.

Honest failure

Reasons survive

Offline, rejected, unsupported, and wrong-network outcomes remain distinct so recovery paths can stay specific.

Local development default listen address: http://127.0.0.1:18765. A hosted production WCA endpoint is planned only after operational and privacy review.

05 · Security model

Boundaries and open work.

The extension is the trusted client boundary. The proxy, providers, and networks are untrusted inputs. The table below is the documented model, not a claim of completed independent audit.

Boundary Enforced rule
Secrets Not returned across the serialized WASM API
Vault Argon2id (65,536 KiB, 3 iterations, 1 lane); XChaCha20-Poly1305 with random salt and nonce; authenticated metadata
Authorization Each signature path decrypts again with the user password
Network Identity mismatches abort; test-family Bitcoin accounts do not default to mainnet
Extension MV3, self-hosted code, strict CSP, no content scripts, explicit host permissions
Proxy Public chain data and signed payloads only; no custody and no signing

Suspected vulnerabilities should not be filed as public issues. Use private vulnerability reporting for the repository owner until a dedicated security mailbox is published. Do not include real wallet secrets or mainnet keys in a report.

06 · Roadmap

Acceptance-driven stages.

An item is treated as done only after its acceptance tests pass. The intended first public release is a testnet-oriented build when store packaging and release checklist work are ready.

Done

Stages 0–6

Protocol fixtures, Rust core and vault, extension foundation, onboarding, read-only sync, and first end-to-end transfers on supported development and test paths.

Done (engineering)

Bitcoin + WCA path

Bitcoin crypto and send flow, WCA schema, proxy adapters, and public Bitcoin network profiles as documented in the wallet roadmap. Product messaging remains Bitcoin-first.

Open

Stages 7–10

Reliability and recovery; security and release checklist; fee-economics research; additional ledger families only when they exit experimental status; hosted production WCA after operational and privacy review.

07 · Visual system

Shared tokens, two densities.

The public website and the extension import the same design-system stylesheet. Theme (light/dark) and density (comfortable/compact) are independent. Product CSS may compose layout but must not redefine the token architecture.

Comfortable

Website composition

Wider spacing and section hierarchy for project documentation.

Compact

Application composition

Denser rows for balances, history, and signing review in the extension popup.

P Primary account 0.0342 BTC

Reference site: gandalfsystem.com.

Further reading

Related surfaces.

Design system reference and the sections above. There is no public install link while the extension remains unpacked-only.

Roadmap Security Design system