# Gas benchmark

**What this page is (and isn’t):** These are engineering envelopes and design notes so you can size costs, compare code paths, and keep transactions cheap without weakening safety. Real fees depend on L2 gas price, blob base fee, calldata size, warm/cold storage, and the number of attestations or proofs you include. We publish live p50/p95 on the status page post-launch; use the formulas below to recompute dollars at your current gas/ETH prices.

### A) Method & assumptions

* **Benchmarks:** from devnets and instrumented tests on an Optimistic L2 (OP-stack family). We report execution gas on L2 and typical calldata/blob bytes so you can estimate the L1 data component.
* **Adjustable knobs (plug in your numbers):**
  * **L2\_GAS\_PRICE (gwei):** default 0.02 gwei
  * **ETH\_USD (USD/ETH):** default $2,000
  * **BLOB\_USD\_PER\_KB (USD per KB of blob data):** planning envelope $0.10–$0.60/100 KB (varies with network load)
* **Quick estimate formulas:**
  * **L2 USD cost ≈** gasUsed \* L2\_GAS\_PRICE(gwei) \* 1e-9 \* ETH\_USD
  * **Blob USD cost ≈** blobBytes / 1024 \* BLOB\_USD\_PER\_KB
  * **Total USD ≈** L2 USD + Blob USD
* **We keep calldata compact:** larger dossiers increase blobBytes, not execution gas. Most of your variance comes from how much evidence you send, not from the opcodes that verify it.

### B) Core tx envelopes

| **Tx type**                        | **Core work**                                           | **Calldata p50 (B)** | **L2 gas p50** | **L2 gas p95** | **Rule-of-thumb notes**                                                           |
| ---------------------------------- | ------------------------------------------------------- | -------------------- | -------------- | -------------- | --------------------------------------------------------------------------------- |
| **trade.proof (Gate PASS)**        | Validate schema, quorum, equality, reserve One-Claim    | 1.5–3.0k             | 120k           | 180k           | +20–40k per extra attestation; +40–70k if verifying a small Merkle proof on-chain |
| **trade.emt + release**            | Mint EMT, flip Locked→Unlocked EDSD, fee calc, 50% burn | 0.5–1.0k             | 210k           | 300k           | Includes Router/Burner; fee caps enforced in-call                                 |
| **trade.replace (corrective EMT)** | Mint corrective EMT (replaces), keep lineage            | 1.0–1.8k             | 180k           | 250k           | Similar to EMT mint; no fee until release                                         |
| **tokens.mint**                    | Gate PASS, One-Claim finalize, store token metadata     | 1.2–2.2k             | 160k           | 220k           | Heavier if many metadata fields                                                   |
| **tokens.settle (Buy)**            | Transfer, 4% fee, 50% burn                              | 0.6–1.2k             | 190k           | 260k           | Ownership change only; no dossier                                                 |
| **tokens.retire**                  | Mark retired, 4% fee, 50% burn                          | 0.6–1.2k             | 200k           | 280k           | Adds retirement receipt pointer                                                   |
| **registry.mirror.create**         | Bind external serial → claim\_id                        | 0.8–1.2k             | 110k           | 160k           | Registry signature validated via Attestor Registry                                |
| **registry.mirror.replace**        | Append replacement mirror; freeze/unfreeze              | 0.8–1.2k             | 120k           | 170k           | Old mirror remains for lineage                                                    |
| **pov.revoke**                     | Record revocation + freeze scope                        | 0.5–0.9k             | 95k            | 140k           | No fee/burn; downstream only                                                      |
| **gov.param.change (exec)**        | ParameterStore update via Timelock                      | 0.3–0.6k             | 80k            | 120k           | Bounded values; forward-only activation                                           |

**Typical blob sizes (guidance only):**

* **trade.proof:** 1.5–3.0 KB per gate (dossier JSON + compact attestation bundle)
* **trade.release / tokens.settle/retire:** 0.5–1.0 KB (refs only)
* **registry.mirror:** 0.8–1.2 KB

If you ship raw CSVs/images as files by digest (recommended), they do not go in calldata / blobs; only their {name, sha256, size} entries do. Large logs (e.g., temperature) should commit a Merkle root, not the stream.

### C) What actually moves the needle

