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.

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 profiles Fireblocks targetBitGo targetCopper targetCustomer stacks
Alloy adapter layer WalletKit objectsEventsProvider statusNative IDs
Control modules PolicyKitRiskGuardReconFlowShieldOS
Evidence destinations Finance 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.

Target Fireblocks
Target BitGo
Target Copper
Validating Safe / customer stack
Planned Ledger exports

Transaction intents

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

Target Fireblocks
Target BitGo
Target Copper
Validating Customer execution path
Planned Policy / risk hooks

Webhooks and events

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

Target Provider event adapters
Target Native payload links
Target Exception reasons
Validating Retry / replay model
Planned Support timelines

Provider health and status

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

Target Status polling
Target Capability flags
Validating Failure receipts
Planned Fallback context
Planned Operator alerts

Reconciliation inputs

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

Target Balances
Target Fees
Target Confirmations
Validating Exception queues
Planned ERP / 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 labels Buyers can see what is target, validating, or planned without inferring unsupported partnerships.
Provider escape hatches Native IDs, provider status, and unsupported-operation reasons remain visible for debugging.
Downstream evidence Integrations end in policy, risk, finance, support, and audit workflows rather than raw provider data.
Non-custodial adapter posture Adapters 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.