DatingDapp
AI First Flight #6
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Impact: low
Likelihood: high
Invalid

TransactionApproved Event Does Not Expose Combined Quorum Status

rivera

Description

  • Normal behavior: off-chain indexers/frontends should be able to determine from event logs alone whether a transaction has reached executable (2-of-2) status.

  • Specific issue: TransactionApproved only reports who just approved, not the combined approval state.

emit TransactionApproved(_txId, msg.sender); // @> doesn't report txn.approvedByOwner1/2 — observer must independently track both across separate logs

Risk

Likelihood: Occurs on every single approval, with no exception.
Impact: Observability/UX gap only — no fund-loss or access-control consequence, purely affects off-chain consumers' ability to determine executability from events alone.

Proof of Concept

No PoC is included: nothing on-chain behaves incorrectly — every require/state transition in MultiSig.sol still works as intended. The gap only affects what data an off-chain observer (indexer, frontend) receives, which isn't something a Foundry unit test on contract state can meaningfully assert against; it's demonstrated directly by comparing the event's parameter list to the state it would need to expose full quorum status.

Recommended Mitigation

Adding both approval booleans to the existing event lets any off-chain consumer determine full 2-of-2 status from a single log entry, instead of having to correlate multiple TransactionApproved events for the same _txId across time.

- emit TransactionApproved(_txId, msg.sender);
+ emit TransactionApproved(_txId, msg.sender, txn.approvedByOwner1, txn.approvedByOwner2);
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 1 day ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!