Account Abstraction and Gas Sponsorship

CRE Connect Operations are gas-less from the application's point of view. Your code signs an Operation with a key that holds no on-chain balance, hands it to the SDK, and the on-chain transaction lands without your code paying gas. This page explains the mechanics behind that experience and where it differs from ERC-4337 account abstraction.

What "gas-less" means here

When you call client.Transact.ExecuteTransactions(...):

The signing key (local ECDSA, KMS, Vault, Fireblocks, Privy, or custom) only signs an EIP-712 hash. It is never asked to broadcast a transaction.
The Operation is POSTed over HTTPS to the CRE Connect API: no gas, no nonce, no chain RPC.
A CRE workflow on the Chainlink DON picks up the Operation, signs the underlying transaction with the DON's keys, and broadcasts it on-chain.
The DON's writer EOA is the on-chain tx.origin and pays the gas. Your application's signing key never appears in tx.origin.

From your application's perspective, executing an Operation is a single SDK call that returns immediately with a tracking ID, and operation.status events flow back as the chain transaction is included and confirmed. See Multi-Event Finality.

End-to-end flow

Gas is paid by the DON's writer, not by your application's signer. The signer's only role is producing the EIP-712 signature.

Why this is "account abstraction"

Account abstraction is the property that the authorizer of an Operation does not have to be the payer of gas. CRE Connect's model achieves this by:

Authorization is decoupled from gas via EIP-712. The Smart Account verifies that the EIP-712 signature was produced by an address in its AllowedEcdsaSigners (or RSA equivalent) allow-list. That address holds no ETH and is never tx.origin.
Execution is delegated to the DON. The DON signs and broadcasts the on-chain transaction itself, paying gas from its own writer EOA. The Smart Account treats the DON-attested call as sufficient permission to execute the Operation atomically.

This is functionally equivalent to ERC-4337's "User signs, paymaster pays" model, but the implementation is Chainlink-native and does not depend on EntryPoint, UserOperation, or bundlers. See the comparison below.

How this differs from ERC-4337

Concept	ERC-4337	CRE Connect
Account model	UserOperation queue → EntryPoint → Account	EIP-712 Operation → Chainlink DON → Smart Account
Authorization	Account-defined `validateUserOp`	Account-defined EIP-712 signer allow-list (ECDSA or RSA)
Gas sponsorship	Paymaster contract or self-funded	Chainlink DON pays gas from its own writer EOA
Bundler	Off-chain bundler builds UserOp batches	The DON itself signs and broadcasts each operation
Network requirement	Any EVM chain with deployed EntryPoint	Any EVM chain supported by CRE (see Supported Networks)
Signing format	Account-defined	EIP-712, fixed `CLLSmartAccount` domain

The two models solve the same problem with different infrastructure. CRE Connect's model is a fit when you also want verifiable inbound events from the same DON that executes your outbound operations, which is the typical CREC integration pattern.

What gas sponsorship covers

Sponsored	Not sponsored
Gas for the on-chain transaction the DON broadcasts.	Funding the `value` field of any `Transaction` in the Operation: the Smart Account itself must hold enough native token.
Gas for the Smart Account's `OperationExecuted` log.	Tokens transferred or approved by the Operation's transactions.
Gas for the on-chain status read that triggers your `operation.status` event.	Off-chain compute (the application's own infrastructure).

Practically: if your Operation needs to send 1 ETH to a counterparty, the Smart Account needs to hold 1 ETH. Gas for that send is sponsored by the DON.

Operations & Transactions: the unit of write that this gas-less model executes.
Smart Accounts: the on-chain identity that pays no gas.
Build and Sign Operations: turn the model into runnable code.