Trust

Non-custodial trust, mapped for real operating review.

Alloy is control-plane software for wallet operations. Customers keep funds, keys, provider contracts, and final authorization authority while Alloy coordinates transaction state, controls, and evidence around those boundaries.

Discuss trust review View bank solution
Procurement posture: Trust starts by naming the boundary: Alloy coordinates operating evidence; custody, signing, provider access, and regulated obligations stay with the customer and approved providers.
Decision matrix

The trust model is precise about who controls what.

Operating boundary

Customer authority Provider contractsUser accessApproval policy
Alloy control plane WalletKitPolicyKitRiskGuardReconFlow
Execution boundary Custody providersCustomer key pathsNo Alloy custody
Evidence outputs ReceiptsExceptionsAudit package
Security posture

Security claims should be reviewable, not ornamental.

Least authority

APIs and agent permissions are designed around scoped actions, explicit limits, and time-bounded authority.

Fail-closed controls

Missing authorization, unsupported operation state, policy denial, or approval pause should stop the workflow with a reason-coded receipt.

Provider context preserved

Native provider IDs, statuses, and exceptions remain visible so teams can debug without losing the original source of truth.

Deployment review

Deployment language stays separate from custody claims.

Alloy-hosted control plane

Suitable for design-partner workflow mapping where customers approve provider access and review operational evidence.

Private or institution-controlled profile

For bank and enterprise conversations, the review starts with network, data, tenant, and provider-responsibility boundaries.

Customer-shaped proof only

Public trust language describes real provider or explicit no-signing control-plane profiles for external review.

Evidence ledger

Trust evidence should be generated by the workflow itself.

Policy decisions, risk outcomes, approvals, provider events, denied actions, and reconciliation exports are designed to stay attached to the operating record so customer teams can inspect what happened without reconstructing it from tickets, CSV files, or screenshots.

Evidence

Proof the buyer can inspect.

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

Non-custodial boundary No customer private keys or funds are held by Alloy; custody remains with approved providers or customer-controlled infrastructure.
Reason-coded receipts Approval, denial, unsupported operation, missing authorization, and exception states are designed to produce reviewable records.
Customer-controlled review Provider access, user authority, data retention, and deployment posture remain explicit inputs to every trust conversation.
Certification honesty Roadmap and readiness posture are stated plainly without implying certifications or production claims that are not yet validated.
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