Describe fee proposal draft #135
Conversation
WalkthroughAdds a new proposal document describing a modular Taiko L2 fee design that separates L2 execution gas, L1 data publication costs, and proving incentives, and outlines mechanisms for sequencer charging, liveness bonds, refunds, treasury surcharges, wallet compatibility, alternatives, and resolution. (≤50 words) Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant User
participant Wallet
participant Sequencer
participant L1
participant Prover
participant Treasury
rect rgb(240,248,255)
note right of Wallet: Fee discovery / total fee selection
end
User->>Wallet: build txn (total priority or gas estimate)
Wallet->>Sequencer: submit txn + fee info
Sequencer->>L1: publish block blobs (pay L1 data costs)
Sequencer->>Prover: include publication + liveness bond (validatePublication optional)
Prover->>Sequencer: prove publication or claim bond if proposer fails
alt publication accepted
Sequencer->>Treasury: optional protocol surcharge (from measured L1 costs)
else publication challenged / prover wins
Prover->>Treasury: receives bond/penalty per rules
end
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
documentation/Fee Proposal.md (3)
6-6: Add a comma before “but” to avoid a run-on sentence-… developers to build whatever they want. We can provide example implementations but they should not be part of the core protocol. +… developers to build whatever they want. We can provide example implementations, but they should not be part of the core protocol.
30-41: Normalize nested-list indentation for Markdownlint complianceMD007 violations appear throughout this block (and similar ones below). Stick to a consistent two-space indent per nesting level:
- - Similarly, proposers must post a liveness bond with each publication. The protocol will guarantee: - - if the publication is proven in time, … +- Similarly, proposers must post a liveness bond with each publication. The protocol will guarantee: + - if the publication is proven in time, …Apply the same pattern to all nested bullet lists in the document.
50-50: Tense/clarity tweakPresent tense reads better and removes the duplicated subject.
- - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. + - the prover pays a slightly smaller amount to the proposer on L2. The difference is the proving fee.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Fee Proposal.md
[uncategorized] ~6-~6: Use a comma before ‘but’ if it connects two independent clauses (unless they are closely connected and short).
Context: .... We can provide example implementations but they should not be part of the core pro...
(COMMA_COMPOUND_SENTENCE)
[uncategorized] ~26-~26: This verb may not be in the correct form. Consider using a different form for this context.
Context: ... L2 ETH when they exceed the target and adjust the target whenever this happens. The d...
(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
[grammar] ~49-~49: This phrase is duplicated. You should probably use “the prover” only once.
Context: ...L1 liveness bond, which will be sent to the prover - the prover paid a slightly smaller amount to the p...
(PHRASE_REPETITION)
🪛 markdownlint-cli2 (0.17.2)
documentation/Fee Proposal.md
13-13: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
14-14: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
31-31: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
32-32: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
33-33: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
34-34: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
35-35: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
37-37: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
38-38: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
39-39: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
40-40: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🪛 GitHub Check: typos
documentation/Fee Proposal.md
[warning] 26-26:
"targetting" should be "targeting".
🪛 GitHub Actions: check
documentation/Fee Proposal.md
[warning] 26-26: "targetting" should be "targeting".
[error] 26-26: Typo error: targetting should be targeting.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Foundry project
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
documentation/Fee Proposal.md (3)
30-46: Fix list-indentation to satisfy markdownlint (MD007).
Nested unordered lists should be indented by two spaces per level. Current mis-indentation breaks some renderers and fails CI markdown-lint.-30 - Based on feedback for the previous version: -31 - we should retain the EIP1559 mechanism to remain consistent with existing (and battle-tested) infrastructure -32 - we should include a mechanism to direct funds to the rollup's treasury +30 - Based on feedback for the previous version: +31 - we should retain the EIP1559 mechanism to remain consistent with existing (and battle-tested) infrastructure +32 - we should include a mechanism to direct funds to the rollup's treasuryApply the same two-space rule to subsequent nested bullets (38-46, 56-67, etc.) to clear all MD007 warnings.
25-25: Minor wording – add hyphen to “off-chain”.
Compound adjectives like “off-chain mechanism” improve readability and avoid spell-check noise.-Users can incentivize the proposer to include their transaction using any offchain or L2-mechanism they want. +Users can incentivize the proposer to include their transaction using any off-chain or L2 mechanism they want.
22-24: Consider clarifying DoS/abuse assumptions when base fee is zero.
Setting the base fee to 0 while relying solely on a gas limit could invite cheap spam unless the liveness bond or other mechanisms sufficiently price abusive compute-heavy blocks. A brief rationale (e.g., “gas limit X + proposer-paid L1 costs is economically sufficient because …”) would pre-empt reviewer concerns.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Fee Proposal.md
[grammar] ~1-~1: Use correct spacing
Context: # Fee Proposal ## Overview - I have an intuition that so...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~3-~3: Use proper spacing conventions.
Context: # Fee Proposal ## Overview - I have an intuition that some of the L2 ...
(QB_NEW_EN_OTHER_ERROR_IDS_000007)
[grammar] ~6-~6: Correctly pair commas and coordinating conjunctions
Context: ...tever they want. We can provide example implementations but they should not be part of the core...
(QB_NEW_EN_OTHER_ERROR_IDS_14)
[typographical] ~8-~8: To join two clauses or set off examples, consider using an em dash.
Context: ...tions. - I have low confidence in this claim - it's quite possible I'm missing somethin...
(QB_NEW_EN_DASH_RULE_EM)
[grammar] ~8-~8: There might be a problem here.
Context: ...through the idea. Feedback is very much encouraged. ## Background - As I understand it, the whole L1 gas me...
(QB_NEW_EN_MERGED_MATCH)
[grammar] ~12-~12: There might be a mistake here.
Context: ...d to limit third-party costs on staking validators: - the block gas limit ensures consumer-grade ...
(QB_NEW_EN_OTHER)
[grammar] ~13-~13: There might be a problem here.
Context: ... validator devices can keep up with the chain - the gas price ensures users pay the "costs ...
(QB_NEW_EN_MERGED_MATCH)
[grammar] ~15-~15: There might be a mistake here.
Context: ...here are no actual "costs to the network". - The gas target is not about security,...
(QB_NEW_EN_OTHER)
[grammar] ~16-~16: There might be a problem here.
Context: ... demand. We should aim to preserve this property. ## Idea ### Transaction Costs - Version 1 - The ba...
(QB_NEW_EN_MERGED_MATCH)
[typographical] ~20-~20: To join two clauses or set off examples, consider using an em dash.
Context: ...his property. ## Idea ### Transaction Costs - Version 1 - The basic idea is to remove...
(QB_NEW_EN_DASH_RULE_EM)
[grammar] ~20-~20: Use correct spacing
Context: ...# Idea ### Transaction Costs - Version 1 - The basic idea is to remove the in-prot...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~22-~22: There might be a mistake here.
Context: ...col fee mechanism (and the implicit gas target), by setting the base fee to zero. - I t...
(QB_NEW_EN_OTHER)
[grammar] ~23-~23: Punctuation usually goes inside quotation marks
Context: ...at anyone running a node can reasonably say "if my node has X resources, I will be ...
(QB_NEW_EN_OTHER_ERROR_IDS_20)
[grammar] ~23-~23: There might be a mistake here.
Context: ...I will be able to keep up with the chain", but it doesn't need to target consumer ...
(QB_NEW_EN_OTHER)
[grammar] ~23-~23: Use comma(s) to set off direct address
Context: ...will constrain the practical limit, but data-light compute-heavy transactions (or actual a...
(QB_NEW_EN_OTHER_ERROR_IDS_18)
[grammar] ~25-~25: Insert the missing word
Context: ...oser to include their transaction using any offchain or L2-mechanism they want. The ...
(QB_NEW_EN_OTHER_ERROR_IDS_32)
[grammar] ~25-~25: Use hyphens correctly
Context: ...their transaction using any offchain or L2-mechanism they want. The proposer could reproduce...
(QB_NEW_EN_OTHER_ERROR_IDS_29)
[grammar] ~25-~25: Consider adjusting word choice based on regional variation
Context: ...he proposer could reproduce the current behaviour by measuring the gas used and charging ...
(QB_NEW_EN_OTHER_ERROR_IDS_26)
[grammar] ~26-~26: Use correct spacing
Context: ...tly to the proposer, not the individual transactions. ### Transaction Costs - Version 2 - Based ...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[typographical] ~28-~28: To join two clauses or set off examples, consider using an em dash.
Context: ...dividual transactions. ### Transaction Costs - Version 2 - Based on feedback for the p...
(QB_NEW_EN_DASH_RULE_EM)
[grammar] ~28-~28: Use correct spacing
Context: ...tions. ### Transaction Costs - Version 2 - Based on feedback for the previous vers...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~30-~30: Use colons correctly
Context: ...2 - Based on feedback for the previous version: - we should retain the EIP1559 mechanism to ...
(QB_NEW_EN_OTHER_ERROR_IDS_30)
[grammar] ~31-~31: There might be a problem here.
Context: ...stent with existing (and battle-tested) infrastructure - we should include a mechanism to direct fu...
(QB_NEW_EN_MERGED_MATCH)
[grammar] ~32-~32: There might be a mistake here.
Context: ...chanism to direct funds to the rollup's treasury - However, I still insist that we should not use t...
(QB_NEW_EN_OTHER)
[grammar] ~34-~34: Use correct spacing
Context: ...wo-step process (except possibly for L2 execution): - users pay the sequencer with the priority fee...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~35-~35: Insert the missing word
Context: ...ny sequencer wants to set up another L2 or offchain mechanism (eg. to use an ERC20 ...
(QB_NEW_EN_OTHER_ERROR_IDS_32)
[grammar] ~35-~35: There might be a mistake here.
Context: ...et up another L2 or offchain mechanism (eg. to use an ERC20 token), they always hav...
(QB_NEW_EN_OTHER)
[grammar] ~37-~37: There might be a mistake here.
Context: ...ue. - In practice, this will have a few components: - the L2 base fee mechanism continues to char...
(QB_NEW_EN_OTHER)
[grammar] ~38-~38: There might be a mistake here.
Context: ...rd EIP1559 mechanism with some possible modifications: - the base fee itself could be set to 0 (beca...
(QB_NEW_EN_OTHER)
[grammar] ~39-~39: There might be a mistake here.
Context: ...- the base fee itself could be set to 0 (because as noted above, I think it's not necess...
(QB_NEW_EN_OTHER)
[grammar] ~39-~39: There might be a mistake here.
Context: ...noted above, I think it's not necessary) - in this case, the sequencer could still op...
(QB_NEW_EN_OTHER)
[grammar] ~40-~40: Use commas correctly
Context: ...tionally have a (per-second) target gas amount, and be charged for it using an EIP1559-s...
(QB_NEW_EN_OTHER_ERROR_IDS_33)
[grammar] ~44-~44: There might be a mistake here.
Context: ...ication transaction) and doing a direct transfer - alternatively, it could be computed as part of the sta...
(QB_NEW_EN_OTHER)
[style] ~47-~47: In American English, abbreviations like “etc.” require a period.
Context: ...transactions incur large proving costs, etc) - unfortunately, priority fees are...
(ETC_PERIOD)
[grammar] ~47-~47: There might be a mistake here.
Context: ...sactions incur large proving costs, etc) - unfortunately, priority fees are actually a fee-rate,...
(QB_NEW_EN_OTHER)
[grammar] ~48-~48: Use hyphens correctly
Context: ...rtunately, priority fees are actually a fee-rate, so the amount paid will depend on the L...
(QB_NEW_EN_OTHER_ERROR_IDS_29)
[grammar] ~48-~48: There might be a mistake here.
Context: ...whether a transaction is worth including - this is a consequence of the EIP1559 mechani...
(QB_NEW_EN_OTHER)
[grammar] ~49-~49: There might be a mistake here.
Context: ...559 mechanism only accounting for L2 gas - sequencers may be able to address this by using wr...
(QB_NEW_EN_OTHER)
[grammar] ~50-~50: Use commas correctly
Context: ...e able to address this by using wrapper transactions, or just deal with the possibility that t...
(QB_NEW_EN_OTHER_ERROR_IDS_33)
[grammar] ~51-~51: There might be a mistake here.
Context: ...need to get support from the ecosystem (eg. wallets) to use it. ### Proving costs ...
(QB_NEW_EN_OTHER)
[grammar] ~51-~51: Use correct spacing
Context: ...from the ecosystem (eg. wallets) to use it. ### Proving costs - Similarly, proposers m...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~53-~53: Use correct spacing
Context: ...m (eg. wallets) to use it. ### Proving costs - Similarly, proposers must post a livene...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~55-~55: Use colons correctly
Context: ...ith each publication. The protocol will guarantee: - if the publication is proven in time, th...
(QB_NEW_EN_OTHER_ERROR_IDS_30)
[grammar] ~67-~67: There might be a mistake here.
Context: ...saction that can change L2 state in any way including transferring tokens or ETH. I...
(QB_NEW_EN_OTHER)
[grammar] ~69-~69: Add a conjunction or punctuation
Context: ...veness bond minus its chosen fee to the proposer - it ensures the L1 refund address be...
(QB_NEW_EN_OTHER_ERROR_IDS_16)
[grammar] ~70-~70: There might be a mistake here.
Context: ...es the L1 refund address belongs to the prover - In this way - the prover contra...
(QB_NEW_EN_OTHER)
[grammar] ~71-~71: There might be a mistake here.
Context: ...dress belongs to the prover - In this way - the prover contract can decide how much to ...
(QB_NEW_EN_OTHER)
[grammar] ~72-~72: There might be a mistake here.
Context: ...lar publication using whatever rules it wants - any proposer can accept the deal by constr...
(QB_NEW_EN_OTHER)
[grammar] ~73-~73: There might be a mistake here.
Context: ...cation that invokes this prover contract - in the happy case - the proposer paid ...
(QB_NEW_EN_OTHER)
[grammar] ~74-~74: There might be a mistake here.
Context: ...s this prover contract - in the happy case - the proposer paid the L1 liveness bond, whi...
(QB_NEW_EN_OTHER)
[grammar] ~75-~75: There might be a problem here.
Context: ...iveness bond, which will be sent to the prover - the prover paid a slightly smaller amount t...
(QB_NEW_EN_MERGED_MATCH)
[grammar] ~77-~77: There might be a mistake here.
Context: ... is the proving fee. - in the unhappy case - the proposer still pays the proving fee (in...
(QB_NEW_EN_OTHER)
[grammar] ~78-~78: There might be a mistake here.
Context: ...proposer still pays the proving fee (in effect) - the specified prover pays the rest of the l...
(QB_NEW_EN_OTHER)
[grammar] ~79-~79: There might be a problem here.
Context: ...pays the rest of the liveness bond as a penalty - both amounts are given to the actual prover ...
(QB_NEW_EN_MERGED_MATCH)
[grammar] ~80-~80: There might be a mistake here.
Context: ... - both amounts are given to the actual prover - We could avoid actually transferring funds...
(QB_NEW_EN_OTHER)
[style] ~81-~81: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
🪛 markdownlint-cli2 (0.17.2)
documentation/Fee Proposal.md
13-13: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
14-14: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
31-31: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
32-32: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
35-35: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
36-36: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
38-38: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
39-39: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
40-40: Unordered list indentation
Expected: 6; Actual: 11
(MD007, ul-indent)
41-41: Unordered list indentation
Expected: 6; Actual: 11
(MD007, ul-indent)
42-42: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
43-43: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
44-44: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
45-45: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
46-46: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
48-48: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
49-49: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
50-50: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
51-51: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
56-56: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
57-57: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
58-58: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
59-59: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
60-60: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
62-62: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
63-63: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
64-64: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
65-65: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
66-66: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
67-67: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🔇 Additional comments (1)
documentation/Fee Proposal.md (1)
26-26: Typo resolved – thank you.
The earliertargettingmisspelling is now correctly written as “targeting”.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
documentation/Taiko Fee Proposal.md (3)
59-59: Replace “L1 / L2” with a conjunction for clarityUsing the slash can be ambiguous and was flagged by static analysis. Switching to “and” improves readability.
- - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address … + - We could avoid actually transferring funds between L1 and L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address …
85-86: Correct minor typosTwo small spelling errors slipped in—also flagged by CI.
- - Morever, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user … + - Moreover, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user … - … if the publication fee was not incoporated into the base fee … + … if the publication fee was not incorporated into the base fee …
4-14: Adjust unordered-list indentation to satisfymarkdownlint(MD007)Many list items are indented 4 spaces instead of the recommended 2. Aligning to 2-space indentation keeps the hierarchy clear and will silence the linter.
Example fix:
- - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. - - limit the total resource consumption … + - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. + - limit the total resource consumption …Apply the same adjustment throughout the document.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[grammar] ~61-~61: Ensure spelling is correct
Context: ...he agreed proving costs (as part of the validatPublication interface) and apply a surcharge to se...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~86-~86: Ensure spelling is correct
Context: ...was that if the publication fee was not incoporated into the base fee, it would not be subj...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 GitHub Check: typos
documentation/Taiko Fee Proposal.md
[warning] 86-86:
"incoporated" should be "incorporated".
[warning] 85-85:
"Morever" should be "Moreover".
[warning] 61-61:
"validat" should be "validate".
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🪛 GitHub Actions: check
documentation/Taiko Fee Proposal.md
[error] 61-61: typos: validat should be validate
[error] 85-85: typos: Morever should be Moreover
[error] 86-86: typos: incoporated should be incorporated
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
documentation/Taiko Fee Proposal.md (1)
61-61: Fix the remainingvalidatPublicationtypo – it still breaks consistency & the CI.The earlier review already flagged this, but the typo persists. Please rename
validatPublication→validatePublicationto unblock the pipeline.- - We could track the agreed proving costs (as part of the `validatPublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. + - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to the sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee.
🧹 Nitpick comments (3)
documentation/Taiko Fee Proposal.md (3)
27-27: Grammar nit: “decided” → “decide”.- - sequencers can decided for themselves how (or even whether) to charge each user … + - sequencers can decide for themselves how (or even whether) to charge each user …
85-85: Spelling: “Morever” → “Moreover”.- - Morever, sequencers are incentivised to optimise the publication costs, and can pass … + - Moreover, sequencers are incentivised to optimise the publication costs, and can pass …
86-86: Spelling: “incoporated” → “incorporated”.- - When discussing this idea, one concern was that if the publication fee was not incoporated into the base fee … + - When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee …
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🪛 GitHub Check: typos
documentation/Taiko Fee Proposal.md
[warning] 86-86:
"incoporated" should be "incorporated".
[warning] 85-85:
"Morever" should be "Moreover".
[warning] 61-61:
"validat" should be "validate".
🪛 GitHub Actions: check
documentation/Taiko Fee Proposal.md
[error] 61-61: typos: validat should be validate
[error] 85-85: typos: Morever should be Moreover
[error] 86-86: typos: incoporated should be incorporated
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
documentation/Taiko Fee Proposal.md (1)
60-61: Misspelled interface name still breaks the build
validatPublicationis still missing the “e”. This typo keeps the pipeline red and is inconsistent with the earlier correct spelling (validatePublication).- - We could track the agreed proving costs (as part of the `validatPublication` interface) and apply a surcharge to sequencer, directed to the treasury … + - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to the sequencer, directed to the treasury …
🧹 Nitpick comments (2)
documentation/Taiko Fee Proposal.md (2)
25-28: Grammar nit: “can decided” → “can decide”- - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. + - sequencers can decide for themselves how (or even whether) to charge each user for their gas consumption.
5-14: Clean up list indentation to satisfy markdownlint (MD007)Nested lists use 4-space indents instead of 2, triggering MD007 and causing uneven rendering in some viewers. Normalise the indentation across the doc, e.g.:
- - apply a "negative externality fee" to account for costs to the network. + - apply a "negative externality fee" to account for costs to the network.Also applies to: 78-82, 104-116
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 GitHub Check: typos
documentation/Taiko Fee Proposal.md
[warning] 85-85:
"Morever" should be "Moreover".
[warning] 61-61:
"validat" should be "validate".
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🪛 GitHub Actions: check
documentation/Taiko Fee Proposal.md
[error] 61-61: typos: validat should be validate
[error] 85-85: typos: Morever should be Moreover
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
documentation/Taiko Fee Proposal.md (4)
25-28: Fix verb conjugation (“decided” → “decide”).Minor grammar glitch; keeps the prose crisp.
- - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. + - sequencers can decide for themselves how (or even whether) to charge each user for their gas consumption.
58-60: Prefer “and” instead of a slash for clarity.- - We could avoid actually transferring funds between L1 / L2 ... + - We could avoid actually transferring funds between L1 and L2 ...
70-72: Missing preposition (“included in the L2 base fee”).-- Moreover, attempting to charge for the wrong resource (eg. L1 costs being included the L2 base fee) can let users craft transactions that exploit the discrepancy. +- Moreover, attempting to charge for the wrong resource (e.g., L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy.
4-15: Indentation fails markdown-lint (MD007).Multiple list items are indented by 4 spaces instead of 2, tripping automated docs linting. Reducing the left padding by two spaces across the top-level list fixes all MD007 warnings.
No functional impact, but it will unblock docs CI.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
documentation/Taiko Fee Proposal.md (4)
24-28: Fix minor verb-tense typo (“decided” → “decide”).- - sequencers can decided for themselves how (or even whether) to charge each user … + - sequencers can decide for themselves how (or even whether) to charge each user …
59-60: Prefer “and” instead of a slash for clearer prose.- - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by … + - We could avoid actually transferring funds between L1 and L2 (or requiring the proposer to have L1 funds) by …
61-61: Add missing article (“the sequencer”).- - We could track the agreed proving costs … and apply a surcharge to sequencer, directed to the treasury … + - We could track the agreed proving costs … and apply a surcharge to the sequencer, directed to the treasury …
4-15: Consider normalising list indentation (MD007).Many unordered lists are indented with four spaces instead of the recommended two. While GitHub renders both correctly, conforming to MD007 keeps the document consistent and lint-clean.
Action: re-indent nested bullet points by two spaces where flagged by markdownlint.Also applies to: 79-115
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
documentation/Taiko Fee Proposal.md (6)
4-9: Fix MD007 list-indent violations for top-level bulletsThe first nested bullet list mixes 4- and 8-space indents, triggering markdownlint MD007 and rendering inconsistently in some viewers.
- In particular, it seems to me that L1 protocol-enforced-fees are useful to: - - apply a "negative externality fee" to account for costs to the network. … - - limit the total resource consumption to a level where other network participants can keep up. - - technically, the actual resource limits (block gas limit and blob number limit) achieve … +In particular, it seems to me that L1 protocol-enforced-fees are useful to: + - apply a "negative externality fee" to account for costs to the network. … + - limit the total resource consumption to a level where other network participants can keep up. + - technically, the actual resource limits (block gas limit and blob number limit) achieve …Apply a consistent two-space indent for each list depth across the document.
27-28: Grammar: “can decided” → “can decide”Minor typo in the sentence about sequencer flexibility.
- sequencers can decided for themselves how (or even whether) to charge each user … + sequencers can decide for themselves how (or even whether) to charge each user …
59-59: Prefer “and” instead of a slash for clarity- We could avoid actually transferring funds between L1 / L2 … + We could avoid actually transferring funds between L1 and L2 …
61-61: Missing article before “sequencer”- … apply a surcharge to sequencer, directed to the treasury … + … apply a surcharge to the sequencer, directed to the treasury …
74-82: Zero base-fee assumption may open a DoS vector—please re-evaluateSetting the L2 base fee to zero removes the economic throttle against pathological compute-heavy transactions. Even with a gas limit, a malicious sequencer could fill publications with near-free loop executions, slowing downstream node processing without bearing cost.
Recommend analysing:
- Worst-case CPU/IO load for a block full of “infinite-loop” style transactions.
- Whether priority fees alone are a sufficient deterrent when sequencers control admission and may internalise the cost.
- Mitigations (e.g., non-zero floor base fee, max per-tx gas, or reputational slashing).
Please confirm these risks or document why they are negligible for Taiko’s architecture.
139-142: Grammar: “can demand” not “can demands”- … because sequencers can demand high priority fees or refuse to sequence … + … because sequencers can demand high priority fees or refuse to sequence …
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
documentation/Taiko Fee Proposal.md (6)
24-28: Typo: “decided” → “decide”Minor grammar fix inside the sub-bullet.
- - sequencers can decided for themselves how (or even whether) to charge each user … + - sequencers can decide for themselves how (or even whether) to charge each user …
59-60: Prefer “and” instead of slash, improves readabilitySlash notation is discouraged in formal specs and flagged by LanguageTool.
- - We could avoid actually transferring funds between L1 / L2 … + - We could avoid actually transferring funds between L1 and L2 …
61-61: Missing article — “the sequencer”- - We could track the agreed proving costs … and apply a surcharge to sequencer, directed to the treasury … + - We could track the agreed proving costs … and apply a surcharge to the sequencer, directed to the treasury …
71-71: Use “e.g.” instead of “eg.”- - Moreover, attempting to charge for the wrong resource (eg. L1 costs … + - Moreover, attempting to charge for the wrong resource (e.g., L1 costs …
140-142: Tone & style: replace informal “going to” with “will”- … any scheme we come up with is going to be vulnerable to sequencers … + … any scheme we come up with will be vulnerable to sequencers …
4-145: Markdown-lint: inconsistent unordered-list indentation
markdownlint(rule MD007) flags ~30 occurrences where sub-list items are indented with 4 spaces instead of the expected 2. While purely stylistic, fixing this keeps automated docs checks green and improves diff cleanliness.Action: run
markdownlint --fixor re-indent bullets with 2-space increments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ...oid actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
documentation/Taiko Fee Proposal.md (1)
40-46: Sanity check: reference to validatePublication now consistentThe earlier typo on the interface name appears corrected here. Good catch.
🧹 Nitpick comments (9)
documentation/Taiko Fee Proposal.md (9)
23-28: Standardize EIP-1559 naming and fix grammar in the sequencer charging paragraphUse the canonical “EIP-1559” spelling and fix “decided” → “decide”; also align spelling with the document’s British English (“subsidised”).
- - use the existing EIP1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. + - use the existing EIP-1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. @@ - - use an EIP1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. + - use an EIP-1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. @@ - - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. + - sequencers can decide for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens, or MEV-rich transactions could be subsidised. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol.
12-12: Hyphenate “off-chain” for consistency“offchain” → “off-chain” (two occurrences) to match common usage in the space and improve readability.
- - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. + - L2 provers have to pay L1 proving costs out of their own account, and may incur significant off-chain proving costs. @@ -- The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. +- The sequencer may still want to charge for the off-chain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction.Also applies to: 75-75
44-46: Use consistent hyphenation for “state-transition function”Earlier you use “state-transition function” (Line 34). Mirror that here for consistency.
- - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post) that these values are set correctly (or the publication defaults to an empty block). + - the state-transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post) that these values are set correctly (or the publication defaults to an empty block).
59-61: Minor phrasing fixes: “L1 and L2”; add article before “sequencer”Improves clarity and grammar.
- - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. + - We could avoid actually transferring funds between L1 and L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. @@ - - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. + - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to the sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee.
141-142: Tighten wording and fix compound adjectiveUse “will” for certainty and hyphenate “high-priority” when used adjectivally.
- - I think that risk already exists, because sequencers can demand high priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with is going to be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits + - I think that risk already exists, because sequencers can demand high-priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with will be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits
6-13: Fix nested list indentation to satisfy markdownlint (MD007)Your nested list indentation doesn’t meet MD007’s default rule (2-space indent). Apply the pattern below and replicate across the document to clear the linter warnings.
-- In particular, it seems to me that L1 protocol-enforced-fees are useful to: - - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. - - limit the total resource consumption to a level where other network participants can keep up. - - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility. +- In particular, it seems to me that L1 protocol-enforced fees are useful to: + - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. + - limit the total resource consumption to a level where other network participants can keep up. + - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that is less than the actual limit, to smooth out volatility. -- In the L2 case: - - there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes so there are no actual "costs to the network". - - L2 sequencers have to pay L1 publication costs out of their own account. - - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. - - We want a mechanism to direct funds towards the treasury. +- In the L2 case: + - there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes so there are no actual "costs to the network". + - L2 sequencers have to pay L1 publication costs out of their own account. + - L2 provers have to pay L1 proving costs out of their own account, and may incur significant off-chain proving costs. + - We want a mechanism to direct funds towards the treasury.Note: apply the same 2-space nested indentation to other sections called out by the linter (e.g., Lines 79–81, 88–89, 97–99, 106–115, 126–128, 136–145, 159–165, 167–173).
79-81: Align sub-bullets under “Applying the mechanism to the sequencer” with MD007Indent sub-items by 2 spaces to satisfy markdownlint and render consistently.
- - it is simpler. We only need to do one update calculation per publication (rather than for every block) - - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) - - users and sequencers have more flexibility around when and how payments are made. + - it is simpler. We only need to do one update calculation per publication (rather than for every block) + - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) + - users and sequencers have more flexibility around when and how payments are made.
83-90: Optional: clarify “publication costs” estimation vs smoothingConsider a brief sentence explaining whether sequencers quote an ex-ante estimate for publication costs or reconcile ex-post to L1 BLOBBASEFEE/BASEFEE, and how discrepancies are handled. This strengthens the treasury surcharge rationale and wallet UX expectations.
Happy to draft a short paragraph with examples (preconfirmation vs post-publication reconciliation).
101-116: Wallet compatibility section: propose adding a succinct glossary or calloutsDefining “publication”, “proposer”, “sequencer”, and “liveness bond” the first time they appear (or adding a small glossary) will help wallet integrators and non-Taiko readers. Also, consider calling out whether the fee-signalling RPCs are envisioned as standard JSON-RPC methods or separate endpoints.
I can add a “Terminology” box and a draft of potential fee-signalling RPC shapes for discussion.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[grammar] ~7-~7: There might be a mistake here.
Context: ... other network participants can keep up. - technically, the actual resource limits ...
(QB_NEW_EN)
[grammar] ~8-~8: There might be a mistake here.
Context: ... actual limit, to smooth out volatility. - In the L2 case: - there are no relev...
(QB_NEW_EN)
[grammar] ~12-~12: Ensure spelling is correct
Context: ... own account, and may incur significant offchain proving costs. - We want a mechanis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~12-~12: There might be a mistake here.
Context: ...ncur significant offchain proving costs. - We want a mechanism to direct funds towa...
(QB_NEW_EN)
[grammar] ~26-~26: There might be a mistake here.
Context: ...and to maintain a per-second gas target. - sequencers can decided for themselves ho...
(QB_NEW_EN)
[grammar] ~28-~28: There might be a mistake here.
Context: ...n be directed to the treasury or burned. 2. The protocol does not compute or enforce...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...ransaction) and doing a direct transfer. - alternatively, it could be computed as p...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...s part of the state-transition function. 3. Similar to the existing protocol, propos...
(QB_NEW_EN)
[grammar] ~37-~37: There might be a mistake here.
Context: ... to a proposer-specified refund address. - otherwise, whoever proves it gets the li...
(QB_NEW_EN)
[grammar] ~38-~38: There might be a mistake here.
Context: ...hoever proves it gets the liveness bond. - To facilitate enforceable prover/propose...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...he scenario where the base fee is zero). - The L2 address represents a prover, and ...
(QB_NEW_EN)
[grammar] ~46-~46: There might be a mistake here.
Context: ...gned (but this is not enforced) so that: - it sends the liveness bond minus its cho...
(QB_NEW_EN)
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ... actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[grammar] ~59-~59: There might be a mistake here.
Context: ... fee rather than refund the bond amount. - If the validatePublication function fa...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ...ation` interface) and apply a surcharge to sequencer, directed to the treasury (ju...
(QB_NEW_EN)
[grammar] ~70-~70: There might be a mistake here.
Context: ... out of sync with the market conditions. - Moreover, attempting to charge for the w...
(QB_NEW_EN)
[grammar] ~73-~73: There might be a mistake here.
Context: ...hat exploit the discrepancy. ### L2 Gas - As I understand it (although this should...
(QB_NEW_EN)
[grammar] ~75-~75: Ensure spelling is correct
Context: ...uencer may still want to charge for the offchain processing costs, but this can be incor...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~75-~75: There might be a mistake here.
Context: ... costs) associated with the transaction. - However, we probably do want to include ...
(QB_NEW_EN)
[grammar] ~85-~85: There might be a mistake here.
Context: ... other transactions in the publication). - When discussing this idea, one concern w...
(QB_NEW_EN)
[grammar] ~87-~87: There might be a mistake here.
Context: ...ated) publication costs to the treasury. - this doesn't remove the need for sequenc...
(QB_NEW_EN)
[grammar] ~88-~88: There might be a mistake here.
Context: ...tever level of sophistication they have. - If standardisation is preferred, Taiko c...
(QB_NEW_EN)
[grammar] ~93-~93: There might be a mistake here.
Context: ...sequencers can use. ### Proving Costs - Following the same intuitions, if sequen...
(QB_NEW_EN)
[grammar] ~94-~94: There might be a mistake here.
Context: ...entivised to optimise the proving costs. - For example, sequencers can offer discou...
(QB_NEW_EN)
[grammar] ~96-~96: There might be a mistake here.
Context: ...timate proving costs. Anyone is free to: - use a "zk-opcode" method - use L2 ga...
(QB_NEW_EN)
[grammar] ~107-~107: There might be a mistake here.
Context: ...e calculation with some shared provider. - Using total fees - As I've described...
(QB_NEW_EN)
[grammar] ~110-~110: There might be a mistake here.
Context: ...rate_ (not absolute fee) against L2 gas. - As noted, I don't think they should char...
(QB_NEW_EN)
[grammar] ~128-~128: There might be a mistake here.
Context: ...may be worse than poorly specified fees. - If we do go down this path, we should cr...
(QB_NEW_EN)
[grammar] ~138-~138: There might be a mistake here.
Context: ...tial counterarguments (and my response): - this could lead to issues where compute-...
(QB_NEW_EN)
[grammar] ~141-~141: There might be a mistake here.
Context: ...oses a ridiculously high gas fee amount. - I think that risk already exists, becaus...
(QB_NEW_EN)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
[grammar] ~143-~143: There might be a mistake here.
Context: ...ponding to real-world market conditions. - It also lets users and sequencers be mor...
(QB_NEW_EN)
[grammar] ~144-~144: There might be a mistake here.
Context: ...ock charges for regular L2 transactions. - Any feedback on if I'm missing something...
(QB_NEW_EN)
[grammar] ~151-~151: There might be a mistake here.
Context: ...r preference on a per-transaction basis. - We cannot manipulate the L2 block-produc...
(QB_NEW_EN)
[grammar] ~152-~152: Ensure spelling is correct
Context: ...on a per-block basis (which would allow seqeuncers to group data-heavy transactions into t...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~152-~152: There might be a mistake here.
Context: ...es regular block lengths (of 2 seconds). - Overall, this implies that at least for ...
(QB_NEW_EN)
[grammar] ~153-~153: There might be a mistake here.
Context: ...east for now, any solutions must involve - setting the base fee for all transaction...
(QB_NEW_EN)
[grammar] ~154-~154: There might be a mistake here.
Context: ...sactions in a particular 2-second window - be computable from a predetermined formu...
(QB_NEW_EN)
[grammar] ~157-~157: There might be a mistake here.
Context: ...k the cost of the resources it consumes. - Ideally, we should push for more flexibl...
(QB_NEW_EN)
[grammar] ~159-~159: There might be a mistake here.
Context: ...cify how they would like to select fees. - note that this doesn't change anything a...
(QB_NEW_EN)
[grammar] ~161-~161: There might be a mistake here.
Context: ...ty fee as well as the priority fee rate. - wallets will choose the fees they presen...
(QB_NEW_EN)
[grammar] ~162-~162: There might be a mistake here.
Context: ...to the user (before signing) as follows: - if the account has specified an actual f...
(QB_NEW_EN)
[grammar] ~163-~163: There might be a mistake here.
Context: ...tual formula they want to use, use that. - if the account has specified an RPC to c...
(QB_NEW_EN)
[grammar] ~164-~164: There might be a mistake here.
Context: ... has specified an RPC to call, use that. - if the account has not specified a fee-c...
(QB_NEW_EN)
[grammar] ~165-~165: There might be a mistake here.
Context: ...e whatever mechanism they currently use. - Until then, there are two kinds of risks...
(QB_NEW_EN)
[grammar] ~166-~166: There might be a mistake here.
Context: ...there are two kinds of risks that I see: - the best case scenario is that the base ...
(QB_NEW_EN)
[grammar] ~168-~168: There might be a mistake here.
Context: ...o-L2-compute ratios will be underpriced. - such transactions will either be subsidi...
(QB_NEW_EN)
[grammar] ~169-~169: There might be a mistake here.
Context: ...quencer, or will not be included at all. - moreover, sequencers may have to process...
(QB_NEW_EN)
[grammar] ~170-~170: There might be a mistake here.
Context: ...ocally) before deciding to discard them. - the same problem exists for transactions...
(QB_NEW_EN)
[grammar] ~171-~171: There might be a mistake here.
Context: ...erage proving-cost-to-L2-compute ratios. - transactions with lower than average dat...
(QB_NEW_EN)
[grammar] ~172-~172: There might be a mistake here.
Context: ...to-L2-compute ratios will be overpriced. - Note that this doesn't change the treasu...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
154-154: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
155-155: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
156-156: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
159-159: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
160-160: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
161-161: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
162-162: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
163-163: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
164-164: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
165-165: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
167-167: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
168-168: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
169-169: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
170-170: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
171-171: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
172-172: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
| # Taiko Fee Proposal | ||
|
|
||
| ## Overview | ||
| - I have an intuition that some of the L2 fee-pricing challenges are downstream of reusing and modifying the L1 pricing model, which may not be aligned with the economics of L2s. | ||
| - In particular, it seems to me that L1 protocol-enforced-fees are useful to: | ||
| - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. | ||
| - limit the total resource consumption to a level where other network participants can keep up. | ||
| - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility. | ||
| - In the L2 case: | ||
| - there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes so there are no actual "costs to the network". | ||
| - L2 sequencers have to pay L1 publication costs out of their own account. | ||
| - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. | ||
| - We want a mechanism to direct funds towards the treasury. | ||
| - I believe attempting to combine the relevant fees into an L2 base fee is unnecessarily complicated and distorts the market, which leads to attacks and complications. | ||
| - Instead, we should analyse the dynamics of each resource independently. | ||
|
|
||
| ## Proposal | ||
|
|
||
| I will first describe my suggested proposal, and then explain the rationale. | ||
|
|
||
|
|
||
| 1. L2 gas should only cover L2 execution. There are two options: | ||
| - use the existing EIP1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. | ||
| - charge for publications (not transactions): | ||
| - set the base fee to zero | ||
| - use an EIP1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. | ||
| - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. | ||
| - some or all of the protocol fee can be directed to the treasury or burned. | ||
| 2. The protocol does not compute or enforce any L1 data fee requirements. | ||
| - Sequencers pay the L1 publishing costs to the L1 network. | ||
| - They decide for themselves how to charge users for L1 costs. | ||
| - The inbox should save the number of blobs used, `BLOBBASEFEE` and `BASEFEE` with the publication. This can be used to compute the L1 costs, so a surcharge percentage can be deducted from the sequencer (on L2) and sent to the treasury. | ||
| - this could be handled inside the L2 EVM by injecting those values (in the anchor or end-of-publication transaction) and doing a direct transfer. | ||
| - alternatively, it could be computed as part of the state-transition function. | ||
| 3. Similar to the existing protocol, proposers must post a liveness bond with each publication. | ||
| - The protocol will guarantee: | ||
| - if the publication is proven in time, the liveness bond is sent to a proposer-specified refund address. | ||
| - otherwise, whoever proves it gets the liveness bond. | ||
| - To facilitate enforceable prover/proposer commitments (like an [auction mechanism](https://github.com/OpenZeppelin/minimal-rollup/blob/main/src/protocol/BaseProverManager.sol)), the protocol could: | ||
| - allow an optional special transaction (at the start or end of the publication) that calls `validatePublication` on an arbitrary L2 address chosen by the proposer and passes: | ||
| - the refund address on L1 | ||
| - a hash of the transactions in the publication | ||
| - an arbitrary buffer containing any relevant additional information | ||
| - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post) that these values are set correctly (or the publication defaults to an empty block). | ||
| - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH and consumes L2 gas (which may be free for the proposer in the scenario where the base fee is zero). | ||
| - The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: | ||
| - it sends the liveness bond minus its chosen fee to the proposer | ||
| - it ensures the L1 refund address belongs to the prover | ||
| - In this way | ||
| - the prover contract can decide how much to charge for the particular publication using whatever rules it wants | ||
| - any proposer can accept the deal by constructing a publication that invokes this prover contract | ||
| - in the happy case | ||
| - the proposer paid the L1 liveness bond, which will be sent to the prover | ||
| - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. | ||
| - in the unhappy case | ||
| - the proposer still pays the proving fee (in effect) | ||
| - the specified prover pays the rest of the liveness bond as a penalty | ||
| - both amounts are given to the actual prover | ||
| - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. | ||
| - If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. | ||
| - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. | ||
|
|
||
| Note that under this design, the costs for a publication are self-contained, so delayed publications can be treated like regular publications. | ||
|
|
||
| ## Rationale | ||
|
|
||
| ### Overall Intuition | ||
|
|
||
| - The goal is to reflect the real-world costs as faithfully as possible. | ||
| - Any opinionated pricing formulas enforced by the protocol, particularly ones that rely on empirically-derived parameters (like average transaction sizes), can get out of sync with the market conditions. | ||
| - Moreover, attempting to charge for the wrong resource (eg. L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy. | ||
|
|
||
| ### L2 Gas | ||
| - As I understand it (although this should be validated), since there is no security reason to encourage users to run L2 nodes, we do not need to charge for "costs to the L2 network". This means the L2 gas fee can be set to zero. | ||
| - The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. | ||
| - However, we probably do want to include an overall gas limit to ensure that other users can keep up with the chain. I suspect it can be large enough that it is never reached in practice (because the publication and proving cost limits will likely be reached first), but it is still necessary to prevent malicious compute-only transactions (like running an infinite loop). | ||
| - Once we've decided to include a limit, I think it also makes sense to have a smaller target, so that unexpected volatility does not create immediate scarcity (and correspondingly very high prices). The EIP1559 mechanism seems like a good way to regulate this. | ||
| - However, applying the mechanism to the sequencer (instead of the transactions) has some benefits: | ||
| - it is simpler. We only need to do one update calculation per publication (rather than for every block) | ||
| - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) | ||
| - users and sequencers have more flexibility around when and how payments are made. | ||
|
|
||
| ### Publication Costs | ||
| - Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. | ||
| - Moreover, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). | ||
| - When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. | ||
| - With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. | ||
| - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. | ||
| - If standardisation is preferred, Taiko could still create a suggested fee formula that sequencers can use. | ||
|
|
||
|
|
||
|
|
||
| ### Proving Costs | ||
| - Following the same intuitions, if sequencers compensate provers at whatever rate they agree, then sequencers and users are incentivised to optimise the proving costs. | ||
| - For example, sequencers can offer discounts for transactions that are easy to prove. | ||
| - This also lets Taiko be maximally flexible about the best way to estimate proving costs. Anyone is free to: | ||
| - use a "zk-opcode" method | ||
| - use L2 gas as a proxy for proving costs | ||
| - invent a new method specialised for their proving hardware. | ||
|
|
||
| ## Wallet compatibility | ||
|
|
||
| There are two challenges that I think will need to be addressed, and may depend on the cooperation of wallet developers: | ||
|
|
||
| - Fee discovery | ||
| - Sequencers will need a way to signal to wallets how much they would charge for a given transaction | ||
| - I'm not sure how this works in practice, and whether wallets can change which endpoint they query based on who the next sequencer is, or if sequencers can register their fee calculation with some shared provider. | ||
| - Using total fees | ||
| - As I've described the mechanism, the transactions will pay some base fee (possibly zero) associated with the L2 gas execution, and should also specify a priority fee to account for the other charges | ||
| - However, current transaction types require them to specify a _priority fee rate_ (not absolute fee) against L2 gas. | ||
| - As noted, I don't think they should charge per unit of L2 gas execution, so they will need to compute the total fee and then divide it by the actual gas consumed. | ||
| - Unfortunately, users do not necessarily know exactly how much gas will be consumed when constructing the transaction because that might depend on if any other transactions change the state before this transaction is sequenced. | ||
| - Ideally, this would be solved with a new transaction type, allowing users to specify the total priority fee. | ||
| - Until then, sequencers will need to simulate the transaction to determine the actual gas consumed, and only then can they figure out whether the priority fee will be sufficient. | ||
| - They could also use a wrapper smart contract that first executes the transaction and then consumes the remaining gas so that the transaction gas limit would be equivalent to the actual gas consumed, but this seems pretty hacky. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| - To address the question of wallet compatibility, I should get familiar with how wallets choose fees and display them to users. At this point I do not have enough background to understand claims about whether it is or is not possible. | ||
| - I will be offline for a few days, but in the mean time, I think it might be worthwhile to consider alternatives, to provoke a discussion and better pinpoint exactly what the constraints are. | ||
|
|
||
| ### Independent L2 charges | ||
|
|
||
| - If we cannot use priority fees (or it is too difficult to use the priority fee rate), my preference is to use an external L2 mechanism to charge the fee. | ||
| - For example: | ||
| - sequencers could require all transactions to go to a wrapper contract that extracts fees (potentially in tokens) as part of the user operation | ||
| - sequencers could require users to create independent transactions that pay the fees directly | ||
| - This is a minor preference because the annoyance of having an external mechanism may be worse than poorly specified fees. | ||
| - If we do go down this path, we should create a standard default mechanism (eg. a standard wrapper contract) to minimize inconsistencies. | ||
|
|
||
| ### Sequencer chosen base rate | ||
|
|
||
| - If we do decide to use the L2 base fee for all charges, it's not clear to me why Taiko needs to be opinionated about the amount. | ||
| - Can we just let sequencers pick an arbitrary base fee for their blocks, disconnected from whatever else is happening in the protocol? | ||
| - My rationale is: | ||
| - as noted, we do not need to ensure they cover "costs to the network" | ||
| - this is another way of letting users and sequencers negotiate a market price, based on the realtime expected costs | ||
| - Potential counterarguments (and my response): | ||
| - this could lead to issues where compute-heavy transactions subsidize the data-heavy transactions | ||
| - I think that's a consequence of charging the same base fee for all transactions, and charging for each computational step. As far as I can tell, it's not worsened by choosing any specific number. | ||
| - this may allow wide price swings between publications if some sequencer chooses a ridiculously high gas fee amount. | ||
| - I think that risk already exists, because sequencers can demand high priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with is going to be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits | ||
| - On the other hand, the ability to allow massive price swings may actually just be sequencers responding to real-world market conditions. | ||
| - It also lets users and sequencers be more creative about how to arrive at the correct charge given the base-fee constraint. For example, the sequencer could include all data-heavy transactions in a block with a high base fee (to indirectly charge for the L1 blobs), and then go back to regular block charges for regular L2 transactions. | ||
| - Any feedback on if I'm missing something would be appreciated. | ||
|
|
||
|
|
||
| ## Resolution | ||
|
|
||
| - As I understand it, this recommendation is not possible for Taiko because existing wallets do not have standard RPCs for fetching priority fees. | ||
| - Moreover, we cannot use the "Sequencer chosen base rate" alternative, because (most) wallets compute the base fee from internal node logic, so there is no place for the current sequencer to inject their preference on a per-transaction basis. | ||
| - We cannot manipulate the L2 block-producing mechanism to change the base fee arbitrarily on a per-block basis (which would allow seqeuncers to group data-heavy transactions into the same block) because the preconfirmation mechanism now enforces regular block lengths (of 2 seconds). | ||
| - Overall, this implies that at least for now, any solutions must involve | ||
| - setting the base fee for all transactions in a particular 2-second window | ||
| - be computable from a predetermined formula | ||
| - be charged against L2 computational steps | ||
| - As noted already, this means the fee will not correctly track the cost of the resources it consumes. | ||
| - Ideally, we should push for more flexible fee-choosing mechanisms, particularly for the priority fee. My preference is: | ||
| - accounts should be able to specify how they would like to select fees. | ||
| - note that this doesn't change anything about what fees are enforced by the protocol. L1 must still charge gas fees as a proxy for network costs, but L2s could set the base fee to zero. | ||
| - they should be able to specify a total priority fee as well as the priority fee rate. | ||
| - wallets will choose the fees they present to the user (before signing) as follows: | ||
| - if the account has specified an actual formula they want to use, use that. | ||
| - if the account has specified an RPC to call, use that. | ||
| - if the account has not specified a fee-choosing mechanism, use whatever mechanism they currently use. | ||
| - Until then, there are two kinds of risks that I see: | ||
| - the best case scenario is that the base fee correctly tracks the overall cost for average transactions. However, sequencers can only signal desired changes for future publications, which distorts the incentive to get it right, particularly for a diverse set of sequencers. | ||
| - transactions with higher than average data-to-L2-compute ratios will be underpriced. | ||
| - such transactions will either be subsidized by the sequencer, or will not be included at all. | ||
| - moreover, sequencers may have to process these transactions (since the actual gas consumed will be unknown until it is executed locally) before deciding to discard them. | ||
| - the same problem exists for transactions with higher than average proving-cost-to-L2-compute ratios. | ||
| - transactions with lower than average data-to-L2-compute or proving-cost-to-L2-compute ratios will be overpriced. | ||
| - Note that this doesn't change the treasury fee analysis. I still believe that Taiko can direct a fraction of the measured L1 costs to the treasury, instead of (or in addition to) the base fee fraction. No newline at end of file |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Quick grep to prevent regressions and catch remaining nits
Run this lightweight check to ensure no remaining problematic tokens slip through (e.g., “EIP1559”, “seqeuncers”, “offchain”, “L1 / L2”).
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="documentation/Taiko Fee Proposal.md"
echo "Scanning for common typos and style nits…"
rg -n "EIP1559|seqeuncers|offchain|L1\s*/\s*L2" "$file" || true
echo
echo "Occurrences of EIP-1559 (canonical):"
rg -n "EIP-1559" "$file" || true
echo
echo "Check validatePublication mentions:"
rg -n "validatePublication" "$file" -n -C1 || true
echo
echo "List indentation anomalies (lines starting with 3+ spaces before a bullet):"
rg -nP '^\s{3,}-\s' "$file" -n || trueLength of output: 16765
Cleanup style nits in documentation/Taiko Fee Proposal.md
Please address the following before merging:
- Canonicalize “EIP-1559”: replace all
EIP1559occurrences (lines 23, 26, 77, 86) withEIP-1559. - Fix typo
seqeuncers→sequencers(line 152). - Hyphenate “off-chain” instead of
offchain(line 12). - Standardize L1/L2 formatting: change any
L1 / L2(line 59) toL1/L2. - Normalize list indentation: use consistent two-space indents per level; remove any 3+-space bullet indents.
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: There might be a mistake here.
Context: ... other network participants can keep up. - technically, the actual resource limits ...
(QB_NEW_EN)
[grammar] ~8-~8: There might be a mistake here.
Context: ... actual limit, to smooth out volatility. - In the L2 case: - there are no relev...
(QB_NEW_EN)
[grammar] ~12-~12: Ensure spelling is correct
Context: ... own account, and may incur significant offchain proving costs. - We want a mechanis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~12-~12: There might be a mistake here.
Context: ...ncur significant offchain proving costs. - We want a mechanism to direct funds towa...
(QB_NEW_EN)
[grammar] ~26-~26: There might be a mistake here.
Context: ...and to maintain a per-second gas target. - sequencers can decided for themselves ho...
(QB_NEW_EN)
[grammar] ~28-~28: There might be a mistake here.
Context: ...n be directed to the treasury or burned. 2. The protocol does not compute or enforce...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...ransaction) and doing a direct transfer. - alternatively, it could be computed as p...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...s part of the state-transition function. 3. Similar to the existing protocol, propos...
(QB_NEW_EN)
[grammar] ~37-~37: There might be a mistake here.
Context: ... to a proposer-specified refund address. - otherwise, whoever proves it gets the li...
(QB_NEW_EN)
[grammar] ~38-~38: There might be a mistake here.
Context: ...hoever proves it gets the liveness bond. - To facilitate enforceable prover/propose...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...he scenario where the base fee is zero). - The L2 address represents a prover, and ...
(QB_NEW_EN)
[grammar] ~46-~46: There might be a mistake here.
Context: ...gned (but this is not enforced) so that: - it sends the liveness bond minus its cho...
(QB_NEW_EN)
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ... actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[grammar] ~59-~59: There might be a mistake here.
Context: ... fee rather than refund the bond amount. - If the validatePublication function fa...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ...ation` interface) and apply a surcharge to sequencer, directed to the treasury (ju...
(QB_NEW_EN)
[grammar] ~70-~70: There might be a mistake here.
Context: ... out of sync with the market conditions. - Moreover, attempting to charge for the w...
(QB_NEW_EN)
[grammar] ~73-~73: There might be a mistake here.
Context: ...hat exploit the discrepancy. ### L2 Gas - As I understand it (although this should...
(QB_NEW_EN)
[grammar] ~75-~75: Ensure spelling is correct
Context: ...uencer may still want to charge for the offchain processing costs, but this can be incor...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~75-~75: There might be a mistake here.
Context: ... costs) associated with the transaction. - However, we probably do want to include ...
(QB_NEW_EN)
[grammar] ~85-~85: There might be a mistake here.
Context: ... other transactions in the publication). - When discussing this idea, one concern w...
(QB_NEW_EN)
[grammar] ~87-~87: There might be a mistake here.
Context: ...ated) publication costs to the treasury. - this doesn't remove the need for sequenc...
(QB_NEW_EN)
[grammar] ~88-~88: There might be a mistake here.
Context: ...tever level of sophistication they have. - If standardisation is preferred, Taiko c...
(QB_NEW_EN)
[grammar] ~93-~93: There might be a mistake here.
Context: ...sequencers can use. ### Proving Costs - Following the same intuitions, if sequen...
(QB_NEW_EN)
[grammar] ~94-~94: There might be a mistake here.
Context: ...entivised to optimise the proving costs. - For example, sequencers can offer discou...
(QB_NEW_EN)
[grammar] ~96-~96: There might be a mistake here.
Context: ...timate proving costs. Anyone is free to: - use a "zk-opcode" method - use L2 ga...
(QB_NEW_EN)
[grammar] ~107-~107: There might be a mistake here.
Context: ...e calculation with some shared provider. - Using total fees - As I've described...
(QB_NEW_EN)
[grammar] ~110-~110: There might be a mistake here.
Context: ...rate_ (not absolute fee) against L2 gas. - As noted, I don't think they should char...
(QB_NEW_EN)
[grammar] ~128-~128: There might be a mistake here.
Context: ...may be worse than poorly specified fees. - If we do go down this path, we should cr...
(QB_NEW_EN)
[grammar] ~138-~138: There might be a mistake here.
Context: ...tial counterarguments (and my response): - this could lead to issues where compute-...
(QB_NEW_EN)
[grammar] ~141-~141: There might be a mistake here.
Context: ...oses a ridiculously high gas fee amount. - I think that risk already exists, becaus...
(QB_NEW_EN)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
[grammar] ~143-~143: There might be a mistake here.
Context: ...ponding to real-world market conditions. - It also lets users and sequencers be mor...
(QB_NEW_EN)
[grammar] ~144-~144: There might be a mistake here.
Context: ...ock charges for regular L2 transactions. - Any feedback on if I'm missing something...
(QB_NEW_EN)
[grammar] ~151-~151: There might be a mistake here.
Context: ...r preference on a per-transaction basis. - We cannot manipulate the L2 block-produc...
(QB_NEW_EN)
[grammar] ~152-~152: Ensure spelling is correct
Context: ...on a per-block basis (which would allow seqeuncers to group data-heavy transactions into t...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~152-~152: There might be a mistake here.
Context: ...es regular block lengths (of 2 seconds). - Overall, this implies that at least for ...
(QB_NEW_EN)
[grammar] ~153-~153: There might be a mistake here.
Context: ...east for now, any solutions must involve - setting the base fee for all transaction...
(QB_NEW_EN)
[grammar] ~154-~154: There might be a mistake here.
Context: ...sactions in a particular 2-second window - be computable from a predetermined formu...
(QB_NEW_EN)
[grammar] ~157-~157: There might be a mistake here.
Context: ...k the cost of the resources it consumes. - Ideally, we should push for more flexibl...
(QB_NEW_EN)
[grammar] ~159-~159: There might be a mistake here.
Context: ...cify how they would like to select fees. - note that this doesn't change anything a...
(QB_NEW_EN)
[grammar] ~161-~161: There might be a mistake here.
Context: ...ty fee as well as the priority fee rate. - wallets will choose the fees they presen...
(QB_NEW_EN)
[grammar] ~162-~162: There might be a mistake here.
Context: ...to the user (before signing) as follows: - if the account has specified an actual f...
(QB_NEW_EN)
[grammar] ~163-~163: There might be a mistake here.
Context: ...tual formula they want to use, use that. - if the account has specified an RPC to c...
(QB_NEW_EN)
[grammar] ~164-~164: There might be a mistake here.
Context: ... has specified an RPC to call, use that. - if the account has not specified a fee-c...
(QB_NEW_EN)
[grammar] ~165-~165: There might be a mistake here.
Context: ...e whatever mechanism they currently use. - Until then, there are two kinds of risks...
(QB_NEW_EN)
[grammar] ~166-~166: There might be a mistake here.
Context: ...there are two kinds of risks that I see: - the best case scenario is that the base ...
(QB_NEW_EN)
[grammar] ~168-~168: There might be a mistake here.
Context: ...o-L2-compute ratios will be underpriced. - such transactions will either be subsidi...
(QB_NEW_EN)
[grammar] ~169-~169: There might be a mistake here.
Context: ...quencer, or will not be included at all. - moreover, sequencers may have to process...
(QB_NEW_EN)
[grammar] ~170-~170: There might be a mistake here.
Context: ...ocally) before deciding to discard them. - the same problem exists for transactions...
(QB_NEW_EN)
[grammar] ~171-~171: There might be a mistake here.
Context: ...erage proving-cost-to-L2-compute ratios. - transactions with lower than average dat...
(QB_NEW_EN)
[grammar] ~172-~172: There might be a mistake here.
Context: ...to-L2-compute ratios will be overpriced. - Note that this doesn't change the treasu...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
154-154: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
155-155: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
156-156: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
159-159: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
160-160: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
161-161: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
162-162: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
163-163: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
164-164: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
165-165: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
167-167: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
168-168: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
169-169: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
170-170: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
171-171: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
172-172: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🤖 Prompt for AI Agents
In documentation/Taiko Fee Proposal.md around lines 1-173, clean up style nits:
replace every occurrence of "EIP1559" with "EIP-1559" (noted at ~23,26,77,86),
correct the typo "seqeuncers" to "sequencers" (line ~152), change "offchain" to
"off-chain" (line ~12), convert any "L1 / L2" to "L1/L2" (line ~59), and
normalize all markdown list indentation to use consistent two-space indents per
level (remove any bullets indented with 3+ spaces).
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (11)
documentation/Taiko Fee Proposal.md (11)
27-27: Grammar fix: “decided” → “decide”; minor readability polishThe sentence has subject-verb mismatch and could use light punctuation cleanup.
- - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. + - sequencers can decide for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case, they would use the L2 priority fee, but users with no ETH could also pay in other tokens, or MEV‑rich transactions could be subsidized. The protocol remains unopinionated about how sequencers charge users as long as the sequencer pays the protocol.
12-12: Hyphenate “offchain” → “off-chain”Standardize to the hyphenated form.
- - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. + - L2 provers have to pay L1 proving costs out of their own account, and may incur significant off-chain proving costs.-- The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. +- The sequencer may still want to charge for the off-chain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction.Also applies to: 75-75
59-59: Replace “L1 / L2” with “L1 and L2” (or “L1/L2”)Avoid slashes in prose; improves clarity and satisfies style linters.
- - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. + - We could avoid actually transferring funds between L1 and L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount.
88-88: Spell “realtime” as “real time” (or “real-time” when adjectival)Use “in real time” in these contexts.
- - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. + - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in real time with whatever level of sophistication they have.- - this is another way of letting users and sequencers negotiate a market price, based on the realtime expected costs + - this is another way of letting users and sequencers negotiate a market price, based on the real-time expected costsAlso applies to: 137-137
71-71: Use “e.g.” instead of “eg.” and include a comma when starting a clauseMinor technical-writing nit.
-- Moreover, attempting to charge for the wrong resource (eg. L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy. +- Moreover, attempting to charge for the wrong resource (e.g., L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy.-- If we do go down this path, we should create a standard default mechanism (eg. a standard wrapper contract) to minimize inconsistencies. +- If we do go down this path, we should create a standard default mechanism (e.g., a standard wrapper contract) to minimize inconsistencies.Also applies to: 129-129
21-21: Define “publication” up front to align with Taiko terminologyAdd a short terminology note after introducing the Proposal so readers map “publication” to existing Taiko concepts (“batch” / “block”) and reduce ambiguity with “transaction”.
I will first describe my suggested proposal, and then explain the rationale. +> Terminology: In this document, “publication” refers to the batch of L2 transactions a sequencer posts and finalizes (often called a “batch” or “block” in Taiko docs). It is distinct from an individual user transaction.
44-44: Link the “generic assertions post” for the “consistency hash” referenceProvide a concrete URL so readers can evaluate the mechanism.
If you share the intended reference, I can add the exact link and cross-check nomenclature matches.
59-61: Security considerations for the “flash-loan-like refund address” approachThis mechanism implies temporary fronting of L1 funds and settlement on L2. Please add a “Security considerations” note covering:
- Replay/rollback handling if L1/L2 finality diverges during the operation.
- Reentrancy/griefing risks around the L2 prover contract “retrieving” fees.
- How you prevent proposer/prover collusion to siphon the bond (e.g., via alternate side payments).
I can draft a short “Security considerations” subsection if helpful.
23-29: Request: cite or restate the corrected EIP-1559 update rule for variable-length blocksThe parenthetical link is helpful; consider inlining the exact adjustment (variables, target, update coefficient) so the doc is self-contained and reviewers can sanity-check with no context switching.
I can add a compact equation block with symbols (baseFee, targetGasPerSecond, elasticity, etc.) reflecting your intended control loop.
101-116: Wallet compatibility section: propose concrete discovery and quoting flowsThe section raises the right risks. To drive actionable next steps, suggest specifying:
- A sequencer fee-quote RPC shape (request/response fields, signature binding to sequencer identity, expiry).
- Handling for multi-token quotes and L2-priority-fee-as-total-fee mapping.
- Simulation source of truth (which node, fork config) and dispute resolution if gas used deviates.
Happy to draft an example JSON-RPC method (e.g., taiko_getSequencerQuote) with fields and validation requirements.
133-146: US vs UK spelling: pick one variant and standardizeOccurrences include “optimised/standardisation/specialised” (UK) vs “optimized/standardization/specialized” (US). Choose one house style and apply consistently across the doc and repo.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
documentation/Taiko Fee Proposal.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
documentation/Taiko Fee Proposal.md
[grammar] ~7-~7: There might be a mistake here.
Context: ... other network participants can keep up. - technically, the actual resource limits ...
(QB_NEW_EN)
[grammar] ~8-~8: There might be a mistake here.
Context: ... actual limit, to smooth out volatility. - In the L2 case: - there are no relev...
(QB_NEW_EN)
[grammar] ~12-~12: Ensure spelling is correct
Context: ... own account, and may incur significant offchain proving costs. - We want a mechanis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~12-~12: There might be a mistake here.
Context: ...ncur significant offchain proving costs. - We want a mechanism to direct funds towa...
(QB_NEW_EN)
[grammar] ~26-~26: There might be a mistake here.
Context: ...and to maintain a per-second gas target. - sequencers can decided for themselves ho...
(QB_NEW_EN)
[grammar] ~28-~28: There might be a mistake here.
Context: ...n be directed to the treasury or burned. 2. The protocol does not compute or enforce...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...ransaction) and doing a direct transfer. - alternatively, it could be computed as p...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...s part of the state-transition function. 3. Similar to the existing protocol, propos...
(QB_NEW_EN)
[grammar] ~37-~37: There might be a mistake here.
Context: ... to a proposer-specified refund address. - otherwise, whoever proves it gets the li...
(QB_NEW_EN)
[grammar] ~38-~38: There might be a mistake here.
Context: ...hoever proves it gets the liveness bond. - To facilitate enforceable prover/propose...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...he scenario where the base fee is zero). - The L2 address represents a prover, and ...
(QB_NEW_EN)
[grammar] ~46-~46: There might be a mistake here.
Context: ...gned (but this is not enforced) so that: - it sends the liveness bond minus its cho...
(QB_NEW_EN)
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ... actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[grammar] ~59-~59: There might be a mistake here.
Context: ... fee rather than refund the bond amount. - If the validatePublication function fa...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ...ation` interface) and apply a surcharge to sequencer, directed to the treasury (ju...
(QB_NEW_EN)
[grammar] ~70-~70: There might be a mistake here.
Context: ... out of sync with the market conditions. - Moreover, attempting to charge for the w...
(QB_NEW_EN)
[grammar] ~73-~73: There might be a mistake here.
Context: ...hat exploit the discrepancy. ### L2 Gas - As I understand it (although this should...
(QB_NEW_EN)
[grammar] ~75-~75: Ensure spelling is correct
Context: ...uencer may still want to charge for the offchain processing costs, but this can be incor...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~75-~75: There might be a mistake here.
Context: ... costs) associated with the transaction. - However, we probably do want to include ...
(QB_NEW_EN)
[grammar] ~85-~85: There might be a mistake here.
Context: ... other transactions in the publication). - When discussing this idea, one concern w...
(QB_NEW_EN)
[grammar] ~87-~87: There might be a mistake here.
Context: ...ated) publication costs to the treasury. - this doesn't remove the need for sequenc...
(QB_NEW_EN)
[grammar] ~88-~88: There might be a mistake here.
Context: ...tever level of sophistication they have. - If standardisation is preferred, Taiko c...
(QB_NEW_EN)
[grammar] ~93-~93: There might be a mistake here.
Context: ...sequencers can use. ### Proving Costs - Following the same intuitions, if sequen...
(QB_NEW_EN)
[grammar] ~94-~94: There might be a mistake here.
Context: ...entivised to optimise the proving costs. - For example, sequencers can offer discou...
(QB_NEW_EN)
[grammar] ~96-~96: There might be a mistake here.
Context: ...timate proving costs. Anyone is free to: - use a "zk-opcode" method - use L2 ga...
(QB_NEW_EN)
[grammar] ~107-~107: There might be a mistake here.
Context: ...e calculation with some shared provider. - Using total fees - As I've described...
(QB_NEW_EN)
[grammar] ~110-~110: There might be a mistake here.
Context: ...rate_ (not absolute fee) against L2 gas. - As noted, I don't think they should char...
(QB_NEW_EN)
[grammar] ~128-~128: There might be a mistake here.
Context: ...may be worse than poorly specified fees. - If we do go down this path, we should cr...
(QB_NEW_EN)
[grammar] ~138-~138: There might be a mistake here.
Context: ...tial counterarguments (and my response): - this could lead to issues where compute-...
(QB_NEW_EN)
[grammar] ~141-~141: There might be a mistake here.
Context: ...oses a ridiculously high gas fee amount. - I think that risk already exists, becaus...
(QB_NEW_EN)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
[grammar] ~143-~143: There might be a mistake here.
Context: ...ponding to real-world market conditions. - It also lets users and sequencers be mor...
(QB_NEW_EN)
[grammar] ~144-~144: There might be a mistake here.
Context: ...ock charges for regular L2 transactions. - Any feedback on if I'm missing something...
(QB_NEW_EN)
[grammar] ~151-~151: There might be a mistake here.
Context: ...r preference on a per-transaction basis. - We cannot manipulate the L2 block-produc...
(QB_NEW_EN)
[grammar] ~153-~153: There might be a mistake here.
Context: ...east for now, any solutions must involve - setting the base fee for all transaction...
(QB_NEW_EN)
[grammar] ~154-~154: There might be a mistake here.
Context: ...sactions in a particular 2-second window - be computable from a predetermined formu...
(QB_NEW_EN)
[grammar] ~157-~157: There might be a mistake here.
Context: ...k the cost of the resources it consumes. - Ideally, we should push for more flexibl...
(QB_NEW_EN)
[grammar] ~159-~159: There might be a mistake here.
Context: ...cify how they would like to select fees. - note that this doesn't change anything a...
(QB_NEW_EN)
[grammar] ~161-~161: There might be a mistake here.
Context: ...ty fee as well as the priority fee rate. - wallets will choose the fees they presen...
(QB_NEW_EN)
[grammar] ~162-~162: There might be a mistake here.
Context: ...to the user (before signing) as follows: - if the account has specified an actual f...
(QB_NEW_EN)
[grammar] ~163-~163: There might be a mistake here.
Context: ...tual formula they want to use, use that. - if the account has specified an RPC to c...
(QB_NEW_EN)
[grammar] ~164-~164: There might be a mistake here.
Context: ... has specified an RPC to call, use that. - if the account has not specified a fee-c...
(QB_NEW_EN)
[grammar] ~165-~165: There might be a mistake here.
Context: ...e whatever mechanism they currently use. - Until then, there are two kinds of risks...
(QB_NEW_EN)
[grammar] ~166-~166: There might be a mistake here.
Context: ...there are two kinds of risks that I see: - the best case scenario is that the base ...
(QB_NEW_EN)
[grammar] ~168-~168: There might be a mistake here.
Context: ...o-L2-compute ratios will be underpriced. - such transactions will either be subsidi...
(QB_NEW_EN)
[grammar] ~169-~169: There might be a mistake here.
Context: ...quencer, or will not be included at all. - moreover, sequencers may have to process...
(QB_NEW_EN)
[grammar] ~170-~170: There might be a mistake here.
Context: ...ocally) before deciding to discard them. - the same problem exists for transactions...
(QB_NEW_EN)
[grammar] ~171-~171: There might be a mistake here.
Context: ...erage proving-cost-to-L2-compute ratios. - transactions with lower than average dat...
(QB_NEW_EN)
[grammar] ~172-~172: There might be a mistake here.
Context: ...to-L2-compute ratios will be overpriced. - Note that this doesn't change the treasu...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
documentation/Taiko Fee Proposal.md
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
154-154: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
155-155: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
156-156: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
159-159: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
160-160: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
161-161: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
162-162: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
163-163: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
164-164: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
165-165: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
167-167: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
168-168: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
169-169: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
170-170: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
171-171: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
172-172: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🔇 Additional comments (2)
documentation/Taiko Fee Proposal.md (2)
1-173: Well-structured and thought-through proposalClear separation of concerns (L2 execution vs L1 publication vs proving), concrete levers for treasury, and pragmatic wallet considerations. With the minor wording/style fixes and a small “Security considerations” subsection, this will read crisply.
32-35: Ensure BLOBBASEFEE/BASEFEE availability and clearly define surcharge computationI don’t see any references or definitions of
BLOBBASEFEEorBASEFEEin the codebase (only in the proposal doc), so we need to verify and wire up the actual opcode values and persistence logic before relying on them:• Confirm that post-Dencun the EVM exposes both fee opcodes in your execution context
• Decide where to persist them (calldata vs. logs vs. contract storage)—weigh gas cost, auditability, and replay protection
• Specify exactly where and when the treasury surcharge is calculated and transferred (e.g. in the anchor tx vs. in the STF) to avoid reorg/MEV risksPlease update the implementation plan (and code) to define the opcode handlers for these fees, persist their values, and inject the surcharge at a deterministic point.
| # Taiko Fee Proposal | ||
|
|
||
| ## Overview | ||
| - I have an intuition that some of the L2 fee-pricing challenges are downstream of reusing and modifying the L1 pricing model, which may not be aligned with the economics of L2s. | ||
| - In particular, it seems to me that L1 protocol-enforced-fees are useful to: | ||
| - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. | ||
| - limit the total resource consumption to a level where other network participants can keep up. | ||
| - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility. | ||
| - In the L2 case: | ||
| - there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes so there are no actual "costs to the network". | ||
| - L2 sequencers have to pay L1 publication costs out of their own account. | ||
| - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. | ||
| - We want a mechanism to direct funds towards the treasury. | ||
| - I believe attempting to combine the relevant fees into an L2 base fee is unnecessarily complicated and distorts the market, which leads to attacks and complications. | ||
| - Instead, we should analyse the dynamics of each resource independently. | ||
|
|
||
| ## Proposal | ||
|
|
||
| I will first describe my suggested proposal, and then explain the rationale. | ||
|
|
||
|
|
||
| 1. L2 gas should only cover L2 execution. There are two options: | ||
| - use the existing EIP-1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. | ||
| - charge for publications (not transactions): | ||
| - set the base fee to zero | ||
| - use an EIP-1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. | ||
| - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. | ||
| - some or all of the protocol fee can be directed to the treasury or burned. | ||
| 2. The protocol does not compute or enforce any L1 data fee requirements. | ||
| - Sequencers pay the L1 publishing costs to the L1 network. | ||
| - They decide for themselves how to charge users for L1 costs. | ||
| - The inbox should save the number of blobs used, `BLOBBASEFEE` and `BASEFEE` with the publication. This can be used to compute the L1 costs, so a surcharge percentage can be deducted from the sequencer (on L2) and sent to the treasury. | ||
| - this could be handled inside the L2 EVM by injecting those values (in the anchor or end-of-publication transaction) and doing a direct transfer. | ||
| - alternatively, it could be computed as part of the state-transition function. | ||
| 3. Similar to the existing protocol, proposers must post a liveness bond with each publication. | ||
| - The protocol will guarantee: | ||
| - if the publication is proven in time, the liveness bond is sent to a proposer-specified refund address. | ||
| - otherwise, whoever proves it gets the liveness bond. | ||
| - To facilitate enforceable prover/proposer commitments (like an [auction mechanism](https://github.com/OpenZeppelin/minimal-rollup/blob/main/src/protocol/BaseProverManager.sol)), the protocol could: | ||
| - allow an optional special transaction (at the start or end of the publication) that calls `validatePublication` on an arbitrary L2 address chosen by the proposer and passes: | ||
| - the refund address on L1 | ||
| - a hash of the transactions in the publication | ||
| - an arbitrary buffer containing any relevant additional information | ||
| - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post) that these values are set correctly (or the publication defaults to an empty block). | ||
| - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH and consumes L2 gas (which may be free for the proposer in the scenario where the base fee is zero). | ||
| - The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: | ||
| - it sends the liveness bond minus its chosen fee to the proposer | ||
| - it ensures the L1 refund address belongs to the prover | ||
| - In this way | ||
| - the prover contract can decide how much to charge for the particular publication using whatever rules it wants | ||
| - any proposer can accept the deal by constructing a publication that invokes this prover contract | ||
| - in the happy case | ||
| - the proposer paid the L1 liveness bond, which will be sent to the prover | ||
| - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. | ||
| - in the unhappy case | ||
| - the proposer still pays the proving fee (in effect) | ||
| - the specified prover pays the rest of the liveness bond as a penalty | ||
| - both amounts are given to the actual prover | ||
| - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. | ||
| - If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. | ||
| - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. | ||
|
|
||
| Note that under this design, the costs for a publication are self-contained, so delayed publications can be treated like regular publications. | ||
|
|
||
| ## Rationale | ||
|
|
||
| ### Overall Intuition | ||
|
|
||
| - The goal is to reflect the real-world costs as faithfully as possible. | ||
| - Any opinionated pricing formulas enforced by the protocol, particularly ones that rely on empirically-derived parameters (like average transaction sizes), can get out of sync with the market conditions. | ||
| - Moreover, attempting to charge for the wrong resource (eg. L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy. | ||
|
|
||
| ### L2 Gas | ||
| - As I understand it (although this should be validated), since there is no security reason to encourage users to run L2 nodes, we do not need to charge for "costs to the L2 network". This means the L2 gas fee can be set to zero. | ||
| - The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. | ||
| - However, we probably do want to include an overall gas limit to ensure that other users can keep up with the chain. I suspect it can be large enough that it is never reached in practice (because the publication and proving cost limits will likely be reached first), but it is still necessary to prevent malicious compute-only transactions (like running an infinite loop). | ||
| - Once we've decided to include a limit, I think it also makes sense to have a smaller target, so that unexpected volatility does not create immediate scarcity (and correspondingly very high prices). The EIP-1559 mechanism seems like a good way to regulate this. | ||
| - However, applying the mechanism to the sequencer (instead of the transactions) has some benefits: | ||
| - it is simpler. We only need to do one update calculation per publication (rather than for every block) | ||
| - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) | ||
| - users and sequencers have more flexibility around when and how payments are made. | ||
|
|
||
| ### Publication Costs | ||
| - Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. | ||
| - Moreover, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). | ||
| - When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP-1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. | ||
| - With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. | ||
| - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. | ||
| - If standardisation is preferred, Taiko could still create a suggested fee formula that sequencers can use. | ||
|
|
||
|
|
||
|
|
||
| ### Proving Costs | ||
| - Following the same intuitions, if sequencers compensate provers at whatever rate they agree, then sequencers and users are incentivised to optimise the proving costs. | ||
| - For example, sequencers can offer discounts for transactions that are easy to prove. | ||
| - This also lets Taiko be maximally flexible about the best way to estimate proving costs. Anyone is free to: | ||
| - use a "zk-opcode" method | ||
| - use L2 gas as a proxy for proving costs | ||
| - invent a new method specialised for their proving hardware. | ||
|
|
||
| ## Wallet compatibility | ||
|
|
||
| There are two challenges that I think will need to be addressed, and may depend on the cooperation of wallet developers: | ||
|
|
||
| - Fee discovery | ||
| - Sequencers will need a way to signal to wallets how much they would charge for a given transaction | ||
| - I'm not sure how this works in practice, and whether wallets can change which endpoint they query based on who the next sequencer is, or if sequencers can register their fee calculation with some shared provider. | ||
| - Using total fees | ||
| - As I've described the mechanism, the transactions will pay some base fee (possibly zero) associated with the L2 gas execution, and should also specify a priority fee to account for the other charges | ||
| - However, current transaction types require them to specify a _priority fee rate_ (not absolute fee) against L2 gas. | ||
| - As noted, I don't think they should charge per unit of L2 gas execution, so they will need to compute the total fee and then divide it by the actual gas consumed. | ||
| - Unfortunately, users do not necessarily know exactly how much gas will be consumed when constructing the transaction because that might depend on if any other transactions change the state before this transaction is sequenced. | ||
| - Ideally, this would be solved with a new transaction type, allowing users to specify the total priority fee. | ||
| - Until then, sequencers will need to simulate the transaction to determine the actual gas consumed, and only then can they figure out whether the priority fee will be sufficient. | ||
| - They could also use a wrapper smart contract that first executes the transaction and then consumes the remaining gas so that the transaction gas limit would be equivalent to the actual gas consumed, but this seems pretty hacky. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| - To address the question of wallet compatibility, I should get familiar with how wallets choose fees and display them to users. At this point I do not have enough background to understand claims about whether it is or is not possible. | ||
| - I will be offline for a few days, but in the mean time, I think it might be worthwhile to consider alternatives, to provoke a discussion and better pinpoint exactly what the constraints are. | ||
|
|
||
| ### Independent L2 charges | ||
|
|
||
| - If we cannot use priority fees (or it is too difficult to use the priority fee rate), my preference is to use an external L2 mechanism to charge the fee. | ||
| - For example: | ||
| - sequencers could require all transactions to go to a wrapper contract that extracts fees (potentially in tokens) as part of the user operation | ||
| - sequencers could require users to create independent transactions that pay the fees directly | ||
| - This is a minor preference because the annoyance of having an external mechanism may be worse than poorly specified fees. | ||
| - If we do go down this path, we should create a standard default mechanism (eg. a standard wrapper contract) to minimize inconsistencies. | ||
|
|
||
| ### Sequencer chosen base rate | ||
|
|
||
| - If we do decide to use the L2 base fee for all charges, it's not clear to me why Taiko needs to be opinionated about the amount. | ||
| - Can we just let sequencers pick an arbitrary base fee for their blocks, disconnected from whatever else is happening in the protocol? | ||
| - My rationale is: | ||
| - as noted, we do not need to ensure they cover "costs to the network" | ||
| - this is another way of letting users and sequencers negotiate a market price, based on the realtime expected costs | ||
| - Potential counterarguments (and my response): | ||
| - this could lead to issues where compute-heavy transactions subsidize the data-heavy transactions | ||
| - I think that's a consequence of charging the same base fee for all transactions, and charging for each computational step. As far as I can tell, it's not worsened by choosing any specific number. | ||
| - this may allow wide price swings between publications if some sequencer chooses a ridiculously high gas fee amount. | ||
| - I think that risk already exists, because sequencers can demand high priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with is going to be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits | ||
| - On the other hand, the ability to allow massive price swings may actually just be sequencers responding to real-world market conditions. | ||
| - It also lets users and sequencers be more creative about how to arrive at the correct charge given the base-fee constraint. For example, the sequencer could include all data-heavy transactions in a block with a high base fee (to indirectly charge for the L1 blobs), and then go back to regular block charges for regular L2 transactions. | ||
| - Any feedback on if I'm missing something would be appreciated. | ||
|
|
||
|
|
||
| ## Resolution | ||
|
|
||
| - As I understand it, this recommendation is not possible for Taiko because existing wallets do not have standard RPCs for fetching priority fees. | ||
| - Moreover, we cannot use the "Sequencer chosen base rate" alternative, because (most) wallets compute the base fee from internal node logic, so there is no place for the current sequencer to inject their preference on a per-transaction basis. | ||
| - We cannot manipulate the L2 block-producing mechanism to change the base fee arbitrarily on a per-block basis (which would allow sequencers to group data-heavy transactions into the same block) because the preconfirmation mechanism now enforces regular block lengths (of 2 seconds). | ||
| - Overall, this implies that at least for now, any solutions must involve | ||
| - setting the base fee for all transactions in a particular 2-second window | ||
| - be computable from a predetermined formula | ||
| - be charged against L2 computational steps | ||
| - As noted already, this means the fee will not correctly track the cost of the resources it consumes. | ||
| - Ideally, we should push for more flexible fee-choosing mechanisms, particularly for the priority fee (perhaps by influencing the [wallet beat](https://github.com/walletbeat/walletbeat) criteria). My preference is: | ||
| - accounts should be able to specify how they would like to select fees. | ||
| - note that this doesn't change anything about what fees are enforced by the protocol. L1 must still charge gas fees as a proxy for network costs, but L2s could set the base fee to zero. | ||
| - they should be able to specify a total priority fee as well as the priority fee rate. | ||
| - wallets will choose the fees they present to the user (before signing) as follows: | ||
| - if the account has specified an actual formula they want to use, use that. | ||
| - if the account has specified an RPC to call, use that. | ||
| - if the account has not specified a fee-choosing mechanism, use whatever mechanism they currently use. | ||
| - Until then, there are two kinds of risks that I see: | ||
| - the best case scenario is that the base fee correctly tracks the overall cost for average transactions. However, sequencers can only signal desired changes for future publications, which distorts the incentive to get it right, particularly for a diverse set of sequencers. | ||
| - transactions with higher than average data-to-L2-compute ratios will be underpriced. | ||
| - such transactions will either be subsidized by the sequencer, or will not be included at all. | ||
| - moreover, sequencers may have to process these transactions (since the actual gas consumed will be unknown until it is executed locally) before deciding to discard them. | ||
| - the same problem exists for transactions with higher than average proving-cost-to-L2-compute ratios. | ||
| - transactions with lower than average data-to-L2-compute or proving-cost-to-L2-compute ratios will be overpriced. | ||
| - Note that this doesn't change the treasury fee analysis. I still believe that Taiko can direct a fraction of the measured L1 costs to the treasury, instead of (or in addition to) the base fee fraction. No newline at end of file |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Optional: quick verification script to prevent regressions (typos/style) before merge
Run from repo root; it only prints matches and lint counts.
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="documentation/Taiko Fee Proposal.md"
echo "Scan for known nits…"
rg -nP 'offchain|realtime|\bdecided for themselves\b|\bL1\s*/\s*L2\b|\beg\.' "$file" || true
echo
echo "Check canonical EIP-1559 hyphenation:"
rg -nP 'EIP1559\b' "$file" || true
echo
echo "List bullets with 3+ leading spaces (MD007 risk):"
rg -nP '^\s{3,}-\s' "$file" || true
echo
echo "markdownlint summary (if configured via npm script or local install):"
if command -v markdownlint-cli2 >/dev/null 2>&1; then
markdownlint-cli2 "$file" || true
else
echo "markdownlint-cli2 not found (skipping)."
fiLength of output: 30750
Stylistic and formatting issues identified in the documentation
The verification script revealed several formatting and style issues in the Taiko Fee Proposal documentation that should be addressed before merge:
Critical formatting issues:
- Line 27: Grammar error - "sequencers can decided for themselves" should be "sequencers can decide for themselves"
- Line 41: Trailing space after "the refund address on L1"
- Multiple instances of "offchain" should be "off-chain" for consistency
- Multiple instances of "realtime" should be "real-time" for consistency
- Several instances of "eg." should be "e.g.," for proper formatting
Markdown formatting issues:
- 148 markdownlint errors including:
- Inconsistent list indentation (MD007) - many bullets use 4+ spaces instead of 2
- Long lines exceeding 80 characters (MD013) - 73 instances
- Missing blank lines around headings (MD022)
- Multiple consecutive blank lines (MD012)
- Missing trailing newline (MD047)
Specific locations needing attention:
- Line 27: Fix grammar error "decided" → "decide"
- Line 41: Remove trailing space
- Lines 12, 75, 88, 137: Change "offchain" → "off-chain" and "realtime" → "real-time"
- Line 71, 129: Change "eg." → "e.g.,"
- Throughout: Standardize list indentation to 2 spaces per level
- Throughout: Break long lines to stay within 80-character limit
- Add blank lines around section headings
- Remove extra blank lines between sections
- Add final newline at end of file
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: There might be a mistake here.
Context: ... other network participants can keep up. - technically, the actual resource limits ...
(QB_NEW_EN)
[grammar] ~8-~8: There might be a mistake here.
Context: ... actual limit, to smooth out volatility. - In the L2 case: - there are no relev...
(QB_NEW_EN)
[grammar] ~12-~12: Ensure spelling is correct
Context: ... own account, and may incur significant offchain proving costs. - We want a mechanis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~12-~12: There might be a mistake here.
Context: ...ncur significant offchain proving costs. - We want a mechanism to direct funds towa...
(QB_NEW_EN)
[grammar] ~26-~26: There might be a mistake here.
Context: ...and to maintain a per-second gas target. - sequencers can decided for themselves ho...
(QB_NEW_EN)
[grammar] ~28-~28: There might be a mistake here.
Context: ...n be directed to the treasury or burned. 2. The protocol does not compute or enforce...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...ransaction) and doing a direct transfer. - alternatively, it could be computed as p...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...s part of the state-transition function. 3. Similar to the existing protocol, propos...
(QB_NEW_EN)
[grammar] ~37-~37: There might be a mistake here.
Context: ... to a proposer-specified refund address. - otherwise, whoever proves it gets the li...
(QB_NEW_EN)
[grammar] ~38-~38: There might be a mistake here.
Context: ...hoever proves it gets the liveness bond. - To facilitate enforceable prover/propose...
(QB_NEW_EN)
[grammar] ~45-~45: There might be a mistake here.
Context: ...he scenario where the base fee is zero). - The L2 address represents a prover, and ...
(QB_NEW_EN)
[grammar] ~46-~46: There might be a mistake here.
Context: ...gned (but this is not enforced) so that: - it sends the liveness bond minus its cho...
(QB_NEW_EN)
[style] ~59-~59: For improved clarity, try using the conjunction “and” instead of a slash.
Context: ... actually transferring funds between L1 / L2 (or requiring the proposer to have L...
(QB_NEW_EN_SLASH_TO_AND)
[grammar] ~59-~59: There might be a mistake here.
Context: ... fee rather than refund the bond amount. - If the validatePublication function fa...
(QB_NEW_EN)
[grammar] ~61-~61: There might be a mistake here.
Context: ...ation` interface) and apply a surcharge to sequencer, directed to the treasury (ju...
(QB_NEW_EN)
[grammar] ~70-~70: There might be a mistake here.
Context: ... out of sync with the market conditions. - Moreover, attempting to charge for the w...
(QB_NEW_EN)
[grammar] ~73-~73: There might be a mistake here.
Context: ...hat exploit the discrepancy. ### L2 Gas - As I understand it (although this should...
(QB_NEW_EN)
[grammar] ~75-~75: Ensure spelling is correct
Context: ...uencer may still want to charge for the offchain processing costs, but this can be incor...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~75-~75: There might be a mistake here.
Context: ... costs) associated with the transaction. - However, we probably do want to include ...
(QB_NEW_EN)
[grammar] ~85-~85: There might be a mistake here.
Context: ... other transactions in the publication). - When discussing this idea, one concern w...
(QB_NEW_EN)
[grammar] ~87-~87: There might be a mistake here.
Context: ...ated) publication costs to the treasury. - this doesn't remove the need for sequenc...
(QB_NEW_EN)
[grammar] ~88-~88: There might be a mistake here.
Context: ...tever level of sophistication they have. - If standardisation is preferred, Taiko c...
(QB_NEW_EN)
[grammar] ~93-~93: There might be a mistake here.
Context: ...sequencers can use. ### Proving Costs - Following the same intuitions, if sequen...
(QB_NEW_EN)
[grammar] ~94-~94: There might be a mistake here.
Context: ...entivised to optimise the proving costs. - For example, sequencers can offer discou...
(QB_NEW_EN)
[grammar] ~96-~96: There might be a mistake here.
Context: ...timate proving costs. Anyone is free to: - use a "zk-opcode" method - use L2 ga...
(QB_NEW_EN)
[grammar] ~107-~107: There might be a mistake here.
Context: ...e calculation with some shared provider. - Using total fees - As I've described...
(QB_NEW_EN)
[grammar] ~110-~110: There might be a mistake here.
Context: ...rate_ (not absolute fee) against L2 gas. - As noted, I don't think they should char...
(QB_NEW_EN)
[grammar] ~128-~128: There might be a mistake here.
Context: ...may be worse than poorly specified fees. - If we do go down this path, we should cr...
(QB_NEW_EN)
[grammar] ~138-~138: There might be a mistake here.
Context: ...tial counterarguments (and my response): - this could lead to issues where compute-...
(QB_NEW_EN)
[grammar] ~141-~141: There might be a mistake here.
Context: ...oses a ridiculously high gas fee amount. - I think that risk already exists, becaus...
(QB_NEW_EN)
[uncategorized] ~142-~142: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...y exists, because sequencers can demand high priority fees or refuse to sequence transactions...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~142-~142: Use ‘will’ instead of ‘going to’ if the following action is certain.
Context: ...opoly power, any scheme we come up with is going to be vulnerable to sequencers making ridi...
(GOING_TO_WILL)
[grammar] ~143-~143: There might be a mistake here.
Context: ...ponding to real-world market conditions. - It also lets users and sequencers be mor...
(QB_NEW_EN)
[grammar] ~144-~144: There might be a mistake here.
Context: ...ock charges for regular L2 transactions. - Any feedback on if I'm missing something...
(QB_NEW_EN)
[grammar] ~151-~151: There might be a mistake here.
Context: ...r preference on a per-transaction basis. - We cannot manipulate the L2 block-produc...
(QB_NEW_EN)
[grammar] ~153-~153: There might be a mistake here.
Context: ...east for now, any solutions must involve - setting the base fee for all transaction...
(QB_NEW_EN)
[grammar] ~154-~154: There might be a mistake here.
Context: ...sactions in a particular 2-second window - be computable from a predetermined formu...
(QB_NEW_EN)
[grammar] ~157-~157: There might be a mistake here.
Context: ...k the cost of the resources it consumes. - Ideally, we should push for more flexibl...
(QB_NEW_EN)
[grammar] ~159-~159: There might be a mistake here.
Context: ...cify how they would like to select fees. - note that this doesn't change anything a...
(QB_NEW_EN)
[grammar] ~161-~161: There might be a mistake here.
Context: ...ty fee as well as the priority fee rate. - wallets will choose the fees they presen...
(QB_NEW_EN)
[grammar] ~162-~162: There might be a mistake here.
Context: ...to the user (before signing) as follows: - if the account has specified an actual f...
(QB_NEW_EN)
[grammar] ~163-~163: There might be a mistake here.
Context: ...tual formula they want to use, use that. - if the account has specified an RPC to c...
(QB_NEW_EN)
[grammar] ~164-~164: There might be a mistake here.
Context: ... has specified an RPC to call, use that. - if the account has not specified a fee-c...
(QB_NEW_EN)
[grammar] ~165-~165: There might be a mistake here.
Context: ...e whatever mechanism they currently use. - Until then, there are two kinds of risks...
(QB_NEW_EN)
[grammar] ~166-~166: There might be a mistake here.
Context: ...there are two kinds of risks that I see: - the best case scenario is that the base ...
(QB_NEW_EN)
[grammar] ~168-~168: There might be a mistake here.
Context: ...o-L2-compute ratios will be underpriced. - such transactions will either be subsidi...
(QB_NEW_EN)
[grammar] ~169-~169: There might be a mistake here.
Context: ...quencer, or will not be included at all. - moreover, sequencers may have to process...
(QB_NEW_EN)
[grammar] ~170-~170: There might be a mistake here.
Context: ...ocally) before deciding to discard them. - the same problem exists for transactions...
(QB_NEW_EN)
[grammar] ~171-~171: There might be a mistake here.
Context: ...erage proving-cost-to-L2-compute ratios. - transactions with lower than average dat...
(QB_NEW_EN)
[grammar] ~172-~172: There might be a mistake here.
Context: ...to-L2-compute ratios will be overpriced. - Note that this doesn't change the treasu...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
10-10: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
11-11: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
12-12: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
13-13: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
79-79: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
80-80: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
81-81: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
88-88: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
89-89: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
97-97: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
98-98: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
99-99: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
114-114: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
126-126: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
127-127: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
136-136: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
137-137: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
139-139: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
140-140: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
141-141: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
142-142: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
143-143: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
144-144: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
154-154: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
155-155: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
156-156: Unordered list indentation
Expected: 2; Actual: 3
(MD007, ul-indent)
159-159: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
160-160: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
161-161: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
162-162: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
163-163: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
164-164: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
165-165: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
167-167: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
168-168: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
169-169: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
170-170: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
171-171: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
172-172: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
🤖 Prompt for AI Agents
In documentation/Taiko Fee Proposal.md lines 1-173: the file has multiple
stylistic and Markdown formatting issues — fix grammar and spelling (line 27:
"decided" → "decide"; line 41: remove trailing space), standardize wording
(replace all "offchain" → "off-chain", "realtime" → "real-time", and "eg." →
"e.g.," on lines 71 and 129 and elsewhere), normalize list indentation to 2
spaces per level, wrap long lines to <=80 characters, add blank lines above and
below headings, remove consecutive extra blank lines, and ensure the file ends
with a single trailing newline; apply these changes across the whole document
consistently.
| - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. | ||
| - limit the total resource consumption to a level where other network participants can keep up. | ||
| - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility. |
There was a problem hiding this comment.
Fix Markdown list indentation to satisfy MD007 (unordered list indentation)
markdownlint-cli2 flags multiple places where nested bullets use 3–4 spaces rather than the repo’s 2-space standard. This can also render inconsistently across viewers.
Representative minimal fixes (apply consistently throughout):
- - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism.
- - limit the total resource consumption to a level where other network participants can keep up.
- - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility.
+ - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism.
+ - limit the total resource consumption to a level where other network participants can keep up.
+ - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that is less than the actual limit, to smooth out volatility.- - it is simpler. We only need to do one update calculation per publication (rather than for every block)
- - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer)
- - users and sequencers have more flexibility around when and how payments are made.
+ - it is simpler. We only need to do one update calculation per publication (rather than for every block)
+ - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer)
+ - users and sequencers have more flexibility around when and how payments are made.- - setting the base fee for all transactions in a particular 2-second window
- - be computable from a predetermined formula
- - be charged against L2 computational steps
+ - setting the base fee for all transactions in a particular 2-second window
+ - be computable from a predetermined formula
+ - be charged against L2 computational stepsFollow-up: if you prefer automation, run markdownlint locally and normalize all bullets to 2-space per nesting level. I can push a commit touching only indentation if you’d like.
Also applies to: 79-81, 154-156
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: There might be a mistake here.
Context: ... other network participants can keep up. - technically, the actual resource limits ...
(QB_NEW_EN)
[grammar] ~8-~8: There might be a mistake here.
Context: ... actual limit, to smooth out volatility. - In the L2 case: - there are no relev...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
6-6: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
7-7: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
8-8: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
🤖 Prompt for AI Agents
In documentation/Taiko Fee Proposal.md around lines 6 to 8 (and also apply same
fix to lines 79-81 and 154-156), several nested unordered bullets use 3–4 spaces
instead of the repo standard 2-space indentation per nesting level; update those
list lines to use 2 spaces per nesting level (align nested bullets
consistently), and run markdownlint (or markdownlint-cli2) locally to normalize
and verify all unordered list indentation across the document.
Summary by CodeRabbit