# Account Abstraction and Gas Sponsorship
Source: https://docs.chain.link/crec/concepts/account-abstraction
Last Updated: 2026-05-01

> For the complete documentation index, see [llms.txt](/llms.txt).

CRE Connect Operations are **gas-less** from the application's point of view. The application signs an Operation with a key that holds no on-chain balance, hands it off to CRE Connect, and the on-chain transaction lands without the application paying gas. This page explains the mechanics behind that experience and where it differs from ERC-4337 account abstraction.## What "gas-less" means hereWhen an application submits an Operation:* 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 sent to CRE Connect over HTTPS — 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. The application's signing key never appears in `tx.origin`.From the application's perspective, executing an Operation is a single call that returns immediately with a tracking identifier, and a `confirmed` event flows back through the channel stream when the chain transaction is included.## End-to-end flow![Image](/images/crec/concepts/account-abstraction-flow.png)Gas is paid by the DON's writer, not by the 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:1) **Authorization is decoupled from gas via EIP-712.** The Smart Account verifies that the EIP-712 signature was produced by an address in its allow-list. That address holds no ETH and is never `tx.origin`.
2) **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.## 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 Connect                   |
| Signing format      | Account-defined                            | EIP-712 with a CRE Connect-native domain                 |The two models solve the same problem with different infrastructure. CRE Connect's model is a fit when applications also want verifiable inbound events from the same DON that executes their outbound operations — which is the typical CRE Connect 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 `operation.status` events. | Off-chain compute (the application's own infrastructure).                                                                 |Practically: if an 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.> **TIP: Funding model**
>
> The signing key is gas-less, but the Smart Account itself may need to hold native token if Operations transfer
> `value`. A common pattern is to keep a small native-token float on each Smart Account and top it up through a separate
> Operation when it dips below a threshold.## Related* [Operations & Transactions](/crec/concepts/operations) — the unit of write that this gas-less model executes.
* [Smart Accounts](/crec/concepts/smart-accounts) — the on-chain identity that pays no gas.
* [EIP-712 Signing](/crec/concepts/eip712-signing) — the authorization step that precedes execution.