Receiving profile and whitelist

Two related things govern where a merchant's funds can go: the receiving profile — the merchant's primary settlement wallet — and the destination whitelist — the signed set of addresses any sweep or refund is permitted to reach. The receiving profile is operational configuration; the whitelist is a cryptographic boundary fixed by the merchant's signature.

Receiving profile

A receiving profile records the merchant's primary settlement wallet for a chain: the address where approved payments are intended to settle. A merchant has exactly one active receiving profile at any time.

The history of receiving profiles is append-only. Changing the active profile selects a different recorded profile; it never edits a prior one in place. A receiving profile is operational intent — it expresses where the merchant wants funds to go. It is not proof of what is configured on-chain, and recording it does not by itself move or authorise funds.

The destination whitelist

The destination whitelist is the exhaustive set of addresses the merchant authorises as settlement and refund targets. Every sweep_to returned on an approve decision and every refund_to returned on a reject decision MUST belong to this set. A target outside the whitelist is rejected on-chain — the transfer reverts and no funds move.

The whitelist is not a database field Tekmerion can edit. It is embedded in the merchant's signed authorisation and enforced by the on-chain factory contract. Tekmerion relays; the chain decides. The whitelist must be non-empty.

The structural guarantee

The whitelist is what makes the platform safe to integrate with. Because the set of permitted destinations is fixed by the merchant's own signature and enforced on-chain, funds can only ever reach an address the merchant pre-authorised — regardless of what Tekmerion relays.

This holds even under full compromise of Tekmerion. A relay carrying a destination outside the signed whitelist is rejected on-chain; an attacker controlling the relay path cannot redirect a merchant's funds to an address the merchant never signed for. The guarantee is structural, not procedural: it does not depend on Tekmerion behaving correctly.

Changing the whitelist

The whitelist cannot be edited incrementally. Adding or removing a permitted destination requires the merchant to sign a new authorisation; the prior authorisation is superseded by the new one. Until the new signature is in place and active, the destinations that apply are those of the currently active authorisation.

The signing ceremony, the exact structure that is signed, and supersession are specified in Factory authorisation.

Relationship between the two

• The receiving profile is where the merchant intends approved funds to settle — operational, mutable through activation, owned in configuration.
• The whitelist is the boundary of where funds are permitted to go — cryptographic, fixed by signature, enforced on-chain.

A merchant's primary settlement wallet is typically a whitelisted destination, but the whitelist is the authoritative constraint. A decision is executable only when its sweep_to or refund_to is a member of the active whitelist.