l2tol2cdm-gasreceipt

Author: hamdiallam

ecosystem/l2tol2cdm-gasreceipt.md

@@ -0,0 +1,64 @@
+# [Project Name]: Design Doc
+
+|                    |                                                    |
+| ------------------ | -------------------------------------------------- |
+| Author             | _Author Name_                                      |
+| Created at         | _YYYY-MM-DD_                                       |
+| Initial Reviewers  | _Reviewer Name 1, Reviewer Name 2_                 |
+| Need Approval From | _Reviewer Name_                                    |
+| Status             | _Draft / In Review / Implementing Actions / Final_ |
+
+## Purpose
+
+<!-- This section is also sometimes called “Motivations” or “Goals”. -->
+
+<!-- It is fine to remove this section from the final document,
+but understanding the purpose of the doc when writing is very helpful. -->
+
+## Summary
+
+<!-- Most (if not all) documents should have a summary.
+While the length will likely be proportional to the length of the full document,
+the summary should be as succinct as possible. -->
+
+## Problem Statement + Context
+
+<!-- Describe the specific problem that the document is seeking to address as well
+as information needed to understand the problem and design space.
+If more information is needed on the costs of the problem,
+this is a good place to that information. -->
+
+## Proposed Solution
+
+<!-- A high level overview of the proposed solution.
+When there are multiple alternatives there should be an explanation
+of why one solution was picked over other solutions.
+As a rule of thumb, including code snippets (except for defining an external API)
+is likely too low level. -->
+
+### Resource Usage
+
+<!-- What is the resource usage of the proposed solution?
+Does it consume a large amount of computational resources or time? -->
+
+### Single Point of Failure and Multi Client Considerations
+
+<!-- Details on how this change will impact multiple clients. Do we need to plan for changes to both op-geth and op-reth? -->
+
+## Failure Mode Analysis
+
+<!-- Link to the failure mode analysis document, created from the fma-template.md file. -->
+
+## Impact on Developer Experience
+<!-- Does this proposed design change the way application developers interact with the protocol?
+Will any Superchain developer tools (like Supersim, templates, etc.) break as a result of this change? ---!>
+
+## Alternatives Considered
+
+<!-- List out a short summary of each possible solution that was considered.
+Comparing the effort of each solution -->
+
+## Risks & Uncertainties
+
+<!-- An overview of what could go wrong.
+Also any open questions that need more work to resolve. -->