EVM Backend Demo for Ethscriptions by RogerPodacter · Pull Request #100 · ethscriptions-protocol/ethscriptions-indexer

RogerPodacter · 2025-09-09T15:15:05Z

Proposal: Ethscriptions App Chain

Summary

It's time to put Ethscriptions on the right technical foundation for long-term growth. We propose evolving Ethscriptions into a Stage 2 App Chain ("app chain" = rollup purpose-built for Ethscriptions, doesn't support arbitrary smart contracts) in a way that preserves full backward compatibility for users and indexers, but gives us provability, client diversity, and the ability to better attract support from partners like OpenSea.

What This Actually Means

Think of this as replacing the current official indexer's Postgres database backend with a blockchain backend. From the outside, everything works exactly the same: same inscription creation, same transfer mechanics, same API endpoints. But internally, instead of storing state in Postgres, we're running an actual EVM chain that:

Processes the same Ethscriptions transactions
Maintains canonical state with cryptographic proofs
Can prove its state to Ethereum L1
Allows different indexers to verify they're in sync via state roots

For users: Zero changes. Create and transfer inscriptions exactly as before.
For alternate indexers: Can continue operating normally, or optionally upgrade to verify state roots.
For the ecosystem: We become a "real" blockchain with provability, better tooling, and Stage 2 status.

Current Architecture Limitations

The current Postgres-based indexer architecture has served us well but has inherent limitations:

Technical Limitations

No cryptographic state verification. Because Ethscriptions lacks state roots, it's costly and slow for indexers to confirm they're applying the same rules. In practice, unless everyone runs the exact same indexer code, there's no way to detect divergence. This undermines client diversity and increases the risk of hidden bugs.
Not provable to L1. Ethscriptions doesn't have a proof system. That means no smart contract on Ethereum can make decisions based on Ethscriptions state. This makes use-cases like wrapping an ethscription into an L1 ERC-721 or bridging an ethscription to another L2 impossible without a trusted operator. As we learned from Ordex this is a major risk.
Limited tooling compatibility. Marketplaces and developers want to run EVM nodes, use EVM RPCs, interact with EVM contracts, use EVM indexers, etc. Custom indexers make it harder for marketplaces like OpenSea and others to support Ethscriptions.
Complex feature development. Modeling a blockchain (with reorgs and rollbacks) in Postgres is awkward. Simple things like ERC-20s have to be re-implemented outside the EVM, leading to bugs, incompatibilities, and "shadow" versions of what the EVM already solves.
Perception challenges. The above creates a branding problem: without cryptographic proofs and standard tooling, Ethscriptions can appear less robust than L2s.

Proposed Solution

Deploy an EVM-based "reference indexer" that internally uses a blockchain instead of Postgres

This alternate implementation processes the exact same Ethscriptions data but stores it in an EVM blockchain instead of a traditional database. This gives us:

Same behavior, better foundation: All existing Ethscriptions functionality works identically, but now with state roots and cryptographic proofs
L1 provability: The rollup can prove its state to Ethereum, enabling trustless bridges and wrapping
Indexer consensus: Different indexers can verify they have the same state by comparing state roots (no more silent divergence)
EVM compatibility: Standard EVM tools (nodes, RPCs, indexers) can read Ethscriptions as ERC-721s
Stage 2 recognition: L2Beat can list us as a Stage 2 App Chain

Implementation details:

Ethscriptions are represented in a pre-deployed ERC-721 contract in the rollup state
No arbitrary smart contract deployment
Uses proven rollup technology (fork of Facet's Stage 2 stack) for reliability

What stays the same:

All inscription creation/transfer UX
All existing APIs and endpoints
All existing indexer operations
User wallets and tooling

What's new (all optional):

Ability to verify state roots between indexers
Ability to prove ownership to L1 contracts
Ability to use standard EVM tooling
Path to future features like native DEXes or marketplaces

FAQ

Q: Do I need to change my indexer?
A: No. This is backward compatible. Existing indexers continue to work exactly as they do now.

Q: Is this related to Facet?
A: Under the hood it would use a fork of Facet's stack which has already been used to create a provable Stage 2 rollup. However, Ethscriptions would continue to have no protocol-level relationship to the Facet Chain.

Q: Is this a migration or a replacement?
A: It's an alternate implementation that can run alongside existing infrastructure. Think of it as offering a blockchain-backed reference indexer as an option, not a requirement.

Q: What about future smart contract functionality?
A: The initial implementation focuses solely on maintaining current functionality with better infrastructure. Later, if there's demand from marketplaces like OpenSea, limited smart contract functionality (DEX, non-custodial marketplaces) could be added. This would be a breaking change for current indexers but would only happen if there's clear value.

Q: How does this affect users?
A: It doesn't. Users continue creating and transferring inscriptions exactly as they do today. The benefits (provability, bridges, etc.) become available without any user-facing changes.

This PR