diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml new file mode 100644 index 0000000..978b083 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug-report.yml @@ -0,0 +1,51 @@ +name: "\U0001F41B Bug Report" +description: Report a bug on the website or in the framework. +title: "[Bug] " +labels: ["bug"] +body: + - type: markdown + attributes: + value: | + Thank you for reporting a bug. Please provide enough detail so we can reproduce and fix it. + + - type: input + id: url + attributes: + label: Page URL + description: The URL where you encountered the bug (if applicable). + placeholder: "https://feelyourprotocol.org/eip-7883-modexp-gas-cost-increase" + + - type: textarea + id: description + attributes: + label: What happened? + description: Describe the bug and what you expected to happen instead. + validations: + required: true + + - type: textarea + id: steps + attributes: + label: Steps to reproduce + description: Numbered steps to trigger the bug. + placeholder: | + 1. Go to … + 2. Click on … + 3. See error … + + - type: dropdown + id: browser + attributes: + label: Browser + options: + - Chrome + - Firefox + - Safari + - Edge + - Other + + - type: textarea + id: context + attributes: + label: Additional context + description: Screenshots, console errors, or anything else that helps. diff --git a/.github/ISSUE_TEMPLATE/general.yml b/.github/ISSUE_TEMPLATE/general.yml new file mode 100644 index 0000000..a774aab --- /dev/null +++ b/.github/ISSUE_TEMPLATE/general.yml @@ -0,0 +1,25 @@ +name: "\U0001F4AC General / Question" +description: Ask a question, suggest an improvement, or discuss an idea. +title: "[Discussion] " +labels: ["discussion"] +body: + - type: markdown + attributes: + value: | + Use this template for questions, feature ideas, or anything that doesn't fit the other templates. + + **Docs:** [How to Contribute](https://docs.feelyourprotocol.org/contributing/how-to-contribute) · [Architecture](https://docs.feelyourprotocol.org/guide/architecture) + + - type: textarea + id: description + attributes: + label: What's on your mind? + description: Describe your question, idea, or suggestion. + validations: + required: true + + - type: textarea + id: context + attributes: + label: Additional context + description: Links, screenshots, or references that help explain. diff --git a/.github/ISSUE_TEMPLATE/library-request.yml b/.github/ISSUE_TEMPLATE/library-request.yml new file mode 100644 index 0000000..702511e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/library-request.yml @@ -0,0 +1,54 @@ +name: "\U0001F4E6 Library Request" +description: Request adding a new dependency or setting up a managed fork. +title: "[Library] " +labels: ["library"] +body: + - type: markdown + attributes: + value: | + Use this template to request a new third-party dependency or a managed fork branch. + + **Docs:** [Third-Party Libraries](https://docs.feelyourprotocol.org/contributing/third-party-libraries) + + - type: dropdown + id: type + attributes: + label: Request type + options: + - "Add a new npm dependency" + - "Create a managed fork branch" + - "Other / not sure" + validations: + required: true + + - type: input + id: library + attributes: + label: Library name & URL + description: Name of the npm package and link to its repository. + placeholder: "e.g. @noble/curves — https://github.com/paulmillr/noble-curves" + validations: + required: true + + - type: input + id: exploration + attributes: + label: Related exploration + description: Which exploration will use this library? + placeholder: "e.g. eip-7951 (secp256r1)" + + - type: textarea + id: description + attributes: + label: What do you need? + description: | + For new dependencies: why is this library needed and can it be used unmodified? + For managed forks: what modifications are required and on which branch? + validations: + required: true + + - type: textarea + id: context + attributes: + label: Additional context + description: Links to your fork branch, related issues, or anything else. diff --git a/.github/ISSUE_TEMPLATE/new-exploration.yml b/.github/ISSUE_TEMPLATE/new-exploration.yml new file mode 100644 index 0000000..bc2d5e4 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/new-exploration.yml @@ -0,0 +1,82 @@ +name: "\U0001F680 New Exploration" +description: Propose a new interactive exploration for an EIP, protocol change, or research topic. +title: "[Exploration] " +labels: ["exploration"] +body: + - type: markdown + attributes: + value: | + Thanks for proposing a new exploration! Please fill out the sections below so we can discuss scope, library needs, and taxonomy placement before you start coding. + + **Docs:** [Adding an Exploration](https://docs.feelyourprotocol.org/contributing/adding-an-exploration) · [Architecture](https://docs.feelyourprotocol.org/guide/architecture) + + - type: input + id: eip + attributes: + label: EIP / Spec Reference + description: Link to the EIP, research paper, or forum post this exploration is based on. + placeholder: "https://eips.ethereum.org/EIPS/eip-XXXX" + validations: + required: true + + - type: textarea + id: description + attributes: + label: What should the exploration show? + description: Brief description of the interactive widget and what users will learn. + validations: + required: true + + - type: dropdown + id: topic + attributes: + label: Topic + description: "Which strategic pillar does this belong to? See [Topics](https://docs.feelyourprotocol.org/guide/architecture#topics)." + options: + - Scaling + - Privacy + - UX + - Security + - Robustness + - Interoperability + - "Not sure — need guidance" + validations: + required: true + + - type: dropdown + id: timeline + attributes: + label: Timeline + description: "Where does this sit on the protocol timeline? See [Timeline](https://docs.feelyourprotocol.org/guide/architecture#timeline)." + options: + - Fusaka + - Glamsterdam + - Ready + - Research + - Ideas + - "Not sure — need guidance" + validations: + required: true + + - type: input + id: tags + attributes: + label: Tags (up to 3–4) + description: "Existing tags or proposed new ones. See [Tags](https://docs.feelyourprotocol.org/guide/architecture#tags) for rules." + placeholder: "e.g. EVM, Gas Costs, Precompiles" + + - type: textarea + id: libraries + attributes: + label: Library needs + description: | + Which libraries will the exploration use? Are they already in `package.json`? Do you need a custom fork or new dependency? + + See [Third-Party Libraries](https://docs.feelyourprotocol.org/contributing/third-party-libraries) for the process. + placeholder: "e.g. @ethereumjs/evm (already available), noble-curves (needs adding)" + + - type: textarea + id: context + attributes: + label: Additional context + description: Anything else — mockups, related explorations, open questions. diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..bf7280e --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,43 @@ +## What does this PR do? + + + +## Related issue + + + +## Type of change + + + +- [ ] New exploration +- [ ] Improvement to an existing exploration +- [ ] New or updated E-Component +- [ ] Library addition or fork +- [ ] Documentation +- [ ] Bug fix +- [ ] Other: + +## Taxonomy (new explorations only) + + + +- **Topic:** +- **Timeline:** +- **Tags:** + +## Checklist + + + +- [ ] I have read the [contributing guide](https://docs.feelyourprotocol.org/contributing/how-to-contribute) +- [ ] Linting and type checking pass (`npm run lf && npm run type-check`) +- [ ] Unit tests pass (`npx vitest run`) +- [ ] E2E tests pass (`npm run test:e2e`) +- [ ] Production build succeeds (`npm run build`) +- [ ] New exploration is registered in `REGISTRY.ts` +- [ ] Library needs were discussed in a separate issue (if applicable — see [Third-Party Libraries](https://docs.feelyourprotocol.org/contributing/third-party-libraries)) + +## Screenshots / recordings + + diff --git a/dist/docs/404.html b/dist/docs/404.html index 5f5ec4e..e986ee9 100644 --- a/dist/docs/404.html +++ b/dist/docs/404.html @@ -9,14 +9,14 @@ - +
- + \ No newline at end of file diff --git a/dist/docs/contributing/adding-an-exploration.html b/dist/docs/contributing/adding-an-exploration.html index c753e0d..d01ae1c 100644 --- a/dist/docs/contributing/adding-an-exploration.html +++ b/dist/docs/contributing/adding-an-exploration.html @@ -9,16 +9,16 @@ - + - + - + -
Skip to content

Adding an Exploration

Each exploration lives in its own folder under src/explorations/ with a few files. This guide walks you through adding a new one.

Quick Overview

An exploration folder looks like this:

src/explorations/eip-XXXX/
+    
Skip to content

Adding an Exploration

Each exploration lives in its own folder under src/explorations/ with a few files. This guide walks you through adding a new one.

Quick Overview

An exploration folder looks like this:

src/explorations/eip-XXXX/
 ├── info.ts          # Metadata (required)
 ├── MyC.vue          # Interactive widget (required)
 ├── examples.ts      # Example presets (recommended)
@@ -45,7 +45,7 @@
   poweredBy: [
     { name: 'EthereumJS', href: 'https://github.com/ethereumjs/ethereumjs-monorepo' },
   ],
-}

