Abstract
This standard defines a proxy that coordinates execution sessions by temporarily caching a program and its associated calldata in transient storage. The proxy forwards the cached program to a fixed implementation through DELEGATECALL and uses a handler flag to control whether subsequent reentrant invocations are dispatched.
The program remains unchanged throughout an execution session, while the cached calldata is replaced on each accepted invocation. This enables a single implementation to coordinate callback-driven execution using different programs and calldata without deploying a new contract for each execution.
Motivation
Many advanced execution strategies require dynamically changing execution logic, particularly when interacting with external contracts that invoke callbacks during execution.
Traditionally, dynamically changing the execution logic of a contract may require deploying a new contract containing the desired runtime code. This introduces deployment costs, including contract creation and code-deposit costs.
Flash Loan Proxy separates the execution program from the implementation responsible for interpreting it. Instead of deploying a new contract for each program, callers provide the program as calldata. The proxy temporarily caches the program and forwards it to an implementation that interprets and executes it.
This design provides several benefits:
- Dynamic execution programs: Different programs can be supplied for different execution sessions without deploying a new contract.
- Callback coordination: The proxy can dispatch reentrant invocations to the same implementation while preserving the program associated with the current session.
- Reduced deployment overhead: Programs are supplied as transaction data rather than deployed as contract code.
- Flexible execution environments: The implementation can interpret native EVM bytecode, EOF-related representations, or other program formats supported by its execution engine.
- Larger programs: The program size is not subject to the EIP-170 deployed-contract code-size limit merely because it is supplied as calldata. It remains subject to transaction and block resource limits.
The proxy does not define a programming language, virtual machine, or execution semantics. These are determined by the implementation.
Link to Github
The security section covers callback authentication, but authorization to start a session also needs an explicit trust model. At DEPTH_SLOT == 0, the reference proxy accepts a new program without checking the caller. With a permissionless interpreter that permits arbitrary external calls, another caller could submit a program that spends leftover proxy balances or uses a user’s remaining ERC-20 allowance via transferFrom. Clearing the transient cache leaves those balances and allowances intact.
A security note and a test with two different session initiators would help make this risk concrete. Could the ERC specify how initial callers are authorized or document the balance and approval restrictions needed for a permissionless deployment?
2 Likes
Thank you for pointing this out. We agree that session initialization is permissionless in the reference implementation and that clearing transient storage does not isolate persistent balances or token allowances between sessions.
This is intentional. Flash Loan Proxy is designed as a minimal, transparent execution coordinator rather than a custody or authorization layer. It does not establish ownership of assets, authenticate session initiators, or enforce isolation between execution sessions. These responsibilities are delegated to the implementation and the integrating system.
Consequently, a permissionless implementation that supports arbitrary external calls must be treated as a public execution endpoint. Any assets held by the proxy, or any outstanding token allowances granted to the proxy, may be consumed by any caller able to submit an appropriate program.
In the intended smart-account integration model, the account controls the execution context and supplies the necessary assets and permissions for each transaction. For example, it may transfer assets to the proxy, grant narrowly scoped approvals, invoke the proxy, and enforce post-execution conditions. Approvals should be revoked or otherwise constrained within the same atomic transaction where applicable. The account can also verify the resulting balances and other execution invariants before considering the operation successful.
The proxy itself does not require this integration model. Implementations may enforce their own authorization policies, while permissionless implementations may deliberately expose unrestricted execution.
We will clarify these trust assumptions in the Security Considerations section and include a test demonstrating that persistent balances and allowances are not isolated between different session initiators.