Provider connections
Connect and manage provider credentials, scopes, environment state, and adapter-specific escape hatches.
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.
What WalletKit normalizes
One wallet operations model across provider-specific APIs.
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.
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.
Can WalletKit support self-hosted wallets?
The initial plan includes a narrow Safe/self-hosted EVM adapter path. Broader self-custody support will expand 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 will 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.
Request WalletKit access
Or email chakra@alloy.build with your current provider and migration trigger.