Two Legs, One Engine
Feel Your Protocol is designed around two legs that share one engine. The same EthereumJS core powers both the educational website (live today) and the headless MCP server for the future Ethereum protocol (built, not yet publicly launched) — but each leg is a different surface and is framed differently. Who those surfaces serve — humans and agents as equal customers — is Two Audiences.
The two legs
| Leg A — Website (live) | Leg B — MCP server (built; public launch pending) | |
|---|---|---|
| Surface | Humans in the browser | Agents on the hosted MCP — two audiences |
| Experience | Interactive, visual, educational explorations | Headless, deterministic, well-documented; MCP tool bindings |
| Optimizes for | Intuition, narrative, trust | Latency, reliability, exact deterministic output |
| Economics | Community, fan token, education | Open at launch (full Glamsterdam). Later, x402 for EIPs ahead of the current hardfork |
| Docs | website-docs | mcp-docs |
The shared engine is the modular EthereumJS stack and the fork/EIP pipeline behind it — real on the website side and in the execution engine; the public hosted gateway is what launch week ships.
They reinforce each other (the DevRel funnel)
An early instinct was to fully separate "marketing" the website from the API. That's wrong: aesthetics don't sell infrastructure, but trust, reputation and educational authority absolutely do. The website is the project's DevRel engine — and it's already running:
- Proof-of-work halo. A meticulous, interactive breakdown of a fork is undeniable proof of competence — it converts into technical trust for the MCP underneath.
- Education as top-of-funnel. People arrive to learn about an upcoming protocol change; the natural next step is to use the hosted MCP through their agent.
- The agent trust proxy. Humans configure which tools their agents may use. A developer will be far more likely to allowlist our MCP server if they already know and trust the FYP website.
A simple mental model:
The website is the textbook. The MCP server is the lab equipment.
The textbook is live. The lab equipment is built; the hosted door opens in launch week.
How they connect, concretely
- The website remains the visual entry point — each exploration links to its MCP twin on
mcp-docs/use/eips/. - Both legs live as separate sites/subdomains, with the main website acting as the binding ground that ties the fleet together (
docs.,community-token., thisroadmap.,mcp-docs., andmcp.at launch).
The discipline this requires
Two legs means two kinds of work — UI/narrative polish vs. ruthless uptime and deterministic testing. As a small team this is a real resource tension; we manage it explicitly rather than pretending both can move at full speed at once. See Principles & Operating Discipline.
Changelog
- v0.52026-10-01Leg B economics: open Glamsterdam at launch; x402 for EIPs ahead of the hardfork.
- v0.42026-09-24Legs as surfaces; who they serve is Two Audiences.
- v0.32026-09-02Leg B is built (not publicly launched); mcp-docs exists; launch week is the hosted milestone.
- v0.22026-06-30Initial two-legs model — website live, API planned.