Skip to content

Conversation

@dionysuzx
Copy link
Contributor

@dionysuzx dionysuzx commented Dec 19, 2025

Description

This PR introduces a new field to the EIP data type: statusHistory. This enables Forkcast to encode the minimum necessary information for users to understand how the inclusion status of an EIP progresses over forks and ACD calls.

This PR only adds status history for the most recent ACDE 226 call. In a future PR, we can add more status history and UI components to take advantage of the new data.

How I reviewed this PR

  1. Reviewed the EIP data type change and the changes to dependent UI components: 1e6488e
  2. Carefully reviewed the data migration: 06ef13c
  3. Compared these two commits side by side: CFI and DFI decisions based on ACDE 226 and 6f05661

return 'Declined for Inclusion';
case 'Included':
return 'Included';
case 'Withdrawn':
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added Withdrawn because i noticed it in several EIP json files, and felt Declined would be inaccurate:

6873.json - withdrawn
7667.json - withdrawn
7999.json - withdrawn

@dionysuzx dionysuzx marked this pull request as ready for review December 19, 2025 17:19
import { EIP } from '../types/eip';
import eipsDataRaw from './eips.json';

export const eipsData = eipsDataRaw as EIP[];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the reason for the type assertion is because typescript won't infer the union types inside the new statusHistory field.

i believe it's safer to keep the union and do a type assertion than use a string and leave it to inference. we can always strengthen safety in the future with a compile time check (eg. in compile-eips.mjs).

Copy link
Member

@wolovim wolovim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the PR! as discussed in dms, i think this is the right abstraction and starting point to be able to show eip history.

there's enough going on now that i think its worth validating data types when contributors edit eips. just tacked on ajv schema validation that runs during the build step - it actually caught one case where isHeadliner was found outside of the forkRelationships.

the other thing that comes to mind is how we might support references beyond just status updates, e.g., when an eip was presented, debated, mentioned. multiple ways forward that can be sorted out later (e.g., a new discussions key or adding new types and entries to the status history).

@wolovim wolovim merged commit 4a140d2 into ethereum:main Dec 19, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants