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.
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
Fireblocks
Vault/account mapping, transaction intent, policy evidence, webhook normalization, raw payload retention, and reconciliation exports.
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.
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
Payment operations Support and ops Future AI-agent controls
Alloy WalletKit Transaction intent State and events Reconciliation and audit
PolicyKit RiskGuard ReconFlow
Fireblocks BitGo Copper Safe / self-hosted
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 based on 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.