## Quick Stage 1.4 Notes

We want to build confidence in kona as a fault proof program.

**What does building confidence in kona mean?**

We need to build tests around kona.
Concretely, this means building a high coverage test suite around the fault proof program.

We keep the execution extension in scope because it's really valuable to throw real traffic at the software to tease out issues. It should also be a low lift. We will have the ExEx just follow the safe head.

We'll also continue to run the long lived differential testing.

**Testing as a Framework**

By building a framework for multi-program testing, we force future hardforks to write tests covering the hardfork. This ensures that all programs are compliant with the hardfork. It sets up a standard and will hold us to it.

**Other Key Points**

Reth is outside the scope of the project.
The only thing we pull in from reth is their evm.
We also pull in their consensus types.
The Reth EVM should be passing all of the spec tests which is the same level of confidence we have in op-geth.