Trust and security model

Tekmerion is non-custodial. It never holds a key that can move merchant or customer funds. Authority to move funds originates from a merchant signature; the blockchain verifies that signature and executes the transfer. Tekmerion relays signed instructions — it does not originate them.

This shifts the basis of trust. Security does not rest on Tekmerion behaving correctly. It rests on a clear division of key material between the merchant and Tekmerion, and on guarantees the blockchain enforces independently of either party. The most important of those guarantees holds even if Tekmerion is fully compromised.

The division of responsibility

Each party holds distinct key material and is accountable for protecting it. Neither party's material can substitute for the other's.

What the merchant protects

The authorisation signing key. At onboarding the merchant signs an EIP-712 authorisation that scopes what Tekmerion is permitted to relay on the merchant's behalf. The key that produces that signature is held by the merchant and is never shared with Tekmerion. It is the merchant's most sensitive material: it is the sole origin of authority to move funds. Its compromise is bounded — see the destination whitelist below — but it must be protected as the root of payment authority.

Webhook signing secrets. Every notification Tekmerion sends is signed with a per-endpoint secret. The receiving endpoint verifies the v1=<hex> signature before trusting the payload. The secret is shared between Tekmerion and the merchant endpoint; the merchant protects its copy and rejects any notification that does not verify. Verification is mandatory — an unsigned or unverifiable notification carries no authority. See Signature verification.

API keys. Authenticated access to the merchant API surface is granted by an API key. The merchant protects it and rotates it on suspicion of exposure. See Authentication.

KYT endpoint availability. The transaction-level decision — approve, reject, or hold — belongs to the merchant and is delivered through the merchant's KYT endpoint. Tekmerion has no authority to make or override that decision. Keeping the endpoint reachable, and signing its responses, is the merchant's responsibility; an unreachable endpoint resolves under the merchant's configured timeout policy. See the KYT webhook overview.

What Tekmerion protects

The relay path. Tekmerion operates the path that submits merchant-signed authorisations to the chain. This path carries no key capable of moving funds: it can submit only what the merchant has already signed, and the blockchain rejects anything else. Its integrity matters for liveness and correctness, not for custody.

The Proof-of-Payment signing key. Tekmerion signs each Proof-of-Payment artifact with an ES256 key whose private half never leaves Tekmerion's custody. The corresponding public key is published for verifiers, identified by a kid of the form pop-signing-v{N}. This key authenticates the proof artifact; it has no power over funds. See Signing and key discovery.

The destination whitelist is a structural guarantee

The merchant's signed authorisation embeds a mandatory, non-empty set of allowed destination addresses. Every sweep and every refund must target an address in that set. This set is enforced on-chain at execution time: a relayed transaction whose destination is outside the signed set is rejected by the contract, no funds move, and no fee is taken.

This is a structural guarantee, not a policy promise. A policy promise would depend on Tekmerion choosing to honour it. The whitelist instead depends on the blockchain verifying the merchant's signature and the signed destination set on every execution. The boundary is enforced by the chain, not by Tekmerion's good behaviour.

The consequence is the central security property of the platform: even a full compromise of Tekmerion cannot move funds to an address the merchant did not sign. A compromised relay path can, at most, relay a transfer to a destination already in the merchant's own signed set — it cannot redirect funds elsewhere, because the chain rejects any other destination. Tekmerion cannot forge the authorisation, because it does not hold the signing key, and it cannot widen the set, because the set is part of the signed, verified message.

The signature is additionally bound to a specific contract on a specific chain, so an authorisation captured on one chain cannot be replayed on another, and a per-authorisation nonce prevents resubmission of a consumed authorisation.

Revocation and rotation

Every piece of key material has a path to withdrawal that does not depend on the other party's cooperation.

Authorisation revocation is on-chain and merchant-driven. The merchant revokes their authorisation by a direct on-chain action. Revocation is enforced by the chain: from that point no relay can succeed for that merchant, regardless of what Tekmerion attempts, until a new authorisation is signed. The authorisation does not expire on its own — its lifetime ends only by merchant revocation or by the merchant signing a replacement authorisation, which supersedes the prior one. See Factory authorisation.

Secrets are rotated by regeneration. Webhook signing secrets and API keys are rotated by generating a new value, which immediately invalidates the prior one; at most one is active per scope at a time. Newly executed requests — including retries — are signed with the currently active secret, so a rotated secret must not be cached after rotation. See Secret rotation.

The Proof-of-Payment signing key has two distinct withdrawal paths. Orderly rotation publishes a new signing key and moves new signing to it while retaining the prior public key, so artifacts already signed remain verifiable indefinitely. Emergency revocation, used only on suspected key compromise, withdraws the affected key from the public discovery surface; artifacts signed by it become unverifiable from that point. The unverifiability is the intended security signal. It does not alter payment truth: the blockchain remains the source of truth for whether a payment occurred, and only the proof artifact's signature is affected. See Signing and key discovery.

What a compromise cannot reach

The trust model is bounded by what each compromise can and cannot affect:

• A compromised relay path cannot move funds outside the merchant's signed destination set, and cannot forge or widen an authorisation.
• A compromised Proof-of-Payment signing key cannot alter the underlying payment outcome; it can only render proof artifacts unverifiable, which is detectable and recoverable by rotation.
• A leaked webhook signing secret or API key is contained by rotation and does not extend to fund-movement authority, which lives only with the merchant's authorisation signing key.
• Loss of the merchant's KYT endpoint suspends decisions under the merchant's timeout policy; it does not transfer decision authority to Tekmerion.

No single compromise, on either side, yields the ability to move funds to an unauthorised destination. That property is held by the chain, not by trust in Tekmerion.