Add EigenDA , native Bridging

[GigaHierz]

1. Adding EigenDA
2. Adding Native Bridging

Open questions here, related to the spec:

- Should we use Superchain docs for WETH bridging? Harpal did the docs for this, but in the spec, you mention using optimism sdk: 
  - https://docs.celo.org/what-is-celo/using-celo/native-ETH-bridging

  - https://docs.optimism.io/stack/transactions/deposit-flow
- Intro:
    - Does CELO have different addresses on Ethereum than Celo? 
    - Don’t understand that sentence: The L2 version is the native token on the L2 Celo chain, preserving the balances from the Celo L1 chain. How does it preserve the balances from the Celo L1 chain? 
    - Do we have an address for CeloDistributionSchedule?
- Bridging tokens
    - Bridging CELO will be different from ERC20 tokens, even if CELO is also an ERC20 token?
    - Where is the fee abstraction happening? During the bridging? Only on Celo? Is this specific to bringing or all Fee Currency? 
    - What are the explorer tools for checking bridging? 

[netlify]

❌ Deploy Preview for celo-docs failed. Why did it fail? →

Name	Link
🔨 Latest commit	33c8e0e
🔍 Latest deploy log	https://app.netlify.com/projects/celo-docs/deploys/6887fc92d4148c00087a675f

[karlb]

Does CELO have different addresses on Ethereum than Celo?

Yes
Celo mainnet: https://celoscan.io/address/0x471ece3750da237f93b8e339c536989b8978a438
Ethereum: https://etherscan.io/address/0x057898f3C43F129a17517B9056D23851F124b19f

We can't freely choose an address on Ethereum and we would break existing usage if we changed the address on Celo, so those have to be different.

Don’t understand that sentence: The L2 version is the native token on the L2 Celo chain, preserving the balances from the Celo L1 chain. How does it preserve the balances from the Celo L1 chain?

The Celo L2 started with the same state that the Celo L1 had in its last block. So all native balances (CELO) carry over from the Celo L1 to the Celo L2.

Do we have an address for CeloDistributionSchedule?

It's not registered in the Registry contract for mainnet. @pahor167 can probably answer this one.

Bridging CELO will be different from ERC20 tokens, even if CELO is also an ERC20 token?

Yes, unlike other bridged tokens, the CELO ERC20 token does not allow the bridge to mint and burn tokens as part of the bridging process. This can't be implemented in the CELO smart contract without additional precompiles and we don't want to add any unless absolutely necessary.

Where is the fee abstraction happening? During the bridging? Only on Celo? Is this specific to bringing or all Fee Currency?

Bridging and fee abstraction as concepts are completely unrelated. A token can be bridgeable without being a fee currency and it can be a fee currency without being bridgeable (as well as both or neither).

Our fee abstraction only exists on Celo. Ethereum does not have support for it and does not "see" anything about it happening on Celo. The fee abstraction ins handled as part of the execution of txs on a Celo chain (when debiting and crediting fees right before and after the execution of the actual tx)

[viral-sangani]

@claude Can review this PR also?

[claude]

Claude finished @viral-sangani's task in 1m 20s —— View job

---

PR Review

• Read changed files
• Analyze git diff
• Provide review feedback

---

Summary

This PR adds two new documentation pages (EigenDA and Native Bridging) and registers them in the sidebar. Here is my full review:

---

Critical Issue: Sidebar Path Mismatch (Likely Cause of Build Failure)

The sidebar entries reference doc IDs under protocol/, but the actual files were created directly under using-celo/:

sidebars.js (lines added):

id: "what-is-celo/using-celo/protocol/eigenda",    // ❌ Wrong
id: "what-is-celo/using-celo/protocol/native-bridging",  // ❌ Wrong

Actual file locations:

docs/what-is-celo/using-celo/eigenda.md          → id: "what-is-celo/using-celo/eigenda"
docs/what-is-celo/using-celo/native-bridging.md  → id: "what-is-celo/using-celo/native-bridging"

Either:

1. Move the files into docs/what-is-celo/using-celo/protocol/ to match the sidebar IDs, or
2. Update the sidebar IDs to "what-is-celo/using-celo/eigenda" and "what-is-celo/using-celo/native-bridging"

Given that celo-token.md, consensus.md, escrow.md etc. all live in protocol/, option 1 (moving the files) is more consistent with the existing structure.

Fix this →

---

eigenda.md — Review

Strengths:

• Good high-level overview with clear structure
• Useful links to forum proposals and specs
• Covers both the technical rationale and ecosystem benefits

Issues:

1. Missing spaces around em-dashes (commas used as em-dashes) — Several sentences use commas where em-dashes or actual commas should be, which hurts readability:

   • Line 11: This integration,[first proposed...] — missing space after comma
   • Line 19: focused on stablecoins, payments, and access in low-bandwidth environments,fee volatility — the trailing comma before "fee volatility" should be an em-dash or restructured
   • Line 25: stores only a **DA commitment**,a cryptographic reference — missing space after comma
   • Line 34: sub-cent transaction fees,even during peak demand — missing space

2. Stale link for EigenLayer testnet deployments (line 65/85): https://www.eigenlayer.xyz points to EigenLayer's homepage, not a testnet deployment page. Consider linking to the actual docs or contract addresses page.

3. Unverified throughput claim (line 37): "Internal benchmarks have shown EigenDA's potential to reach up to 10 MB/s" — consider citing or linking the source for this benchmark to make it verifiable.

4. Minor: Line 7 has a redundant top-level # EigenDA on Celo heading. Since the frontmatter already has title: EigenDA, the H1 in the body will appear as a duplicate title in some Docusaurus configurations. Other docs in this repo (e.g., bridges.md) omit the inline H1.

---

native-bridging.md — Review

Critical: The file is empty. It contains no content — this is a placeholder with no text whatsoever. This should not be merged until the content is added. The open questions in the PR description (CELO addresses, fee abstraction, explorer tools) should be answered and documented here.

Based on karlb's comments, at minimum the following should be documented:

• CELO has different addresses on Ethereum vs Celo (with both addresses)
• State was carried over from Celo L1 at migration time (explaining "preserving balances")
• CELO bridging works differently from standard ERC20 bridging (no mint/burn via bridge)
• Fee abstraction is unrelated to bridging — it's a Celo-native tx execution concept

---

sidebars.js — Review

The placement under "Protocol" (alongside celo-token, consensus, escrow) makes sense for EigenDA, but Native Bridging might be better placed near bridges.md in the existing bridging section. Consider the information architecture.

---

Summary of Required Changes Before Merge

Issue	Severity
native-bridging.md is empty	Blocker
Sidebar doc IDs don't match file paths (build failure)	Blocker
Missing spaces after commas in eigenda.md	Minor
Inline H1 heading in eigenda.md	Minor
Stale/imprecise link for testnet deployments	Minor