⚠ experimentalEVVM EIP Lab is in a very experimental phase. Output is documented Solidity for research and prototyping — it is NOT audited, not guaranteed to compile, and not production-ready. Expect rough edges and breaking changes.
~/eiplab
EVVM · protocol-level lab · live

TEST ANY EIP
on the EVVM stack

EVVM is where protocol-level experiments get modeled at the contract layer. Bring an EIP and your own AI key — the Lab reads it, agrees with you on what it is, maps it onto the EVVM core, and hands back documented .sol contracts.

~/eiplab/run

// why evvm eip lab

The bottleneck isn't the EIP.
It's getting to running code.

Going from an EIP to contracts you can reason about usually means days of plumbing. The Lab compresses that — and is honest about what it can and can't prove.

evvm.txt

Built for protocol experiments

EVVM's core contracts are modifiable, so an EIP — new signatures, nonce models, account abstraction, privacy, gas changes — can be modeled at the contract layer and exercised directly. It's the natural place to test protocol-level ideas.

focus.txt

Solidity + justification

Every run produces exactly two things: the documented .sol files and a per-contract justification. Sharp scope. No half-finished extras to clean up afterward.

honesty.txt

Mocks called by name

Heavy dependencies (ZK proofs, exotic hashes, precompiles) get mocked — and every mock carries an explicit limitation: what it stubs and what claims it does NOT support. Real vs. stubbed, at a glance.

// how it works

Four phases, end at Solidity.

The EVVM EIP Lab drives all four. You make the calls it can't — which path when an EIP requires another draft EIP, which sub-experiment when the scope is huge.

phase 01
01

Upload

Load your EIP — paste the full text, or drop links (eips.ethereum.org, an Ethereum Magicians thread, a repo). No length limit. An important EIP can be hundreds of lines, and every line can matter.

phase 02
02

Read & Agree

The Lab reads it and tells you what it is — status, surface, the real behavioral change. Then it asks: did I get the intent right? You correct it until you both agree. No forced word limit.

phase 03
03

Map the surface

The technical conversation: which implementation shape (modify the core, add a service, or an external adapter), which dependencies to vendor / mock / simulate / defer, which EVVM contracts change and how.

phase 04
04

Download .sol

The deliverable: documented, commented Solidity for the EVVM stack — modified core, new services, mocks — plus a per-contract justification. Download the package and take it from there.

// comparison

vs. rolling your own

Not better at everything. Better at the parts most efforts skimp on: agreeing on intent up front, documenting what's real vs. stubbed, and stopping before scope explodes.

comparison.csv
dimensiontraditionalevvm eip lab
Time to running codeDays reading the EIP, finding the right surface, writing plumbingA working session — read, agree, map, download
Shared understandingYou hope the implementer read the EIP the same way you didPhase 2 makes you both agree on the intent before any code
Output shapeCode + half-finished extras, mixed maturityDocumented Solidity + per-contract justification (deliberately narrow)
Mock honesty'Good enough' mocks; caveats buried in PR commentsEvery mock states what it stubs and what it does NOT prove
Big EIPsOne tangled attempt at everything at onceDecomposes into clean sub-experiments when the scope is huge
Cost visibilityNo idea what the AI run cost youLive token meter every run — your key, your spend, your data

// roadmap (raw)

Where this is going.

A rough, honest plan — subject to change. EVVM EIP Lab is early; this is the direction, not a commitment of dates.

stage 01
01
● you are here

Alpha — testable

Where we are today. A very alpha, testable version: bring an EIP and your own provider key, run the four phases, get documented Solidity. Rough edges, breaking changes, output not guaranteed to compile.

stage 02
02
next

Alpha — polished

Still alpha, still testable — but polished. Steadier runs, cleaner output, fewer rough edges across providers and models. The same flow, more reliable.

stage 03
03
planned

Scaffold-EVVM local

Connected to scaffold-evvm: take the generated contracts straight into local compilation and deployment, so you can compile and run your EIP experiment locally instead of just reading the .sol.

stage 04
04
planned

Testnet-ready

Scaffold-evvm compatible plus ready for EVVM testnet deployment — an end-to-end path from EIP to a deployed experiment on the EVVM testnet.

// questions

faq.txt

~/eiplab/faq
Can I run my own EIP?
Yes — that's the whole point. Launch the Lab, pick a provider, paste your API key, drop in an EIP (text or links), and walk the four phases. The examples below are pre-baked runs so you can see the output shape before you spend a token.
What does a run produce?
Documented .sol files (modified core, new services, mocks) plus a per-contract justification, bundled into a downloadable package. No tests, no deploy scripts, no EIP draft — the deliverable is documented Solidity.
Whose API key is used, and is it safe?
Yours. The Lab works with your own provider key (Venice AI to start). The key is sent per-request to our proxy, forwarded to the provider, and discarded — never written to our storage, never logged. We record only token counts (for EVVM's research on AI + EIP cost).
How should I test the contracts the Lab gives me?
For local testing we recommend scaffold-evvm — it runs the full EVVM stack on Anvil or Hardhat Network, and the contracts drop straight into experiments/. See the scaffold-evvm docs and how to make an EVVM service. The downloaded package includes a guide for this.
How does it handle EIPs that depend on other draft EIPs?
The map phase does a dependency survey. For each required EIP you pick a strategy: vendor, mock, simulate, or defer. For draft EIPs without coverage, the Lab offers two paths — model the dependency first as a prerequisite, or mock the minimum surface.
What about really large EIPs?
When more than ~5 distinct mocks are needed, the Lab proposes decomposing into sub-experiments instead of one tangled attempt. Each sub-experiment has its own clean dependency slice.
Why track token counts?
EVVM is studying the cost and behavior of AI models on protocol-level work — for a research write-up and to make the economics of EIP prototyping transparent. The live meter shows your spend; we aggregate only anonymous counts.
Is it open source?
Yes, under the EVVM Noncommercial License v1.0. Free for research, personal, and noncommercial use. Commercial use requires a separate license — contact g@evvm.org.
launch lab
--:--:--