---
eip: 7960
title: EOF - Extended types section
description: Extend EOF container's types section with an extra type parameter.
author: Wei Tang (@sorpaas)
discussions-to: https://ethereum-magicians.org/t/eip-series-evm64/23794
status: Draft
type: Standards Track
category: Core
created: 2025-05-28
requires: 3540
---

## Abstract

This EIP extends the definition of `types_section` in EOF format ([EIP-3540](./eip-3540.md)) with an additional `type` parameter.

## Motivation

An additional `type` parameter allows the EOF EVM interpreter to identify the "type" of a code section. This allows the interpreter to "interpret" each code section differently, allowing EOF function calls to, for example, invoke pure EVM64 code or even later support RISC-V.

## Specification

`types_section`, as defined in EIP-3540, is changed to be of the following format `(type, reserved, inputs, outputs, max_stack_increase)`. `type` is `uint8`, `reserved` is 24 bits, and `inputs`, `outputs`, `max_stack_increase` are defined as `uint8`, `uint8`, `uint16` respectively, the same as before. The only valid `type` defined in this EIP is `0x01`. Additional EIPs may be defined for other code section `type`s.

`version`, as defined in EIP-3540, is changed to `0x02`, to avoid the backward compatibility issue if a third-party chain already deployed EOF in production.

In EOF container, the following validation rules are added:

* If a `type` in `types_section` is not of a known type, then the validation fails.
* `reserved` in `types_section` must be all zeros.

## Rationale

The new `type` parameter allows a contract to "dispatch" to different variants of the interpreter to better suit its need.

* The portion of the code where it mainly interacts with Ethereum addresses, balances, storages may run "normal" EVM.
* The portion of the code that is computationally heavy may run faster EVM64, but loses the ability to directly interact with Ethereum addresses and balances.

Allowing this `type` to be defined for each code section ensures that a contract remains concise -- it can quickly switch between its computational needs and system/runtime needs.

`reserved` is added to `types_section` to maintain the proper padding. Each item in `types_section` is now 64 bits in total.

## Backwards Compatibility

As we know, EOF, including EIP-3540, was extremely close to being deployed before it was decided to withdraw from Fusaka. To avoid the issue that some third-party chains have already deployed EOF in production (given the state of EOF we can consider this to be likely), we bump `version` of EOF to `0x02`. `0x01` is now invalid.

No other backward compatibility issues found.

## Test Cases

To be added.

<!-- TODO -->

## Reference Implementation

To be added.

<!-- TODO -->

## Security Considerations

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).