Delegated Transaction
Pronunciation: DEH-luh-gay-tuhd tran-ZAK-shun
Definition
A delegated transaction is a blockchain transaction in which one party authorizes another party, service, or smart contract to submit or execute an action on its behalf. The delegation can be temporary, limited to specific permissions, or tied to a spending cap, session key, or signed message. The original account owner does not necessarily broadcast the transaction directly. Delegation improves usability and automation, but the authorization scope must be clear so the delegate cannot perform unintended actions.
Overview
Delegated transactions separate authorization from transaction submission. A user may sign a permission that allows a relayer, wallet service, smart account, or application to submit a transaction later. This pattern is common in sponsored-gas systems, account abstraction, delegated staking, session keys, and automated trading or payment workflows.
The delegation mechanism varies by protocol. It may use an on-chain approval, an off-chain signed message, a temporary key, a capability object, or a smart-contract policy. The delegate normally cannot exceed the permissions encoded in that authorization, but poorly designed permissions can still expose broad control.
Security depends on scope, expiry, replay protection, and revocation. A safe delegation should identify the network, account, allowed actions, spending limits, destination restrictions, nonce or unique identifier, and expiration time. If the same signed authorization can be reused, an attacker may replay it. If revocation is slow or unclear, a compromised delegate may continue acting.
Applications should display exactly what the user is delegating and distinguish between permission to submit a transaction and permission to control funds. Audit logs should preserve who created the delegation, which delegate used it, and which transaction resulted. Delegated transactions can make blockchain applications feel more like conventional software, but they require stronger permission design because users may not review every resulting transaction individually.
Delegation should also be separated from custody. A service can submit transactions without ever holding the user’s private key, while another arrangement may give the delegate direct control over assets. Policy engines should enforce the narrowest permissions possible and reject transactions that exceed them. When delegated access is used for recurring payments or automation, users need a clear dashboard for reviewing active permissions and revoking them without waiting for support.
Key Takeaway
A delegated transaction lets another party act under limited authorization, so scope, expiry, replay protection, revocation, and auditability are essential.
Sources
- Ethereum Transactions — Ethereum.org (2026-07-30)