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-71-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-71-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.CAP-71-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
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.