Custody adapter mapping
Luvion separates policy, approvals, authorization and evidence from a specific wallet or custody provider. A named integration requires a provider-specific adapter and joint validation; the generic adapter design does not imply support for every provider.
Scope the integration
Before implementation, agree on the test environment, protected accounts and assets, authorized destinations, authentication ownership, duplicate prevention, outcome reporting and evidence requirements. Exchange sanitized technical information, not production credentials.
The integration must preserve the exact approved operation from request to provider handoff. Changed bindings must fail closed, and an uncertain outcome must be reconciled before another submission is considered.
Completion is not always onchain confirmation
| Reported outcome | Meaning |
|---|---|
provider_accepted | The provider accepted the request; a chain transaction may not exist |
broadcast | A transaction was submitted; success and finality are not yet established |
confirmed | The configured successful receipt, operation binding and confirmation requirements were verified |
The generic executed state must not automatically be displayed as “confirmed onchain”. A transaction hash or provider acknowledgement alone is not sufficient evidence of chain completion.
Acceptance
A named adapter must demonstrate correct operation binding, duplicate prevention, safe handling of uncertain results and redacted evidence in its agreed sandbox. Production adds transport protection, credential lifecycle controls, monitoring, incident ownership and operational acceptance.
The full mapping worksheet, request/response schemas, error classifications and provider-specific runbook are supplied only for an approved integration scope. See Source and documentation access and Compatibility matrix.