2026-04-30
Protocol Discussion: Modular Custom Accounts and Signature Security in Protocol 27
This protocol meeting covered two related authorization changes coming in Protocol 27, presented by Dmytro Kozhevin: a recap of CAP-71's authentication delegation for custom accounts, and a newly published security addendum, CAP-0071-02, that closes a narrow signature replay gap.
CAP-71 Recap: Authentication Delegation for Custom Accounts
CAP-71 has been around for a while and hasn't changed — the news is that it is actually being implemented in Protocol 27. It improves what modular custom accounts can do by adding built-in delegation support at the protocol level. A "root" account can delegate logic — for example, the cryptography implementation — to separate "sub-account" contracts. That makes it possible to have an abstract, configurable meta-account shared by multiple users, with the actual signing logic living in different contracts.
This architecture has already been attempted in the wild (OpenZeppelin's contract examples use it), but until now it was painful: delegating the authorization context required several rounds of pre-simulation to propagate the context. CAP-0071-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.
CAP-0071-02: Closing a Signature Replay Gap
The reason a separate addendum exists: CAP-71 introduced a new kind of signature payload preimage, and that surfaced a small oversight in the original design. Soroban uses a unified format for signature payloads — a preimage carrying most of the necessary context, hashed with SHA-256 and then signed with an arbitrary cryptographic algorithm. "Most" is the key word: the standard authorization payload does not include the signer's address.
Most of the time this doesn't matter. In a typical token transfer from A to B, the authorizing address is present in the payload anyway. Even when it isn't — like minting with a Stellar Asset Contract, where the admin address is not in the payload — a SAC has only a single admin, so the signature can't be reused.
The one obscure case where it does matter, described in detail in the security notice published just before the meeting, requires a specific combination of factors to line up:
- An admin-style contract where the authorizing signer is implicit — fetched from storage rather than named in the payload
- That admin being rotated to a different public address
- The old and new addresses reusing the same private key
Sharing a private key across public addresses is rare and generally not something you should do, and an analysis showed this combination has never occurred on-chain. But if it ever did happen, the impact would be serious — a signature could be replayed to, for example, mint a token a second time. The gap was discovered through security audits.
The fix introduces a new credential type, SOROBAN_CREDENTIALS_ADDRESS_V2, whose only difference from the current address credentials is that the protocol uses an address-bound signature payload preimage — the signer's address is guaranteed to be part of what gets signed. The structure is otherwise identical, so supporting it downstream is just a matter of switching from one credential type and payload format to the other.
Migration Guidance
As of Protocol 27, the old address credentials are not being deprecated — the probability of the issue is low enough that there's no urgency for an abrupt, breaking fix. The intention is to migrate to address v2 eventually (possibly Protocol 28 or later): client tooling — the CLI, developer SDKs, and so on — can update to the new credential and payload format at their own pace after the Protocol 27 upgrade, and once the ecosystem has moved, the old format can be deprecated non-disruptively. If you maintain an admin-style contract and are worried in the meantime, you can pass the signer address in the payload explicitly.
Read more about the proposals here: