A Specialized Rollup with a Non-EVM Execution Layer for Financial Coordination

Hey there, I am making this entry to propose a rollup design for the sole purpose of financial coordination.
DeFi has matured well since the inception of Ethereum, and the concept of programmable finance is already a reality. While true, it has not always been smooth sailing, the causal effect has been exploits, billions of dollars lost. The solution has been more audits and better tooling, but I feel the space has been looking at the wrong layer to patch. We have reached a point where audits and formal verification are standard, yet security remains a perpetual game of patching the wrong things. We treat smart contract exploits as edge cases or developer errors, but they are the predictable outcomes of what our execution environment allows.

The Core Argument

Ethereum is Turing-complete by design. That generality is powerful and necessary, but does every use case require it? The answer is no, and financial systems are the clearest example of that.

Finance has always been a bounded rule set. From the earliest grain loans to modern clearinghouses, every financial system ever constructed has been a constraint system at its core: a defined set of participants, defined assets, a defined trigger, a defined formula, a defined time horizon. Nothing outside those bounds is permitted or relevant. This has never changed. What changed is the execution environment we chose to build them on.

Most DeFi vulnerabilities don’t originate in financial logic. They originate in the arbitrary computation surrounding it. When you implement a declarative pattern in a Turing-complete environment, you inherit the entire attack surface of that environment without needing any of its power.
The DAO hack is the clearest example. In 2016, 3.6 million ETH was drained through a reentrancy vulnerability. The root cause was not a developer error in the conventional sense. It was the predictable outcome of deploying a constrained financial system on an unconstrained execution layer:


function withdraw(uint256 _amount) external {require(balances[msg.sender] >= _amount, "Insufficient balance");(bool sent, ) = msg.sender.call{value: _amount}("");require(sent, "Failed to send Ether");balances[msg.sender] -= _amount; // state updated after external call}

The withdraw function sent ETH before updating the balance. Because the EVM permits reentrant calls, an attacker could recursively call withdraw before the balance was decremented. The FVL equivalent:


system: "DAO"pool:collect:from:type: anyonewhat:type: ethrules:conditions:- if:type: balance_gtevalue: "1"then:type: enablepermission: withdrawdistribute:formula:type: proportionalto:type: contributorstriggers: manualrights:anyone: [deposit, view]contributors: [withdraw]

In FVL that class of bug is entirely erased, not by adding a reentrancy guard, not by reordering logic, but because the execution environment does not permit that state transition to exist in the first place.

The Boundary

My proposal draws a formal line.
If a financial system can be described end-to-end with deterministic state transitions over known primitives, it belongs on FVL. If it requires arbitrary computation whose values cannot be known before execution, it belongs on Ethereum.
There is a small, legitimate class of protocols, Aave and Compound being the primary examples where the complexity genuinely requires general-purpose computation.

The Primitive Set

At its fundamental level, every financial system is a composition of five primitives:


system: <string>   # System namepool:    <config>  # Asset collection rulesrules:   <config>  # Conditional logic and distributionsrights:  <map>     # Permission definitionstime:    <config>  # Temporal constraintsoracles: <list>    # External data feeds

The combination of these primitives yields:

Lending Pool: pool + rights + oracles + rules
Staking Pool: pool + time + rights
Crowdfunding: pool + time + rules + rights
DAO: pool + rights + rules + oracles + time

A working example, a community staking system:


system: "CommunityStaking"pool:collect:from:type: token_holdersaddress: "0xYourToken"what:type: erc20address: "0xStakingToken"min:type: valueamount: "100"cap:type: valueamount: "1000000"rules:conditions:- if:type: time_gttimestamp: "1735689600"then:type: enablepermission: withdrawdistribute:formula:type: proportionalto:type: contributorstriggers: continuoustime:locks:type: durationseconds: "2592000"vesting:type: linearduration: "7776000"rights:contributors: [stake, unstake]admin: [pause, update_params]oracles: []

The Execution Model

Every FVL system is a finite state machine. This is the foundation on which FVL’s security and verifiability properties rest.

Determinism:
the transition function reads no external state during execution. Given the same initial state and the same ordered transaction sequence, any two parties arrive at the same result. State transitions are completely bounded and no interference is possible mid-execution.

Termination:
every transaction terminates in O(k) time, where k is the number of conditions defined in the system at deployment. k is fixed at deployment and cannot change. Execution costs are perfectly predictable, and an entire class of denial-of-service vectors does not exist.

Bounded attack surface:
the input alphabet is typed and finite. It is not possible to submit a transaction that calls an arbitrary function, references an undeclared oracle, or triggers behavior outside the defined primitive set.

Replayability:
because the transition function is deterministic and all inputs are recorded in an append-only log, the current state can always be reconstructed from scratch. Any party with access to the log can verify independently that the reported state is correct.

The Architecture

FVL is an Optimistic Rollup that settles to Ethereum mainnet, replacing the EVM execution environment with a purpose-built constrained runtime.


┌─────────────────────────────────────────┐│        Declaration Layer (YAML)          ││  parsing, validation, System ID          │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│     Execution Layer — FVL Runtime        ││  deterministic state transitions,        ││  block production, state roots           │└─────────────────┬───────────────────────┘▼┌─────────────────────────────────────────┐│     Settlement Layer — Ethereum L1       ││  state root anchoring, data              ││  availability, fraud proof adjudication  │└─────────────────────────────────────────┘

Each deployed system is identified by a content-addressed System ID:

system_id = Keccak256(canonical_json(system))

Any change to the definition, any field, any condition, any permission, produces a different ID. Duplicate deployment is rejected at the protocol level. Anyone can verify locally that a deployed system matches the definition they expect without trusting the deployer.

Primitive Extensions (FIPs)

The primitive set is intentionally finite. This is the source of its safety guarantees. New primitives are added through FVL Improvement Proposals, modeled on Ethereum’s EIP process.

The acceptance criterion is a single question: can this primitive be implemented without Turing-completeness?

If yes, it is a candidate for inclusion. If no, the use case belongs on Ethereum proper. This boundary is load-bearing. A version of FVL that adds general computation to accommodate edge cases loses its static analysis properties, its simple fraud proof verifier and its bounded execution guarantee