docs(tip-1061): specify native multisig accounts

[joshieDo]

Defines native multisig accounts for T11 and adds the corresponding changelog entry. The stacked implementation begins with #7234.

[joshieDo]

cyclops audit fast note="this belongs to the GH stack #7243 and the TIP 1061 is specified in the PR 7242. any bug not introduced by this PR should be clearly marked"

[tempoxyz-bot]

👁️ Cyclops Review

TIP-1061 is detailed and generally consistent, but two low-severity specification gaps should be resolved before independent implementations target T11.

Reviewer Callouts

• ⚡ Primitive sender collision assumption: The design intentionally omits a registry check for primitive signatures that recover to a registered multisig address and treats the approximately 2^80 address-collision attack as out of scope. A human should explicitly accept that account-takeover tradeoff.
• ⚡ Pool validation cost: Invalid transactions can pass the claimed sender's fee-affordability check before forcing bounded but expensive multisig verification. Confirm peer scoring or rate limiting handles repeated NativeMultisigValidationFailed submissions.

[joshieDo]

cyclops audit fast note="this belongs to the GH stack #7243 and the TIP 1061 is specified in the PR 7242. any bug not introduced by this PR should be clearly marked"

[tempoxyz-bot]

👁️ Cyclops Review

Two actionable findings were verified in the T11 configurable-accounts specification.

Reviewer Callouts

• ⚡ State-dependent intrinsic gas: Ensure pool validation, estimation, block building, and execution use the same journaled block-prefix state and recompute after configuration changes.
• ⚡ Direct-frame enforcement: msg.sender == tx.origin does not block DELEGATECALL; require an explicit protocol-frame/depth guard.
• ⚡ Configuration storage updates: Clear old owner weight rows before overwriting the owner count or writing new rows.
• ⚡ Stateless signer recovery: Audit recover_signer and recover_authority callers so bare multisig encodings are not treated as proof of quorum.
• ⚡ Pool/executor consistency: Resolve whether unsupported multisig authorization-list signatures are rejected or skipped and enforce one rule everywhere.
• ⚡ Validation work bounds: Consider an explicit pre-verification budget for invalid transactions.
• ⚡ Bootstrap version wording: Clarify that the stored version is 0 during bootstrap before a header exists.
• ⚡ Configuration events: Include the new version in MultisigConfigUpdated.

[joshieDo]

cyclops audit fast note="this belongs to the GH stack #7243 and the TIP 1061 is specified in the PR 7242. any bug not introduced by this PR should be clearly marked"

[tempoxyz-bot]

👁️ Cyclops Review

TIP-1061 is generally detailed and internally consistent, but one verified Medium gas-accounting issue should be fixed before implementation.

Reviewer Callouts

• ⚡ Invalid-transaction validation cost (tips/tip-1061.md:546): Fee affordability precedes owner-approval verification against a statelessly claimed account, allowing expensive junk trees to consume validation work before rejection. Consider checking derivable owner membership and ordering before P256/WebAuthn verification.
• ⚡ Non-minimal quorum sets (tips/tip-1061.md:211): Earlier removable signatures can produce multiple transaction hashes for the same authorization. Consider requiring every submitted signature to be necessary for quorum.

[joshieDo]

cyclops audit fast note="this belongs to the GH stack #7243 and the TIP 1061 is specified in the PR 7242. any bug not introduced by this PR should be clearly marked"

[tempoxyz-bot]

👁️ Cyclops Review

TIP-1061 is generally detailed, but one verified Medium-severity ordering rule remains undefined. Prior Cyclops reviews already covered the bootstrap-version wording and the no-code/address-collision tradeoff, so those are not repeated here.

Reviewer Callouts

• ⚡ Authorization failure semantics: Quorum failure after fee-affordability validation must reject the transaction as invalid rather than execute as a charged revert; otherwise unauthenticated transactions could burn a funded multisig account's balance.
• ⚡ Intrinsic-gas read ordering: Warm pricing makes registry-gating gas depend on check order. Pin the evaluation order so independent implementations compute the same intrinsic gas.
• ⚡ Bootstrap gas headroom: The stated worst-case 48-owner bootstrap is roughly 29.0M against a 30M transaction cap before its required non-empty call; confirm the limit remains bootstrappable under future gas-schedule changes.
• ⚡ Encoding discriminator: State explicitly that bootstrap and initialized encodings are distinguished by the first RLP item's list-versus-address shape.

[tempoxyz-bot]

⚠️ [ISSUE] Registry role checks are not ordered after same-transaction bootstrap

The TIP allows an account to be bootstrapped and registered in the same transaction while requiring registry checks for newly authorized access-key IDs, keychain authorization-list authorities, and keychain callers with code or delegation. It never specifies whether those checks observe state before or after the bootstrap header write. An implementation using the pre-bootstrap snapshot could treat the new account as unregistered and permit a restricted role, including installing EIP-7702 delegation on a live multisig account and violating the no-account-code invariant.

Recommended Fix:
Require every multisig-restricted role check to observe registry state after any same-transaction bootstrap header write. Explicitly sequence bootstrap before key-authorization registration and authorization-list application, and define an account bootstrapped in transaction T as registered for every role check in T.