Field Reference

FieldRequiredDescription
idYesUnique identifier, matches the folder name
pathYesURL path for the exploration page
titleYesDisplay title
infoURLYesLink to the specification or reference material
topicYesTopic ID this exploration belongs to. Must be one of the fixed set: scaling, privacy, ux, security, robustness, interoperability. Topics are static and not added via contributions — see Architecture for the full list.
timelineYesTimeline ID for this exploration (e.g. fusaka, glamsterdam, ready, research, ideas). See Architecture for details.
tagsYesArray of Tag enum values (max 3–4). Tags are broader technical concepts that must be reusable across explorations. New tags can be proposed — see Architecture for rules and the current list.
imageNoImported image for topic overview display
introTextNoHTML-formatted introduction paragraph
usageTextNoHTML-formatted usage instructions
creatorNameNoDisplay name of the exploration's creator
creatorURLNoURL to the creator's profile (X/Twitter, GitHub, etc.)
poweredByYesArray of { name, href } for library credits

Step 3: Create examples.ts

Define example presets that users can select from a dropdown:

typescript
import type { Examples } from '@/explorations/REGISTRY'
+}

Field Reference

FieldRequiredDescription
idYesUnique identifier, matches the folder name
pathYesURL path for the exploration page
titleYesDisplay title
infoURLYesLink to the specification or reference material
topicYesTopic ID this exploration belongs to. Must be one of the fixed set: scaling, privacy, ux, security, robustness, interoperability. Topics are static and not added via contributions — see Architecture for the full list.
timelineYesTimeline ID for this exploration (e.g. fusaka, glamsterdam, ready, research, ideas). See Architecture for details.
tagsYesArray of Tag enum values (max 3–4). Tags are broader technical concepts that must be reusable across explorations. New tags can be proposed — see Architecture for rules and the current list.
imageNoImported image for topic overview display — see Images for format, palette, and style guidance
introTextNoHTML-formatted introduction paragraph
usageTextNoHTML-formatted usage instructions
creatorNameNoDisplay name of the exploration's creator
creatorURLNoURL to the creator's profile (X/Twitter, GitHub, etc.)
poweredByYesArray of { name, href } for library credits

Step 3: Create examples.ts

Define example presets that users can select from a dropdown:

