EIP-712 Signing

CRE Connect authorizes every Operation with an EIP-712 typed-data signature. The signature is verified on-chain by the Smart Account before any transaction in the Operation runs. EIP-712 was chosen so that a wallet UI — or a key-management operator inspecting a payload — can render a human-readable approval prompt instead of an opaque hash.

Domain

CRE Connect uses a fixed EIP-712 domain to identify "this is a CRE Connect Smart Account Operation":

Domain fieldValue
nameCLLSmartAccount
version1
chainIdThe numeric chain ID of the chain on which the Smart Account is deployed.
verifyingContractThe Smart Account address — the wallet that will execute the Operation.

Because verifyingContract is the Smart Account itself, two wallets on the same chain produce different domain hashes — a signature for wallet A is unusable on wallet B even if both contracts speak the same protocol. This is what makes the EIP-712 binding per-account.

Typed-data schema

The primary type is Operation. It references one dependent type, Transaction:

Operation {
    id          uint256
    account     address
    deadline    uint256
    transactions Transaction[]
}

Transaction {
    to    address
    value uint256
    data  bytes
}

These are the same fields documented in Operations. The signature is a standard EIP-712 digest over this typed structure and the domain — bit-for-bit compatible with any EIP-712 implementation in Solidity, Ethers, viem, or rust-ethereum.

Hashing pipeline

The application supplies the Operation; CRE Connect builds the typed-data payload, computes the digest, and asks the configured signer to sign it. Signing is a 32-bytes-in, 65-bytes-out operation — the signer never has to understand CRE Connect's domain or types.

Signers

A signer is anything that can produce an ECDSA signature over a 32-byte hash. CRE Connect supports several common key-management options at launch:

AdapterNotes
Local (ECDSA)In-process key. Recommended for local development only.
AWS KMSKMS-managed secp256k1 key.
HashiCorp VaultVault Transit secrets engine, ECDSA secp256k1 key.
FireblocksHosted custody with optional human approval workflow.
PrivyPrivy embedded wallet via REST.
CustomAny implementation that signs a 32-byte hash.

Some signer adapters can also render the EIP-712 typed data directly to a human approver, which makes the contents of the Operation human-readable in the approval UI rather than displaying an opaque hash.

Authorization vs execution

EIP-712 signing only authorizes the Operation. It does not pay gas, and it does not put the Operation on-chain by itself. Execution still goes through the Chainlink DON, which signs and broadcasts the underlying transaction on the Smart Account's behalf (see Account Abstraction & Gas Sponsorship).

This separation has two practical consequences:

  1. The signing key never holds gas. A KMS- or Vault-managed key with no on-chain presence is sufficient.
  2. The on-chain tx.origin is the DON's writer, not the user. Authorization is anchored on the EIP-712-recovered signer address compared against the wallet's allow-list, not on the message sender — see Smart Accounts for the contract-level model.

Get the latest Chainlink content straight to your inbox.