Payment Address Pool

Overview

An Payment Address Pool holds prepared receiving destinations for later Address Allocation. The inventory can be derived from an HD wallet, provisioned by a custodian, or generated through a payment-provider API.

Pool records need more than an address string. They should include network, asset scope, derivation path or provider identifier, creation time, monitoring status, and the wallet or account that controls the funds.

Concurrency controls prevent two workers from reserving the same address. A checkout can first create an Address Reservation and then finalize assignment when the payment session is committed.

Previously displayed addresses should not automatically return to the unused pool. A customer can save an old destination and pay later, creating attribution risk if the address is reassigned.

Pool health metrics include remaining available addresses, reservation age, unused assignments, monitoring coverage, derivation gap, and revocation rate. An exhausted or unsynchronized pool should fail payment creation safely rather than reuse uncertain destinations.

Payment Address Pools also need disaster-recovery procedures. A restored database must recover derivation indexes and assignment state before new addresses are issued, or it can unknowingly reuse an exposed destination. Periodic reconciliation between the pool, wallet derivation path, provider records, and blockchain activity helps detect missing rows or monitoring gaps before funds arrive.

Pool entries should be reconciled after wallet restoration, provider migration, or network upgrade. A destination considered unused internally may already appear in external logs or customer records and should not be recycled without investigation.

Pool access should be role-restricted because visibility into unused and assigned destinations can reveal customer relationships and future receiving activity.