Address Allocation

Overview

Address Allocation chooses which destination resource will be used next. In a deterministic wallet, a service can derive public receiving addresses from an extended public key without exposing the private keys needed to spend funds.

Allocation differs from Address Assignment. Allocation reserves or selects an address from the available inventory, while assignment binds that address to a specific customer, invoice, or business record.

The allocator must operate atomically. Two simultaneous checkout requests should not receive the same address unintentionally unless deliberate reuse is part of the product. Database uniqueness and reservation status prevent concurrency errors.

Network, asset, account branch, address type, and derivation path must be stored with the allocation. An address cannot be safely interpreted without the context that determines how it is monitored and which wallet controls it.

Unused allocations need an expiry or release rule, but previously exposed addresses should not be recycled casually. A payer can retain old instructions and send later. Systems should balance inventory efficiency against late-payment and attribution risk.

Allocation should also preserve the selected Address Format so monitoring software knows how to decode the resulting destination.

Allocation services should operate independently from spending keys wherever possible. An extended public key or provider API can generate receiving destinations while private keys remain in a more protected system. This separation reduces theft risk, but exposure of extended public data can still reveal address relationships and should be protected as sensitive operational information.

Capacity planning should monitor derivation gaps, provider generation limits, and unused allocations. A sudden increase in abandoned checkouts can exhaust inventory even when no payments occur, so allocation metrics should be reviewed with reservation and assignment states.