Authentication delegation for custom accounts
A first-class protocol mechanism for smart accounts to delegate authentication logic to other addresses.
What it does
Two new host functions are introduced: delegate_account_auth, which may be called inside a custom account's __check_auth function to delegate authentication to a specified address, and get_delegated_signers_for_current_auth_check, which returns the list of delegated signer addresses populated in the current authorization entry.
A new credential type, SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES, allows all delegated signers and their (potentially nested) signatures to be bundled into a single authorization entry. This eliminates the need for a separate authorization entry per delegated signer, reducing transaction size and simplifying simulation. Delegation can be nested recursively, so any account — including ones with delegated signers of their own — can serve as a delegate.
The signature payload for this credential type uses a new ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS envelope, which explicitly binds the payload to the top-level account address, preventing cross-account signature replay.
Why it matters
The underlying capability — delegating authentication from a custom account to another address — already existed in the protocol, but only as an accidental side effect of the authorization framework design. In practice it was difficult to use: simulation required manually constructing inner authorization payloads and running multiple simulation passes; every delegated signer required its own authorization entry with its own nonce, increasing transaction cost; and forwarding authorization context to delegates bloated transaction size unnecessarily. Zipper makes delegation a proper, first-class feature that is dramatically simpler to implement correctly.
Who should care
Soroban developers building smart accounts — wallets, multisig schemes, account abstraction — will see the most direct benefit. Delegation goes from being a fragile workaround to a supported, efficient pattern. Transaction sizes shrink, simulation simplifies, and the boilerplate around payload construction largely disappears.
Developers following the broader account abstraction roadmap should also pay attention. CAP-0071-01 is explicitly foundational to CAP-0072, which adds contract-based authentication to classic Stellar (G-) accounts. The delegation mechanism introduced here is the same one that more visible features in future protocols will depend on.
End users and wallet holders benefit indirectly: cheaper transactions and more flexible account designs (social recovery, delegated signing keys, modular multisig) become practical to build.