Enhance documentation for exact payment scheme

[notorious-d-e-v]

Description

Expanded the documentation for the 'exact' payment scheme, detailing terminology, protocol flow, payment requirements, and facilitator verification rules.

Tests

N/A

Checklist

• I have formatted and linted my code
• All new and existing tests pass
• My commits are signed (required for merge) -- you may need to rebase if you initially pushed unsigned commits

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[vercel]

@notorious-d-e-v is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[notorious-d-e-v]

Pasting a comment below from @tenequm which contains improvements for this PR.
Original comment here

---

This is exactly the right structure. Separating scheme definition from sponsor policy is the clean architecture this needed.

Your Section 2.1.1 (fee payer signer scope) is the key insight - once you verify the fee payer isn't authorizing anything beyond fee payment, the transaction structure becomes irrelevant. That's what unlocks the flexibility.

A few things that could strengthen Section 2.1 based on some edge cases:

ComputeBudget bypass - If a transaction has multiple SetComputeUnitPrice instructions, only the last one applies. An attacker could put a low value first (passes validation) then a high value later (actually charged). Same for SetComputeUnitLimit. Requiring exactly one of each would close this.

Account creation - Section 2.1.2 says "Enforcing §2.1.1 is sufficient" but CreateAccount with fee payer as from doesn't actually require fee payer as instruction signer - the fee payer role implicitly funds it. Might need an explicit check there.

Token-2022 extensions - Some extensions like NonTransferable or DefaultAccountState=Frozen will cause transfers to always fail. Probably worth explicit rejection in 2.1.

On the SHOULD vs MUST question for Section 2.2 - I'd lean toward making the critical cost controls (compute limits) normative. Otherwise facilitators diverge and clients can't predict acceptance. But curious what others think.

I put together some detailed analysis on these edge cases #646 (comment) if useful for tightening up 2.1.