How it works

Tekmerion's payment model rests on three mechanical facts: every payment resolves to a deterministic address computed before any contract exists there; settlement executes through a one-shot proxy that deploys, transfers, and self-destructs in a single transaction; and the constraints that bound what Tekmerion can relay are enforced on-chain, not by Tekmerion's behaviour.

The deterministic deposit address

Each payment intent is bound to exactly one deposit address, computed at creation using CREATE2. The address is a function of the intent's identity — the Factory contract address, a salt derived from the payment_intent_id, and the proxy bytecode hash. It depends on nothing else.

This has two consequences that shape the entire model:

The address is known before any contract exists at it. The deposit address can be shown to a customer the moment an intent is created. Nothing is deployed at that address until the moment of settlement or refund; the address is effectively empty until then.

The address is stable across all attempts under the same intent. Whether the customer changes their mind about chain or token, returns to pay later, or sends from a different wallet — every attempt under the same intent resolves to the same deposit address. The address is an identity property of the intent, not of any particular attempt within it.

The deposit address is the primary on-chain correlation anchor. A deposit is matched to an intent by the triple of deposit address, chain, and token — not by amount, not by calldata, and not by timing. See IDs and correlation.

The one-shot proxy

No contract code lives at the deposit address before settlement. When a final compliance decision arrives and execution begins, the following happens in one on-chain transaction:

1. The proxy contract is deployed at the deposit address via CREATE2.
2. The proxy transfers the deposited balance — net of the protocol fee — to the merchant-approved destination.
3. The protocol fee is collected to a protocol-controlled Locker in the same transaction.
4. The proxy self-destructs.

After execution, the deposit address carries no code and no balance. The proxy existed for one block and one purpose.

Tekmerion relays; the chain executes. Tekmerion submits a merchant-signed EIP-712 authorisation to the Factory contract, which verifies the signature and the destination address against the merchant's signed whitelist before triggering the proxy. Execution is the chain's, governed by the merchant's own signature. The protocol fee is collected on-chain in the same transaction that moves the funds — there is no off-chain invoice and no separate settlement step. See Fees.

Both the sweep path (merchant approve) and the refund path (merchant reject) use the same one-shot proxy mechanism. The only difference is the destination: sweep_to on approve, refund_to on reject. See Sweep and refund.

What Tekmerion structurally cannot do

The constraints on Tekmerion's authority are structural — enforced by the blockchain and the cryptography of the signature scheme, not by Tekmerion's policies or internal behaviour. Each of the following is a consequence of that structure.

Cannot move funds to a destination outside the merchant's signed whitelist. The whitelist is embedded in the merchant's EIP-712 authorisation and is part of the signed, verified message. The Factory verifies it on-chain at execution: a relayed transaction whose destination is not in the signed set reverts, no funds move, and no fee is taken. Tekmerion cannot widen the whitelist, because it does not hold the merchant's signing key. See Factory authorisation.

Cannot forge the merchant's authorisation. Tekmerion relays authorisations; it does not originate them. Tekmerion does not hold the merchant's signing key. A relay requires a valid EIP-712 signature from that key — without it, the Factory rejects the transaction. This property holds even under full compromise of Tekmerion's relay infrastructure.

Cannot override the merchant's KYT decision. The transaction-level approve, reject, or hold decision belongs to the merchant and is delivered through the merchant's KYT endpoint. Tekmerion has no path to execute a transfer without that decision, and no mechanism to substitute its own. See Compliance pipeline.

Cannot initiate a refund without a merchant-supplied destination. A refund requires a refund_to address returned by the merchant on a reject decision. Tekmerion does not choose refund destinations and has no auto-refund path. Sanctions holds — where the merchant's KYT decision does not apply because funds cannot be returned to a sanctioned address — require a merchant-supplied destination provided through the response channel under operational review.

Cannot replay an authorisation across chains. Each authorisation is bound by the EIP-712 domain separator to a specific Factory contract address on a specific chain. A signature produced for one chain is cryptographically invalid on every other.

Cannot settle an intent more than once. If more than one finalized deposit is matched to the same intent, winner selection is deterministic — given the same set of payments, the same winner is always chosen on replay. A losing payment is recorded as duplicate_payment and is not an additional settlement of that intent.