Factory authorisation

The factory authorisation is a merchant-signed EIP-712 message that scopes what Tekmerion is permitted to relay on the merchant's behalf. The merchant signs it once per chain at onboarding. The on-chain factory contract is the authoritative verifier: it recovers the signer and enforces the signed constraints at execution time. This page fixes the exact message structure, the signing procedure, and the lifecycle of an authorisation.

This page is normative. The keywords MUST, MUST NOT, REQUIRED, and OPTIONAL are used in the RFC 2119 sense.

Domain separator

The EIP-712 domain separator binds the signature to a specific factory contract on a specific chain. It MUST be constructed exactly as:

EIP712Domain {
  string  name              = "Tekmerion Factory"
  string  version           = "1"
  uint256 chainId           = <chain id of the target factory deployment>
  address verifyingContract = <factory contract address on that chain>
}

• name MUST be the literal string "Tekmerion Factory".
• version MUST be "1".
• chainId MUST equal the chain id of the factory the authorisation targets. A signature produced for one chain MUST NOT be accepted on another.
• verifyingContract MUST be the factory contract address on the target chain. This binds the signature to one factory; it MUST NOT be valid against any other contract.

Tekmerion supplies the chainId and verifyingContract for each chain you enable. Do not derive or assume them.

FactoryAuthorisation struct

The typed-data struct the merchant signs MUST be:

FactoryAuthorisation {
  address   merchant
  address[] allowed_destination_whitelist
  bytes32[] allowed_action_types
  uint256   nonce
  uint256   max_amount_per_tx
}

Action types are encoded as keccak256 of the literal token:

• deploy_sweep = keccak256("deploy_sweep")
• deploy_refund = keccak256("deploy_refund")

For full functionality, allowed_action_types SHOULD include both deploy_sweep and deploy_refund. An authorisation omitting deploy_refund cannot be used to relay a merchant-directed refund.

Signing procedure

At onboarding, per chain:

1. Obtain the chainId and factory contract address from Tekmerion.
2. Construct the domain separator exactly as specified above.
3. Construct the FactoryAuthorisation struct:
   • merchant = the merchant signing address;
   • allowed_destination_whitelist = every address you may later return as sweep_to or refund_to on this chain — non-empty;
   • allowed_action_types = at minimum {deploy_sweep, deploy_refund};
   • nonce = a value unique for this (merchant, factory);
   • max_amount_per_tx = 0 unless a per-transaction ceiling is desired.
4. Sign the EIP-712 typed-data hash with the merchant signing key.
5. Provide the signed payload and signature to Tekmerion.

The signature is the only thing that grants Tekmerion relay authority. Tekmerion cannot deploy or move funds without it, and cannot alter what was signed.

No expiry

A v1.0 factory authorisation MUST NOT carry an expiry field. There is no expires_at or valid_until in the struct, and none MUST be added.

The rationale is operational safety. A rolling expiry would require merchant-side automation to re-sign before the deadline; without it, payments would stall the moment an authorisation lapsed. Rather than introduce a silent failure mode, v1.0 authorisations do not expire. Their lifetime is bounded by explicit action only:

• the merchant revokes on-chain;
• the merchant supersedes by signing a new authorisation;
• Tekmerion operationally suspends relay for the merchant.

On-chain verification

The factory performs the definitive verification at execution time. For any relayed transaction it MUST:

1. Recompute the EIP-712 hash from the domain separator and struct.
2. Recover the signer and confirm it equals merchant.
3. Confirm the authorisation is not revoked and the nonce is not consumed.
4. Confirm the target address is a member of allowed_destination_whitelist.
5. Confirm the action type is present in allowed_action_types.

If any check fails, the transaction MUST revert: no funds move and no fee is collected. Verification is on-chain and does not depend on Tekmerion's off-chain records.

Revocation

Revocation is a merchant action performed on-chain. The merchant submits a revocation transaction directly to the factory contract; Tekmerion observes it and stops relaying for that merchant.

• Revocation takes effect on-chain. From that point, any relay the factory receives for the merchant MUST revert.
• After revocation, no relay can succeed until the merchant signs and registers a new authorisation.
• Revocation is irreversible. A revoked authorisation is never re-activated; resuming requires a new signature.

Rotation via supersession

To change the whitelist, the action types, or to migrate to a new factory version, the merchant signs a new FactoryAuthorisation with a new nonce. The new authorisation supersedes the prior one: the prior becomes superseded and the new one governs all subsequent relays.

• At most one authorisation is active per merchant at a time.
• A relay already submitted under the prior authorisation is resolved by the chain against the parameters it was signed with.
• Every relay submitted after supersession is governed by the new authorisation.

Scope rules

• One signature per (merchant, chain). Each chain you enable requires its own authorisation, bound to that chain's factory by the domain separator.
• The whitelist is mandatory and non-empty. An authorisation with an empty whitelist MUST be rejected and would be rejected on-chain.
• The signature is the sole grant of authority. Tekmerion relays signed authorisations and verifies the target against the active whitelist before submitting; the factory verifies independently on-chain. A target outside the signed whitelist cannot settle, regardless of what Tekmerion relays.

The behavioral and configuration side of the whitelist is covered in Receiving profile and whitelist.