Target first
Fireblocks
Vault/account mapping, transaction intent, policy evidence, webhook normalization, raw payload retention, and reconciliation exports.
Product / WalletKit
Custody portability without a wallet migration project.
WalletKit gives digital asset teams one normalized operating layer across Fireblocks, BitGo, Copper, Safe/self-hosted wallets, and future providers. It is designed for teams that need a second provider, migration path, policy evidence, transaction state, reconciliation, or audit control.
In brief: WalletKit does not custody funds. It standardizes provider connections, wallet objects, address objects, transaction intent, transaction state, webhooks, policy hooks, risk hooks, reconciliation primitives, and audit evidence above the wallet layer.
How it works
One payout, one operating record
Intent — A USDC payout batch is created with customer reference, provider target, and idempotency key.
Controls — PolicyKit and RiskGuard attach limits, approval, screening, and exception context before provider submission.
Provider — Fireblocks, BitGo, Copper, or Safe-specific state stays preserved behind one Alloy transaction timeline.
Evidence — ReconFlow exports balances, fees, raw provider payloads, and audit trail for finance close.
The goal is not to hide provider differences. The goal is to keep business workflows stable when provider differences appear.
When WalletKit matters
The pain usually appears after the first wallet provider is already live.
Provider models become embedded into product, compliance, finance, support, engineering, and audit workflows. WalletKit is for teams that want control of that operating layer before provider lock-in becomes permanent.
Best trigger signals
- Adding a second custody or wallet provider.
- Preparing a provider migration or redundancy plan.
- Reconciling wallet state across chains and providers.
- Producing policy and audit evidence for transactions.
- Separating operating controls from a bundled provider.
Adapter coverage
Be explicit about what is target, validating, and later.
Credibility comes from showing the first adapter surface without implying every provider path is already complete.
Target first
BitGo
Wallet and transfer mapping, policy/approval trail capture, webhook replay, and provider-native escape hatches.
Target first
Copper
Custody and settlement-oriented workflows where provider-native settlement semantics must stay visible.
Narrow path
Safe / self-hosted
Initial EVM-oriented self-hosted path for teams that need non-custodial policy evidence and transaction state.
What WalletKit normalizes
One wallet operations model across provider-specific APIs.
Provider connections
Connect and manage provider credentials, scopes, environment state, and adapter-specific escape hatches.
Wallet and address objects
Map provider-specific vaults, accounts, wallets, addresses, assets, and chains into canonical Alloy objects.
Transaction intent
Create a provider-neutral transaction request before it becomes a provider-specific signing or transfer workflow.
State and events
Normalize created, pending, approved, signed, broadcast, confirmed, failed, canceled, and provider-specific edge states.
Policy and risk hooks
Attach ShieldOS, RiskGuard, and PolicyKit decisions before a transaction proceeds.
Reconciliation and audit
Produce evidence for finance, compliance, risk, and operations without rebuilding exports per provider.
Phase one boundary
Start with the data, control, and evidence layer.
WalletKit phase one is intentionally non-custodial. We're building the operating layer above providers first: canonical objects, transaction state, policy checks, risk evidence, event replay, reconciliation, audit evidence, and provider escape hatches.
Architecture & Replay API Proof
┌────────────────────────────────────────────────────────────────────────┐
│ CLIENT / APPLICATION LAYER │
│ Fintech Backend · AI Agents · Treasury Dashboard · Webhook Replay │
└───────────────────────────────────┬────────────────────────────────────┘
│ Unified OpenAPI v3 / REST APIs & Events
▼
┌────────────────────────────────────────────────────────────────────────┐
│ ALLOY WALLETKIT CONTROL PLANE │
│ │
│ ┌───────────────────────┐ ┌───────────────────┐ ┌──────────────────┐ │
│ │ Canonical State & │ │ Policy Engine & │ │ Deterministic │ │
│ │ Event Replay Pipeline │ │ Cryptographic │ │ Reconciliation │ │
│ │ (Transaction Model) │ │ Evidence Vault │ │ Ledger (ReconFlow)│ │
│ └───────────────────────┘ └───────────────────┘ └──────────────────┘ │
└───────────────────────────────────┬────────────────────────────────────┘
│ Zero-Key-Exposure Adapter Enclave
▼
┌────────────────────────────────────────────────────────────────────────┐
│ CONNECTED CUSTODY ENCLAVES │
│ Fireblocks MPC · Turnkey Enclaves · BitGo HSM · Self-Hosted Safe │
└────────────────────────────────────────────────────────────────────────┘
Events Replay API
POST /v1/events/replay
{
"transaction_intent_id": "txn_intent_49201",
"start_state": "provider_submitted",
"end_state": "confirmed",
"include_raw_provider_receipt": true
}Canonical transaction state
One transaction timeline above provider-native statuses.
Support, compliance, finance, and product teams should not need to learn a different lifecycle for every provider. WalletKit exposes a deterministic Alloy timeline while preserving raw provider status for diagnostics and evidence.
draft — intent created with external reference and idempotency context
policy_pending / policy_approved / policy_rejected — Alloy checks controls before provider submission
submitted / provider_pending — request is with the provider, including provider-native status detail
confirmed / failed / provider_rejected / submission_failed / cancelled — close the loop with one customer-facing model and raw evidence attached
Works with your existing stack
WalletKit is not another isolated console.
The control-plane value increases when Alloy hands clean records and evidence to the systems operators already trust. WalletKit connects downstream to payment operations, accounting, CRM, risk, and audit destinations.
Payment operations
Normalize wallet and transaction state before it reaches payout, acceptance, and treasury workflows.
Accounting and ERP
Export reconciliation-ready records instead of provider-specific CSVs and manual spreadsheet stitching.
Compliance and risk
Attach screening, approvals, policy versions, and exceptions to the same transaction record.
Support and ops
Search by customer reference, provider ID, tx hash, or wallet and see one timeline with raw evidence behind it.
Data warehouse
Push normalized events and balance views into analytics and audit destinations without rebuilding per provider.
Future AI-agent controls
Preserve the later lane for agent authority, spend controls, and auditability without making it the phase-one buying story.
Boundaries
What WalletKit does not do.
WalletKit is the control plane above wallet providers. It is not a custodian, and it is not a promise that every provider or asset can be migrated automatically on day one.
Not a custodian: Alloy does not take possession or control of customer funds.
Not a universal migration tool yet: WalletKit starts by normalizing operations and evidence, not moving all funds automatically between providers.
Not a compliance system alone: ShieldOS, RiskGuard, PolicyKit, and ReconFlow are the adjacent modules that add screening, risk, governance, and reconciliation depth.
FAQ
Common WalletKit questions.
How does WalletKit differ from Fireblocks, BitGo, or Copper?
Those platforms can be wallet or custody providers. WalletKit is the neutral operating layer above providers, so the customer owns transaction state, policy evidence, reconciliation, and migration leverage.
Why buy WalletKit before Alloy controls keys?
The first pain most operators feel is not signing itself. It is provider-specific state, policy evidence, support diagnostics, reconciliation, and audit work leaking into every internal system. WalletKit phase one addresses that operating-model debt first.
Can WalletKit support self-hosted wallets?
Yes. The initial release includes a Safe/self-hosted EVM adapter path. Broader self-custody support expands with design-partner validation.
Who should evaluate WalletKit first?
Stablecoin/payment fintechs, PSPs, brokerages, cross-border apps, and exchange-like operators with one wallet provider live and a concrete second-provider, migration, audit, or reconciliation trigger.
Design partner fit
Bring your current provider workflow. We'll map the normalized control plane.
The best first conversation is not a demo. It is a workflow inventory: provider objects, signing flow, webhooks, transaction states, policy approvals, audit evidence, reconciliation, and what breaks when a second provider enters.
Become a WalletKit design partner
Or email hello@alloy.build with your current provider, trigger, and the workflow you want to keep stable.