1. **Attestation count & encoding:** Each additional attestation adds 20–40k gas plus \~0.2–0.4 KB calldata. Use compact role bundles (RLP/ABI-packed signatures) instead of JSON inlined signatures.
2. **Merkle/zk on-chain vs attested off-chain:** On-chain verification: +40–70k per small Merkle proof; zk range/membership proof: 100–500k depending on scheme. If it pushes you over latency budgets, use attested verification: the role verifies off-chain and signs a statement bound to the PoV hash; the Gate counts their signature.
3. **Dossier size:** Keep fields minimal; push binaries to the vault; reference by digest. Treat big lists (containers) as SET and send a single digest of the sorted list instead of the whole array where the schema permits.
4. **Storage patterns:** Prefer events over persistent storage when you only need an audit trail (we already emit PoV hash, claim id, burn hash). Batch small writes where feasible (e.g., mirror adjunct data).

### D) Design patterns to keep costs low 

* **Hash-first UIs:** preview the PoV hash and file digests before submit; server rejects drift with E\_CANONICAL\_DRIFT and returns canonical bytes.
* **Canonicalizer SDK:** serialize once (sorted keys, UTC Z, decimal strings); never re-serialize in the browser.
* **SET vs SEQ:** mark container\_ids as SET (sorted) and send a digest; mark time series as SEQ and keep order.
* **EIP-712 role attestations:** typed data, compact signatures; batch them in a bundle.
* **Merkle at the edge:** commit temp\_log\_root on device/edge; provide inclusion proofs only for the required intervals.
* **Attested zk for heavy circuits:** on-chain zk reserved for small range/membership checks when latency budgets allow.
* **Event-driven receipts:** put PoV hash, claim\_id, burn hash in events; index them off-chain for Explorer/CSV.

### E) Planning envelopes

* **Using L2\_GAS\_PRICE = 0.02 gwei, ETH\_USD = $2,000, BLOB\_USD\_PER\_KB = $0.005 (i.e., $0.50 per 100 KB):**
* **trade.proof p50:** 120k \* 0.02e-9 \* 2000 ≈ $0.0048 + blob (2.0 KB \* $0.005) ≈ $0.01 → \~$0.02
* **trade.emt+release p50:** 210k → \~$0.0084 + blob (0.8 KB) ≈ $0.004 → \~$0.012
* **tokens.settle p50:** 190k → \~$0.0076 + blob (0.8 KB) ≈ $0.004 → \~$0.012
* **tokens.retire p50:** 200k → \~$0.0080 + blob (0.8 KB) ≈ $0.004 → \~$0.012

These are order-of-magnitude. If gas or blob fees surge, multiply by your current values. Operationally, the protocol fee/burn dominates the economics; execution is cents.

### F) How we measure 

* **Unit tests on contracts:** (forge test --gas-report, Hardhat gas reporter) with warm/cold scenarios.
* **Scenario tests with realistic dossiers:** 2–3 attestations, 2 required files (by digest), optional single Merkle proof.
* **Telemetry on devnets & staging:** p50/p95 gas, calldata size, and blob bytes per tx type.
* **Post-launch, the Explorer:** shows per-tx gas and blob usage; weekly dashboards publish p50/p95 and outliers per lane.

### G) Known heavy paths & mitigations

* **Large Merkle proof sets on-chain:** prefer attested verification for long streams; or chunk proofs across gates.
* **Multiple attestations per role:** dedupe per role per gate; schemas should require distinct roles, not many of the same.
* **Chatty schemas:** split optional fields into vault docs (by digest) when feasible; keep PoV JSON tight.

### H) Quick reference table 

| **Tx**                | **p50 gas** | **+per extra attestation** | **+per Merkle proof (small)** | **Notes**                           |
| --------------------- | ----------- | -------------------------- | ----------------------------- | ----------------------------------- |
| **trade.proof**       | 120k        | +20–40k                    | +40–70k                       | Equality, quorum, One-Claim reserve |
| **trade.emt+release** | 210k        | —                          | —                             | Flip funds, fee calc, 50% burn      |
| **tokens.mint**       | 160k        | +20–40k                    | +40–70k                       | PoV PASS + finalize                 |
| **tokens.settle**     | 190k        | —                          | —                             | 4% fee, 50% burn                    |
| **tokens.retire**     | 200k        | —                          | —                             | 4% fee, 50% burn                    |
| **mirror.create**     | 110k        | —                          | —                             | Registry sig via Attestor Registry  |
| **pov.revoke**        | 95k         | —                          | —                             | Freeze scope only                   |

### Bottom line

{% hint style="info" %}
**Execution on L2 is cheap**; bloat comes from dossier size and proof strategy. Keep JSON canonical and minimal, push binaries to the vault, commit big logs by Merkle root, batch role signatures, and verify heavy proofs off-chain with attested roles when latency matters. The settlement law remains constant—and every time you settle or release, the fee line posts and exactly 50% burns in EDM, with a hash you can file.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.edma.app/17.-appendix/gas-benchmark.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.