typescript
import type { Examples } from '@/explorations/REGISTRY'
 
 export const examples: Examples = {
   basic: {
@@ -144,7 +144,7 @@
 export const EXPLORATIONS: Explorations = {
   // ... existing explorations
   [eipXXXX.id]: eipXXXX,
-}

The router reads from EXPLORATIONS and automatically creates the route — no manual route configuration needed.

Step 6: Install Dependencies

If your widget needs additional libraries, install them:

bash
npm install some-library

Import libraries only in your MyC.vue — never in shared code. This keeps each exploration's dependencies isolated via Vite's code splitting.

If you need a custom library fork (e.g. with experimental features), see Library Forks.

Step 7: Add Tests

Each exploration should have a tests.spec.ts file in its folder. Tests verify that your exploration's metadata, examples, and config are correct.

What to Test

All explorations should test:

  • info.ts — correct id, path, topic, and poweredBy
  • examples.ts — each example has the right number of values, valid hex data, and a non-empty title

Precompile explorations should additionally test:

  • config.tsdefaultExample exists in examples, value field count and URL params match expectations
  • assembleData/parseData — if defined, verify they produce correct output and are inverse operations

Example: Custom Exploration Test

typescript
import { describe, expect, it } from 'vitest'
+}

The router reads from EXPLORATIONS and automatically creates the route — no manual route configuration needed.

Step 6: Install Dependencies

If your widget needs additional libraries, install them:

bash
npm install some-library

Import libraries only in your MyC.vue — never in shared code. This keeps each exploration's dependencies isolated via Vite's code splitting.

If you need a library that isn't in package.json yet, or need a customized version, see Third-Party Libraries.

Step 7: Add Tests

Each exploration should have a tests.spec.ts file in its folder. Tests verify that your exploration's metadata, examples, and config are correct.

What to Test

All explorations should test:

  • info.ts — correct id, path, topic, and poweredBy
  • examples.ts — each example has the right number of values, valid hex data, and a non-empty title

Precompile explorations should additionally test:

  • config.tsdefaultExample exists in examples, value field count and URL params match expectations
  • assembleData/parseData — if defined, verify they produce correct output and are inverse operations

Example: Custom Exploration Test

typescript
import { describe, expect, it } from 'vitest'
 
 import { examples } from '../examples'
 import { INFO } from '../info'
@@ -205,8 +205,8 @@
 npx vitest run src/explorations/eip-XXXX    # run tests for one exploration

Step 8: Verify

bash
npm run dev          # check your exploration locally
 npm run lf           # format + lint
 npm run type-check   # TypeScript check
-npm run build        # verify production build

Checklist

  • [ ] Created src/explorations/<id>/info.ts with metadata
  • [ ] Created src/explorations/<id>/MyC.vue with interactive widget
  • [ ] Created src/explorations/<id>/examples.ts with example presets
  • [ ] Created src/explorations/<id>/tests.spec.ts with unit tests
  • [ ] Added import and entry in src/explorations/REGISTRY.ts
  • [ ] Installed library dependencies (if needed)
  • [ ] All unit tests pass
  • [ ] Linting and type checking pass
  • [ ] Production build succeeds

This project and its documentation are under active development.

- +npm run build # verify production build

Checklist

  • [ ] Created src/explorations/<id>/info.ts with metadata
  • [ ] Created src/explorations/<id>/MyC.vue with interactive widget
  • [ ] Created src/explorations/<id>/examples.ts with example presets
  • [ ] Created src/explorations/<id>/tests.spec.ts with unit tests
  • [ ] Added import and entry in src/explorations/REGISTRY.ts
  • [ ] Installed library dependencies (if needed)
  • [ ] All unit tests pass
  • [ ] Linting and type checking pass
  • [ ] Production build succeeds

This project and its documentation are under active development.

+ \ No newline at end of file diff --git a/dist/docs/contributing/how-to-contribute.html b/dist/docs/contributing/how-to-contribute.html index b8f1cf0..94e4ff6 100644 --- a/dist/docs/contributing/how-to-contribute.html +++ b/dist/docs/contributing/how-to-contribute.html @@ -9,22 +9,22 @@ - + - + - + -
Skip to content

How to Contribute

Contributions are what make Feel Your Protocol useful. Whether you are adding a brand-new exploration, polishing an existing one, or improving the shared components — every contribution helps the Ethereum community understand protocol changes better.

Ways to Contribute

Add a New Exploration

This is the most impactful contribution. Each exploration is a self-contained folder with metadata and an interactive widget. The Adding an Exploration guide walks you through it step by step.

Improve an Existing Exploration

  • Better examples and presets
  • UI/UX improvements
  • Bug fixes
  • More informative intro and usage texts

Build or Improve E-Components

E-Components are reusable Ethereum-specific components (e.g. a precompile interface). If you spot a pattern shared across explorations, it might be a candidate for a new E-Component.

Improve Documentation

Fix typos, add guides, clarify explanations. Documentation lives in the docs/ folder as standard markdown files. Preview locally with:

bash
npm run docs:dev

Report Issues

Found a bug or have a suggestion? Open an issue on GitHub.

Development Workflow

1. Setup

bash
git clone https://github.com/feelyourprotocol/website.git
+    
Skip to content

How to Contribute

Contributions are what make Feel Your Protocol useful. Whether you are adding a brand-new exploration, polishing an existing one, or improving the shared components — every contribution helps the Ethereum community understand protocol changes better.

Ways to Contribute

Add a New Exploration

This is the most impactful contribution. Each exploration is a self-contained folder with metadata and an interactive widget. The Adding an Exploration guide walks you through it step by step.

Improve an Existing Exploration

  • Better examples and presets
  • UI/UX improvements
  • Bug fixes
  • More informative intro and usage texts

Build or Improve E-Components

E-Components are reusable Ethereum-specific components (e.g. a precompile interface). If you spot a pattern shared across explorations, it might be a candidate for a new E-Component.

Improve Documentation

Fix typos, add guides, clarify explanations. Documentation lives in the docs/ folder as standard markdown files. Preview locally with:

bash
npm run docs:dev

Report Issues

Found a bug or have a suggestion? Open an issue on GitHub.

Development Workflow

1. Setup

bash
git clone https://github.com/feelyourprotocol/website.git
 cd website
 npm install

2. Develop

bash
npm run dev          # start dev server

3. Verify

Before submitting a PR, run all quality checks:

bash
npm run lf           # format + lint (auto-fix)
 npm run type-check   # TypeScript type checking
 npx vitest run       # unit tests (single run)
-npm run test:e2e     # E2E tests

4. Submit

  • Fork the repository and create a feature branch
  • Make your changes
  • Ensure all checks pass
  • Submit a pull request with a clear description of what you changed and why

What Goes Where

What you are working onWhere it lives
A new explorationsrc/explorations/<id>/
Exploration metadatasrc/explorations/<id>/info.ts
Interactive widgetsrc/explorations/<id>/MyC.vue
Example presetssrc/explorations/<id>/examples.ts
Exploration registrysrc/explorations/REGISTRY.ts
E-Componentssrc/eComponents/<name>EC/
Shared UI componentssrc/eComponents/ui/
Unit testssrc/views/__tests__/ (or co-located __tests__/)
E2E testscypress/e2e/
Documentationdocs/

Further Reading

This project and its documentation are under active development.

- +npm run test:e2e # E2E tests

4. Submit

  • Fork the repository and create a feature branch
  • Make your changes
  • Ensure all checks pass
  • Submit a pull request with a clear description of what you changed and why

What Goes Where

What you are working onWhere it lives
A new explorationsrc/explorations/<id>/
Exploration metadatasrc/explorations/<id>/info.ts
Interactive widgetsrc/explorations/<id>/MyC.vue
Example presetssrc/explorations/<id>/examples.ts
Exploration registrysrc/explorations/REGISTRY.ts
E-Componentssrc/eComponents/<name>EC/
Shared UI componentssrc/eComponents/ui/
Unit testssrc/views/__tests__/ (or co-located __tests__/)
E2E testscypress/e2e/
Documentationdocs/

Further Reading

This project and its documentation are under active development.

+ \ No newline at end of file diff --git a/dist/docs/guide/architecture.html b/dist/docs/guide/architecture.html index 39a5312..447ba98 100644 --- a/dist/docs/guide/architecture.html +++ b/dist/docs/guide/architecture.html @@ -9,16 +9,16 @@ - + - + -
Skip to content

Architecture

Overview

Feel Your Protocol is a Vue 3 application built with Vite. The core idea is simple: each Ethereum protocol change gets its own interactive widget that runs real library code in the browser.

Tech Stack

Content Model

Content is organized around three taxonomies:

Explorations

The core content unit. Each exploration represents an interactive widget for a protocol change — EIPs, ERCs, or research topics. Explorations live in src/explorations/, one folder per exploration:

src/explorations/eip-7883/
+    
Skip to content

Architecture

Overview

Feel Your Protocol is a Vue 3 application built with Vite. The core idea is simple: each Ethereum protocol change gets its own interactive widget that runs real library code in the browser.

Tech Stack

Content Model

Content is organized around three taxonomies:

Explorations

The core content unit. Each exploration represents an interactive widget for a protocol change — EIPs, ERCs, or research topics. Explorations live in src/explorations/, one folder per exploration:

src/explorations/eip-7883/
 ├── info.ts         # Metadata: id, title, path, topic, timeline, tags, poweredBy, …
 ├── MyC.vue         # The interactive widget
 └── examples.ts     # Example presets for the widget

Each info.ts exports a const INFO object typed as Exploration. The REGISTRY.ts imports all INFO constants and assembles them into the EXPLORATIONS dictionary. The router reads from this dictionary to automatically create routes — no manual route registration needed.

Topics

Topics are the high-level strategic pillars that group explorations by theme. Each exploration belongs to exactly one topic via the topic field in its info.ts. Topics are defined in src/explorations/TOPICS.ts.

Topics are a static, curated set — they are not meant to be added as part of regular contributions. The current topics are:

IDTitleDescription
scalingScalingData availability, throughput, and L2 enablement
privacyPrivacyZK-proofs, homomorphic encryption, private mempools
uxUXAccount abstraction, wallet infrastructure, signature schemes
securitySecurityValidator incentives, cryptographic agility, MEV mitigations
robustnessRobustnessGas cost accuracy, EVM semantics hardening, spec clarity
interoperabilityInteroperabilityCross-chain standards, bridge infrastructure, signature scheme support

When adding an exploration, pick the topic that best reflects the primary concern of the protocol change.

Timeline

Timeline is a taxonomy that combines two dimensions: how settled an idea is (from early mention to finalized spec) and where it sits relative to mainnet Ethereum (specific hardfork vs. general readiness stage). Each exploration belongs to exactly one timeline entry via the timeline field in its info.ts. Timeline entries are defined in src/explorations/TIMELINE.ts.

Hardfork entries are named after their Ethereum community event city of origin (e.g. "Fusaka" from Osaka, "Glamsterdam" from Amsterdam). The non-hardfork categories (Ready, Research, Ideas) are static. New hardfork entries can be added as Ethereum's upgrade schedule evolves.

Tags

Tags enrich navigation by adding broader Ethereum technical concepts, protocol-relevant areas, or general technology topics from the blockchain space. Each exploration can have up to 3–4 tags. Tags are defined as a TypeScript enum in src/explorations/TAGS.ts.

Tags grow with contributions — unlike topics and timeline, new tags can be proposed when adding an exploration. They must follow these rules:

RuleExample
Must be reusable beyond a single explorationEVM ✅ — EIP-7883
Short form preferredEVM ✅ — Ethereum Virtual Machine
No redundancy with existing tagsGas Costs exists → don't add Gas
When in doubt, choose the more generic conceptGas Costs ✅ — Gas Increases

Format: Enum keys use CamelCase (GasCosts), all-caps for abbreviations (EVM). Members must be sorted alphabetically (enforced by lint).

E-Components

E-Components are reusable Ethereum-specific components that encapsulate common patterns across explorations. They live in src/eComponents/ and follow a naming convention: folder and component names are post-fixed with EC.

The first E-Component is precompileInterfaceEC, which provides a complete precompile exploration interface — input parsing, hardfork comparison, result display — as a single component backed by a composable:

src/eComponents/precompileInterfaceEC/
@@ -32,7 +32,7 @@
 const ExplorationComponent = defineAsyncComponent(
   componentModules[`../explorations/${explorationId}/MyC.vue`]
 )

Testing Strategy

The project uses a hybrid testing approach:

  • Unit tests (Vitest + Vue Test Utils) for component rendering, content verification, and UI logic — fast and focused
  • E2E tests (Cypress) as lean smoke tests for critical navigation flows and page-level integration

Unit tests live alongside their components in __tests__/ folders. E2E tests are consolidated in cypress/e2e/.

This project and its documentation are under active development.

- + \ No newline at end of file diff --git a/dist/docs/guide/getting-started.html b/dist/docs/guide/getting-started.html index e7c8272..c69eeb3 100644 --- a/dist/docs/guide/getting-started.html +++ b/dist/docs/guide/getting-started.html @@ -9,16 +9,16 @@ - + - + -
Skip to content

Getting Started

What is Feel Your Protocol?

Feel Your Protocol is an interactive website that lets you explore Ethereum protocol changes hands on. Instead of just reading specifications, you can interact with real Ethereum library code running directly in the browser.

Each protocol change — called an Exploration — gets its own page with a dedicated interactive widget. Explorations cover EIPs, ERCs, and protocol research. They are organized through three taxonomies: Topics (static strategic pillars like "Scaling" or "UX"), Timeline (maturity and hardfork placement like "Fusaka" or "Research"), and Tags (reusable technical concepts like "EVM" or "Precompiles") — making it easy to discover and navigate related protocol changes.

Prerequisites

  • Node.js v20.19+ or v22.12+
  • npm (comes with Node.js)

Setup

Clone the repository and install dependencies:

bash
git clone https://github.com/feelyourprotocol/website.git
+    
Skip to content

Getting Started

What is Feel Your Protocol?

Feel Your Protocol is an interactive website that lets you explore Ethereum protocol changes hands on. Instead of just reading specifications, you can interact with real Ethereum library code running directly in the browser.

Each protocol change — called an Exploration — gets its own page with a dedicated interactive widget. Explorations cover EIPs, ERCs, and protocol research. They are organized through three taxonomies: Topics (static strategic pillars like "Scaling" or "UX"), Timeline (maturity and hardfork placement like "Fusaka" or "Research"), and Tags (reusable technical concepts like "EVM" or "Precompiles") — making it easy to discover and navigate related protocol changes.

Prerequisites

  • Node.js v20.19+ or v22.12+
  • npm (comes with Node.js)

Setup

Clone the repository and install dependencies:

bash
git clone https://github.com/feelyourprotocol/website.git
 cd website
 npm install

Development

Start the website dev server:

bash
npm run dev

Start the docs dev server:

bash
npm run docs:dev

Quality Checks

bash
npm run lf           # format + lint (auto-fix)
 npm run lf:ci        # lint + format check (CI mode, no auto-fix)
@@ -64,7 +64,7 @@
 ├── docs/                          # Documentation (VitePress)
 ├── cypress/                       # E2E tests
 └── .github/workflows/             # CI workflows

This project and its documentation are under active development.

- + \ No newline at end of file diff --git a/dist/docs/hashmap.json b/dist/docs/hashmap.json index 301df05..483d297 100644 --- a/dist/docs/hashmap.json +++ b/dist/docs/hashmap.json @@ -1 +1 @@ -{"contributing_adding-an-exploration.md":"iBUUBPTj","contributing_ai-assisted-development.md":"lydwZLlM","contributing_available-e-components.md":"B4Q_z4Hi","contributing_code-conventions.md":"C86y1S4H","contributing_e-components.md":"PhGEgitZ","contributing_how-to-contribute.md":"DneE9-kZ","contributing_library-forks.md":"DYk1JQhp","contributing_styling.md":"BKPSSvmJ","contributing_ui-components.md":"vHxMK_fH","guide_architecture.md":"B6eczQC1","guide_getting-started.md":"BjX7SsDe","index.md":"COXeFy5O"} +{"contributing_adding-an-exploration.md":"CLO_TxsK","contributing_ai-assisted-development.md":"lydwZLlM","contributing_available-e-components.md":"B4Q_z4Hi","contributing_code-conventions.md":"C86y1S4H","contributing_e-components.md":"PhGEgitZ","contributing_how-to-contribute.md":"G0y-xflE","contributing_images.md":"DdK4lm4N","contributing_styling.md":"BKPSSvmJ","contributing_third-party-libraries.md":"DAoVaD5b","contributing_ui-components.md":"vHxMK_fH","guide_architecture.md":"B6eczQC1","guide_getting-started.md":"BjX7SsDe","index.md":"COXeFy5O"} diff --git a/dist/docs/index.html b/dist/docs/index.html index dc29eb4..65d8f68 100644 --- a/dist/docs/index.html +++ b/dist/docs/index.html @@ -9,9 +9,9 @@ - + - + @@ -19,7 +19,7 @@
Skip to content

Feel Your ProtocolInteractive Ethereum Protocol Explorations

Explore, visualize and understand Ethereum protocol changes — hands on.

Beta — Contributions Welcome!

This project is in beta. Everything works, but the APIs of reusable components (E-Components, shared UI) are still evolving. That means contributions may require some manual coordination during review until the interfaces fully stabilize — we are happy to guide you through! The fastest way to get started is to add a new exploration.

This project and its documentation are under active development.

- + \ No newline at end of file diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts index 872b29f..aaa986f 100644 --- a/docs/.vitepress/config.ts +++ b/docs/.vitepress/config.ts @@ -24,12 +24,13 @@ export default defineConfig({ { text: 'How to Contribute', link: '/contributing/how-to-contribute' }, { text: 'AI-Assisted Development', link: '/contributing/ai-assisted-development' }, { text: 'Adding an Exploration', link: '/contributing/adding-an-exploration' }, + { text: 'Images', link: '/contributing/images' }, { text: 'UI Components', link: '/contributing/ui-components' }, { text: 'E-Components', link: '/contributing/e-components' }, { text: 'Available E-Components', link: '/contributing/available-e-components' }, { text: 'Styling & Design', link: '/contributing/styling' }, { text: 'Code Conventions', link: '/contributing/code-conventions' }, - { text: 'Library Forks', link: '/contributing/library-forks' }, + { text: 'Third-Party Libraries', link: '/contributing/third-party-libraries' }, ], }, ], diff --git a/docs/contributing/adding-an-exploration.md b/docs/contributing/adding-an-exploration.md index cc6aeaa..ddda8f8 100644 --- a/docs/contributing/adding-an-exploration.md +++ b/docs/contributing/adding-an-exploration.md @@ -66,7 +66,7 @@ export const INFO: Exploration = { | `topic` | Yes | Topic ID this exploration belongs to. Must be one of the fixed set: `scaling`, `privacy`, `ux`, `security`, `robustness`, `interoperability`. Topics are static and not added via contributions — see [Architecture](/guide/architecture#topics) for the full list. | | `timeline` | Yes | Timeline ID for this exploration (e.g. `fusaka`, `glamsterdam`, `ready`, `research`, `ideas`). See [Architecture](/guide/architecture) for details. | | `tags` | Yes | Array of `Tag` enum values (max 3–4). Tags are broader technical concepts that must be reusable across explorations. New tags can be proposed — see [Architecture](/guide/architecture#tags) for rules and the current list. | -| `image` | No | Imported image for topic overview display | +| `image` | No | Imported image for topic overview display — see [Images](/contributing/images) for format, palette, and style guidance | | `introText` | No | HTML-formatted introduction paragraph | | `usageText` | No | HTML-formatted usage instructions | | `creatorName` | No | Display name of the exploration's creator | @@ -234,7 +234,7 @@ npm install some-library Import libraries only in your `MyC.vue` — never in shared code. This keeps each exploration's dependencies isolated via Vite's code splitting. -If you need a custom library fork (e.g. with experimental features), see [Library Forks](/contributing/library-forks). +If you need a library that isn't in `package.json` yet, or need a customized version, see [Third-Party Libraries](/contributing/third-party-libraries). ## Step 7: Add Tests diff --git a/docs/contributing/how-to-contribute.md b/docs/contributing/how-to-contribute.md index 0bcc2dc..e4ef704 100644 --- a/docs/contributing/how-to-contribute.md +++ b/docs/contributing/how-to-contribute.md @@ -29,7 +29,11 @@ npm run docs:dev ### Report Issues -Found a bug or have a suggestion? [Open an issue](https://github.com/feelyourprotocol/website/issues) on GitHub. +Found a bug or have a suggestion? [Open an issue](https://github.com/feelyourprotocol/website/issues) on GitHub. Our issue templates will guide you through the relevant details. + +::: tip Open an issue early +For new explorations, especially those that need library additions or custom forks, it's a good idea to **open an issue before you start coding**. This lets us align on taxonomy placement, library setup, and scope — and avoids surprises during review. +::: ## Development Workflow @@ -86,4 +90,4 @@ npm run test:e2e # E2E tests - [Adding an Exploration](/contributing/adding-an-exploration) — step-by-step guide - [Using E-Components](/contributing/e-components) — reusable Ethereum-specific components - [Code Conventions](/contributing/code-conventions) — imports, naming, linting, testing -- [Library Forks](/contributing/library-forks) — when you need a custom library build +- [Third-Party Libraries](/contributing/third-party-libraries) — using, adding, and forking libraries diff --git a/docs/contributing/images.md b/docs/contributing/images.md new file mode 100644 index 0000000..2c81052 --- /dev/null +++ b/docs/contributing/images.md @@ -0,0 +1,406 @@ +# Images + +Each exploration can have a cover image that represents the protocol change visually. Images appear on the home page topic cards and on the topic overview pages. They are optional but strongly encouraged — they make the site more engaging and help visitors quickly identify explorations. + +::: tip The fun part +Think of the image as the icing on the cake after building your exploration. The code and the widget are the serious work — the image is where you get to be artistic, experiment with AI tools, and create something visually striking. It's your chance to express what the protocol change *feels* like, not just what it does. Enjoy it! +::: + +## Format & Size + +### Allowed Formats + +| Format | Extension | Notes | +|--------|-----------|-------| +| **WebP** | `.webp` | Preferred — best compression-to-quality ratio | +| **PNG** | `.png` | Good for sharp lines and transparency | +| **JPEG** | `.jpg` / `.jpeg` | Fine for photographic or painterly styles | +| **SVG** | `.svg` | Great for vector illustrations, resolution-independent | + +WebP is recommended and used by all existing explorations. Avoid formats like BMP, TIFF, or GIF. + +### Dimensions & File Size + +| Property | Recommendation | +|----------|---------------| +| **Orientation** | Portrait | +| **Aspect ratio** | 3:4 | +| **Resolution** | 768×1024 | +| **Minimum** | 512px on the shorter side | +| **Maximum** | 1536px on the longer side | +| **File size** | Under 200 KB (WebP), under 400 KB (PNG/JPEG) | + +The image file goes into your exploration folder as `image.webp` (or `.png`, `.jpg`) and is imported in `info.ts`: + +```typescript +import image from './image.webp' + +export const INFO: Exploration = { + // ... + image, + // ... +} +``` + +## Color Palette + +This is the one area with strict rules. The color palette for your image must be derived from the **topic color** assigned to your exploration. This keeps the site visually coherent across contributions. + +### Allowed Colors + +Every image may use: + +1. **The full greyscale range** — black, white, and all greys in between +2. **Shades of the topic color** — from the lightest tint (50) to the deepest shade (900), including tones in between the Tailwind steps + +No other hues are allowed. The image should feel monochromatic with the topic color as its accent. + +### Topic Color Reference + +Use this table to find the palette for your exploration's topic. Each topic includes a visual swatch, a hex table, and a **copy-paste snippet** you can drop straight into your AI image prompt. + +#### Scaling — Orange + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#fff7ed` | `#ffedd5` | `#fed7aa` | `#fdba74` | `#fb923c` | `#f97316` | `#ea580c` | `#c2410c` | `#9a3412` | `#7c2d12` | + +Prompt snippet: + +```text +shades of orange (hex range: #fff7ed to #7c2d12) +``` + +#### Privacy — Yellow + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#fefce8` | `#fef9c3` | `#fef08a` | `#fde047` | `#facc15` | `#eab308` | `#ca8a04` | `#a16207` | `#854d0e` | `#713f12` | + +Prompt snippet: + +```text +shades of yellow (hex range: #fefce8 to #713f12) +``` + +#### UX — Blue + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#eff6ff` | `#dbeafe` | `#bfdbfe` | `#93c5fd` | `#60a5fa` | `#3b82f6` | `#2563eb` | `#1d4ed8` | `#1e40af` | `#1e3a8a` | + +Prompt snippet: + +```text +shades of blue (hex range: #eff6ff to #1e3a8a) +``` + +#### Security — Green + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#f0fdf4` | `#dcfce7` | `#bbf7d0` | `#86efac` | `#4ade80` | `#22c55e` | `#16a34a` | `#15803d` | `#166534` | `#14532d` | + +Prompt snippet: + +```text +shades of green (hex range: #f0fdf4 to #14532d) +``` + +#### Robustness — Purple + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#faf5ff` | `#f3e8ff` | `#e9d5ff` | `#d8b4fe` | `#c084fc` | `#a855f7` | `#9333ea` | `#7e22ce` | `#6b21a8` | `#581c87` | + +Prompt snippet: + +```text +shades of purple (hex range: #faf5ff to #581c87) +``` + +#### Interoperability — Red + +
+
+
+
+
+
+
+
+
+
+
+
+ +| Shade | 50 | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | +|-------|----|-----|-----|-----|-----|-----|-----|-----|-----|-----| +| Hex | `#fef2f2` | `#fee2e2` | `#fecaca` | `#fca5a5` | `#f87171` | `#ef4444` | `#dc2626` | `#b91c1c` | `#991b1b` | `#7f1d1d` | + +Prompt snippet: + +```text +shades of red (hex range: #fef2f2 to #7f1d1d) +``` + +## Drawing Style + +The visual style should lean towards **abstract technical illustration** rather than photorealistic rendering or cartoons. Think along these lines: + +- **Architectural blueprints** — clean lines, measured precision, schematic layouts +- **Industrial design sketches** — product concepts, exploded views, annotated diagrams +- **Pen-and-ink drafting** — crosshatching, fine linework, hand-drawn texture +- **Etching / engraving** — dense parallel lines, high contrast, vintage technical feel + +### Composition Rules + +- **One focal point.** The image should concentrate on a single action, detail, or movement at its center. Avoid busy scenes with many competing elements — abstract and reduce. +- **White margins.** The subject should naturally fade or dissolve towards the edges so that generous white space surrounds it. The image borders should be purely white. +- **No lettering.** No text, labels, captions, or watermarks anywhere in the image. + +### Color Separation + +Keep greyscale tones and topic color tones clearly separate. Elements should be either drawn in black/grey/white *or* rendered in topic color shades — avoid muddying the two together. Within the allowed color palette, be **bold and vivid**: use the full range from light tints to deep shades for visual punch. + +## Theming + +### Ethereum Association + +The image should evoke a **subtle** connection to Ethereum, its ecosystem, or decentralized technology — think geometric patterns reminiscent of blockchain structure, faint diamond shapes woven into the composition, or network-like line patterns. Avoid prominent Ethereum logos or brand marks; the association should feel organic, not stamped on. + +### Mood & Aesthetic + +Styles that work well with the technical illustration approach: + +- **Cypherpunk** — encrypted transmissions, masked identities, circuit traces +- **Futurism** — kinetic forms, velocity, overlapping geometric planes +- **Solarpunk** — organic-meets-technical, optimistic infrastructure +- **Constructivism** — bold structure, angular composition, propaganda-poster energy + +These are suggestions, not requirements. The key is that the image feels intentional and technically grounded, not generic or decorative. + +## Finding a Subject + +This is where the creative freedom kicks in. The hardest part is often deciding *what* to depict — but it's also the most rewarding. There's no single right answer; different people will find wildly different visual metaphors for the same protocol change, and that's exactly what makes the gallery interesting. Here are three approaches to get you started: + +### Goal-Oriented + +Visualize the *outcome* the protocol change aims for. + +- "Post-Quantum Cryptography" → a lattice structure shielding a diamond +- "Scaling" → a network expanding outward from a central beacon +- "Privacy" → layered veils over a geometric identity + +### Structure-Oriented + +Depict the *architecture* described in the specification. + +- "Proposer-Builder Separation" → two interlocking mechanisms, one assembling, one validating +- "PeerDAS" → a distributed mesh of nodes with data shards flowing between them +- "Account Abstraction" → a key morphing into multiple authentication pathways + +### Process-Oriented + +Illustrate the *flow* of how the change works. + +- "Frame Transactions" → a figure moving through sequential frames, each transforming the state +- "Blob Transactions" → data parcels ascending from an execution layer into a beacon above +- "Gas Repricing" → a balance scale recalibrating under shifting weights + +## AI Prompt Templates + +Most images will be generated with AI tools (ChatGPT/DALL-E, Midjourney, Stable Diffusion, etc.). Don't be shy about iterating — generating a few variations and picking the one that clicks is part of the fun. Below are two ready-to-use prompt templates. Copy the **prompt snippet** from your topic's color section above and paste it into the `[TOPIC COLOR]` placeholder. + +### Template A — You Choose the Subject + +Use this when you have a specific visual idea for your exploration. Replace the placeholders: + +```text +Create a portrait-format (3:4) abstract illustration in the style of an +architectural blueprint or industrial design sketch. + +Subject: [YOUR SUBJECT DESCRIPTION — e.g. "a lattice-based cryptographic +shield emerging from intersecting geometric planes"] + +Style and composition: +- Abstract, reduced — focus on ONE central action, detail, or movement +- Pen-and-ink drafting, technical etching, crosshatching +- The subject fades naturally into generous white margins at all edges +- Very subtle Ethereum association (faint geometric patterns, not logos) +- Cypherpunk / futurist mood +- No text, no lettering, no watermarks + +Colors — strict: +- Greyscale tones (black, white, greys) AND [TOPIC COLOR] + (hex range: [LIGHTEST HEX] to [DARKEST HEX]). No other hues. +- Use the color palette boldly and vividly across the full shade range +- Keep greyscale and color clearly separated — elements are either + drawn in black/grey OR rendered in color, not mixed together +``` + +**Example** (for an exploration in the **Scaling / Orange** topic): + +```text +Create a portrait-format (3:4) abstract illustration in the style of an +architectural blueprint or industrial design sketch. + +Subject: a distributed mesh network expanding outward from a central beacon +node, with data shards flowing between peers in concentric rings. + +Style and composition: +- Abstract, reduced — focus on ONE central action, detail, or movement +- Pen-and-ink drafting, technical etching, crosshatching +- The subject fades naturally into generous white margins at all edges +- Very subtle Ethereum association (faint geometric patterns, not logos) +- Cypherpunk / futurist mood +- No text, no lettering, no watermarks + +Colors — strict: +- Greyscale tones (black, white, greys) AND shades of orange + (hex range: #fff7ed to #7c2d12). No other hues. +- Use the color palette boldly and vividly across the full shade range +- Keep greyscale and color clearly separated — elements are either + drawn in black/grey OR rendered in color, not mixed together +``` + +### Template B — Fully AI-Derived + +Use this when you want the AI to pick the subject based on the EIP title and summary. Just fill in the EIP details: + +```text +I'm creating a cover image for an interactive exploration of [EIP TITLE] +([EIP NUMBER]) on an Ethereum protocol education site. + +The EIP in one sentence: [ONE-SENTENCE SUMMARY OF THE EIP] + +Create a portrait-format (3:4) abstract illustration that visually represents +this protocol change. Choose an evocative subject — it can represent the goal, +the internal architecture, or the process flow of the change. + +Style and composition: +- Abstract, reduced — concentrate on ONE central action, detail, or movement +- Architectural blueprint / industrial design sketch / pen-and-ink etching +- The subject fades naturally into generous white margins at all edges +- Very subtle Ethereum association (faint geometric patterns woven into the + composition — no prominent logos or brand marks) +- Cypherpunk / futurist mood +- No text, no lettering, no watermarks + +Colors — strict: +- Greyscale tones (black, white, greys) AND [TOPIC COLOR] + (hex range: [LIGHTEST HEX] to [DARKEST HEX]). No other hues. +- Use the color palette boldly and vividly across the full shade range +- Keep greyscale and color clearly separated — elements are either + drawn in black/grey OR rendered in color, not mixed together +``` + +**Example** (for EIP-7883, **Robustness / Purple** topic): + +```text +I'm creating a cover image for an interactive exploration of "ModExp Gas Cost +Increase" (EIP-7883) on an Ethereum protocol education site. + +The EIP in one sentence: EIP-7883 recalibrates the gas cost formula for the +ModExp precompile to better reflect actual computation costs on modern hardware. + +Create a portrait-format (3:4) abstract illustration that visually represents +this protocol change. Choose an evocative subject — it can represent the goal, +the internal architecture, or the process flow of the change. + +Style and composition: +- Abstract, reduced — concentrate on ONE central action, detail, or movement +- Architectural blueprint / industrial design sketch / pen-and-ink etching +- The subject fades naturally into generous white margins at all edges +- Very subtle Ethereum association (faint geometric patterns woven into the + composition — no prominent logos or brand marks) +- Cypherpunk / futurist mood +- No text, no lettering, no watermarks + +Colors — strict: +- Greyscale tones (black, white, greys) AND shades of purple + (hex range: #faf5ff to #581c87). No other hues. +- Use the color palette boldly and vividly across the full shade range +- Keep greyscale and color clearly separated — elements are either + drawn in black/grey OR rendered in color, not mixed together +``` + +## Quick Reference + +| Rule | Detail | +|------|--------| +| Format | WebP preferred; PNG, JPEG, SVG also accepted | +| Orientation | Portrait (3:4) | +| Resolution | 768×1024 recommended; min 512px short side, max 1536px long side | +| File size | < 200 KB (WebP) or < 400 KB (PNG/JPEG) | +| Colors | Greyscale + topic color shades only; keep the two clearly separated | +| Composition | Abstract, one focal point, generous white margins at edges | +| Style | Technical illustration — blueprints, sketches, etching | +| Theme | Subtle Ethereum association; cypherpunk / futurist mood optional | +| Lettering | None — no text, labels, or watermarks | +| File location | `src/explorations//image.webp` | diff --git a/docs/contributing/library-forks.md b/docs/contributing/library-forks.md deleted file mode 100644 index 7f3f145..0000000 --- a/docs/contributing/library-forks.md +++ /dev/null @@ -1,46 +0,0 @@ -# Library Forks - -Feel Your Protocol runs real Ethereum library code in the browser. Some explorations need a modified version of a library — for example, a version with a new precompile implementation or experimental gas calculation changes that have not been released yet. - -Rather than waiting for upstream releases, the project maintains targeted forks used by specific exploration pages. - -## How Forks Work - -### npm Package Aliases - -Multiple versions of the same library coexist in `package.json` using npm aliases: - -```json -{ - "dependencies": { - "@ethereumjs/evm": "^10.1.1-nightly.1", - "@ethereumjs/evm-experimental": "npm:@ethereumjs/evm@^11.0.0-fork.1" - } -} -``` - -Each alias is a fully independent install. In code, you import the specific version you need: - -```typescript -import { EVM } from '@ethereumjs/evm' -import { EVM as EVMExp } from '@ethereumjs/evm-experimental' -``` - -### Monorepo Libraries - -For libraries from monorepos (like EthereumJS), where the target package has several intra-monorepo dependencies, use **pre-bundled ESM builds**. The fork is bundled on the monorepo side with all internal dependencies resolved, producing a single ESM file with no internal wiring issues. - -### Per-Route Isolation - -Each fork is only imported in its specific exploration's `MyC.vue`. Thanks to Vite's code splitting, the fork's code is only loaded when the user visits that exploration's page. Other pages are unaffected. - -**Key rule:** Only import fork-specific libraries in your `MyC.vue` — never in shared code or E-Components. - -## Adding a New Fork - -1. Fork the upstream library (or create a branch if you have access) -2. Make your changes -3. For single-package repos: add an npm alias in `package.json` pointing to your fork -4. For monorepo packages: create a bundled build, then reference it -5. Import the fork only in your exploration's `MyC.vue` -6. Document the fork in your PR description diff --git a/docs/contributing/third-party-libraries.md b/docs/contributing/third-party-libraries.md new file mode 100644 index 0000000..78959f0 --- /dev/null +++ b/docs/contributing/third-party-libraries.md @@ -0,0 +1,107 @@ +# Third-Party Libraries + +Feel Your Protocol runs real Ethereum library code in the browser. Most explorations need protocol-level functionality — EVM execution, cryptographic primitives, transaction encoding — that comes from third-party libraries. This page explains how to use them, from the simplest case to deep customizations. + +::: tip Open an issue first +If your exploration needs a library that isn't already in `package.json`, or requires a custom fork, **open a GitHub issue before you start coding**. This lets us settle the library situation up front and avoids frustration later. The issue templates will guide you through the relevant questions. +::: + +## 1. Use an Existing Dependency + +The simplest path. Check `package.json` — if the library you need is already there, just import it in your `MyC.vue`: + +```typescript +import { EVM } from '@ethereumjs/evm' +``` + +Thanks to Vite's code splitting, each exploration's imports are loaded on demand. Only the libraries needed for the page the user visits are downloaded. + +**Key rule:** Only import libraries in your exploration's `MyC.vue` (or files within your exploration folder) — never in shared code or E-Components. + +## 2. Request a New Dependency + +If a well-maintained, popular library exists for what you need but isn't in `package.json` yet, you can request its addition: + +1. **Open a GitHub issue** describing the library, why you need it, and which exploration will use it +2. Ideally, submit the dependency addition as a **separate PR** first, so we can review and merge it independently +3. Once merged, import it in your exploration + +We keep the dependency list lean — the library should be actively maintained, reasonably sized, and needed by at least one exploration. + +## 3. Extend Within Your Exploration + +If the library is already available but you need slightly different behavior — a custom precompile, an adjusted gas calculation, a patched encoding — try to make the customization **within your exploration folder** first. This avoids forking entirely. + +Common techniques: + +- **Subclassing** — extend a library class and override specific methods +- **Composition** — wrap library functions with your custom logic +- **Built-in extension APIs** — some libraries provide dedicated customization hooks. For example, the EthereumJS EVM has a [custom precompile API](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm#custom-precompiles) that lets you register precompiles without modifying the library itself + +Place custom code in your exploration's folder (e.g. a `custom/` subfolder) so it stays isolated. + +## 4. Use a Managed Fork (Special Libraries) + +For protocol-core libraries where deep modifications are common, Feel Your Protocol maintains **dedicated forks** under the `feelyourprotocol` GitHub organization. These forks allow multiple explorations to carry independent, branch-isolated customizations in a controlled way. + +### Currently Managed Forks + +| Library | Fork URL | Upstream | +|---------|----------|----------| +| **EthereumJS** | [feelyourprotocol/ethereumjs-monorepo](https://github.com/feelyourprotocol/ethereumjs-monorepo) | [ethereumjs/ethereumjs-monorepo](https://github.com/ethereumjs/ethereumjs-monorepo) | + +Want to propose adding another library as a managed fork? Open an issue. Capacity to maintain forks is limited, so this is reserved for libraries with frequent deep-customization needs. + +### Fork Workflow + +If your exploration needs a modification to one of the managed fork libraries: + +1. **Fork the original upstream library** to your own GitHub account +2. **Create a branch** and implement your changes there +3. **Request a named target branch** on the FYP fork — ask a maintainer (via your issue) to create a branch like `my-custom-exploration` on the managed fork +4. **Open a PR** from your branch towards that named target branch on the FYP fork +5. Your branch is reviewed, merged into the FYP fork, and **kept as a separate branch** — it won't be merged into `master` +6. **A release is built** from that branch and integrated into the site's `package.json` using an [npm alias](#npm-package-aliases) + +::: warning Security policy +For security reasons, code is never integrated directly from a contributor's personal fork or branch into the site. All library code flows through the managed FYP fork, where it can be reviewed and maintained. +::: + +### npm Package Aliases + +Multiple versions or forks of the same library coexist in `package.json` using npm aliases: + +```json +{ + "dependencies": { + "@ethereumjs/evm": "^10.1.1-nightly.1", + "@ethereumjs/evm-experimental": "npm:@ethereumjs/evm@^11.0.0-fork.1" + } +} +``` + +Each alias is a fully independent install. In your exploration, import the specific version you need: + +```typescript +import { EVM } from '@ethereumjs/evm' +import { EVM as EVMExp } from '@ethereumjs/evm-experimental' +``` + +### Monorepo Libraries + +For libraries from monorepos (like EthereumJS), where the target package has several intra-monorepo dependencies, use **pre-bundled ESM builds**. The fork is bundled on the monorepo side with all internal dependencies resolved, producing a single ESM file with no wiring issues. + +### Per-Route Isolation + +Each fork is only imported in its specific exploration's `MyC.vue`. Thanks to Vite's code splitting, the fork's code is only loaded when the user visits that page. Other explorations are unaffected. + +## Decision Flowchart + +Not sure which approach to take? Walk through this: + +1. **Is the library already in `package.json`?** → Use it directly ([Level 1](#_1-use-an-existing-dependency)) +2. **Is it a well-known library you can use unmodified?** → Request addition ([Level 2](#_2-request-a-new-dependency)) +3. **Can you customize via subclassing or built-in APIs?** → Extend in-place ([Level 3](#_3-extend-within-your-exploration)) +4. **Do you need deep library modifications?** → Use the managed fork workflow ([Level 4](#_4-use-a-managed-fork-special-libraries)) + +When in doubt, **open an issue and ask**. Library integration is often a case-by-case decision that benefits from a quick conversation before you invest implementation time. diff --git a/src/explorations/eip-7594/image.webp b/src/explorations/eip-7594/image.webp index 2d29da5..0784a30 100644 Binary files a/src/explorations/eip-7594/image.webp and b/src/explorations/eip-7594/image.webp differ diff --git a/src/explorations/eip-7883/image.webp b/src/explorations/eip-7883/image.webp index d550afd..57f9c86 100644 Binary files a/src/explorations/eip-7883/image.webp and b/src/explorations/eip-7883/image.webp differ