Address Assignment

Overview

Address Assignment creates the business relationship between an on-chain destination and an internal record. The address can come from Address Allocation, a provider-generated static address, or a manually registered wallet.

Assignment differs from Address Attribution. Assignment is the system’s planned binding before payment, while attribution is the later evidentiary conclusion that an observed transaction belongs to a particular record or party.

The assignment should include exact chain and asset context. An EVM address assigned for one network should not automatically cause payments on every compatible chain to be credited to the same customer.

Reassignment is dangerous because old payers can continue using previously displayed instructions. If reuse is unavoidable, the system needs a cooling period, transaction-history check, and exception process for late transfers.

Audit records should preserve who or which service created the assignment, its source address pool or derivation path, related order or customer, and every later state change. This history supports reliable Transaction Attribution and dispute investigation.

Assignment changes should be event-driven rather than direct record replacement. A history of assigned, exposed, used, revoked, and superseded states allows the monitor to interpret late transfers correctly. If a customer account is closed, the address can stop being displayed while remaining associated with that customer for any future exception handling.

Support interfaces should show the full assignment timeline and should prevent staff from changing the owner with a simple text edit. Reassignment should require a controlled workflow that evaluates prior exposure and any observed transactions.

Automated tests should cover late payment after deactivation, customer reassignment attempts, and cross-network lookups so the historical binding remains authoritative.