Integrations

Adapter credibility without pretending every provider is the same.

Alloy’s integration story is provider-neutral and capability-led: normalize wallet providers, preserve native escape hatches, and route downstream evidence into finance, risk, compliance, and support workflows.

Request an adapterExplore WalletKit
Status language: Target, validating, and planned labels show the intended adapter architecture without implying partnerships or externally validated availability.
Decision matrix

Coverage is described by capability, not by invented partnership claims.

Operating boundary

Provider profilesFireblocks targetBitGo targetCopper targetCustomer stacks
Alloy adapter layerWalletKit objectsEventsProvider statusNative IDs
Control modulesPolicyKitRiskGuardReconFlowShieldOS
Evidence destinationsFinance closeCompliance reviewSupport timeline
Capability matrix

What each adapter has to prove.

Capability labels make provider coverage inspectable without turning the page into a logo wall.

Wallet and address inventory

List, tag, and reconcile provider wallet objects while preserving provider-native IDs.

TargetFireblocks
TargetBitGo
TargetCopper
ValidatingSafe / customer stack
PlannedLedger exports

Transaction intents

Submit normalized intent records, attach business references, and keep provider submission state visible.

TargetFireblocks
TargetBitGo
TargetCopper
ValidatingCustomer execution path
PlannedPolicy / risk hooks

Webhooks and events

Normalize provider event payloads into status changes that humans, services, and agents can consume.

TargetProvider event adapters
TargetNative payload links
TargetException reasons
ValidatingRetry / replay model
PlannedSupport timelines

Provider health and status

Expose availability, degraded capability, unsupported operation, approval pause, and provider-specific constraints.

TargetStatus polling
TargetCapability flags
ValidatingFailure receipts
PlannedFallback context
PlannedOperator alerts

Reconciliation inputs

Carry wallet balances, transfers, fees, confirmations, provider deltas, and exception state toward finance close.

TargetBalances
TargetFees
TargetConfirmations
ValidatingException queues
PlannedERP / accounting
Lifecycle

Adapters should expose what they can and cannot do.

Connect

Register provider profile, credentials boundary, supported objects, webhook endpoints, and native identifiers.

Normalize

Translate provider-specific wallet, address, transfer, event, and status fields into canonical operating records.

Route evidence

Attach policy, risk, reconciliation, support, and audit context before the workflow leaves the control plane.

Evidence

Proof the buyer can inspect.

Every route keeps Alloy's public story grounded in operating records, custody boundaries, and right-sized modules.

Capability-level labelsBuyers can see what is target, validating, or planned without inferring unsupported partnerships.
Provider escape hatchesNative IDs, provider status, and unsupported-operation reasons remain visible for debugging.
Downstream evidenceIntegrations end in policy, risk, finance, support, and audit workflows rather than raw provider data.
Non-custodial adapter postureAdapters coordinate operating state while custody and signing remain with providers or customer-controlled stacks.
Next step

Bring your current provider stack.

We will map the first workflow Alloy should stabilize, the custody boundary, and the modules that create evidence.

Join design partners

Prefer email? hello@alloy.build