Title: EIP_7906__Restricted_Behavior_Transaction_Type
Category: EIPs

Author: alex-forshtat-tbk
Date: 2025-03-12T16:19:31.067Z

Discussion topic for EIP-7906:


github.com/ethereum/EIPs








Add EIP: Restricted Behavior Transaction Type


ethereum:master ← eth-infinitism:restricted_writes_transaction_eip



          opened 04:11PM - 12 Mar 25 UTC




            forshtat
          



+282
-0






**ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN [ETHEREUM/ERCS](https://gith…ub.com/ethereum/ercs)**

--

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.






The point of this EIP is to provide the mechanism for wallets to actually restrict the outcomes of transactions the users are signing. This is just a building block on top of which a truly secure wallet UI can be build.

Author: odysseas_eth
Date: 2025-03-13T17:43:46.667Z

@alex-forshtat-tbk I love this proposal.
It’s very similar to the concept of Assertions that we have been developing for a while at Phylax as part of a wider protocol. Essentially, taking a more liberal approach of running some user defined solidity after every state transition, which evaluates whether it should be a valid state transition or not.
I have been ideating on a wallet/user-facing integration of the above concept, with wallets being able to offer “pre-defined” assertions for users to enable. One big difference is that we intend to integrate at the network level with enforcement being done by block builders.
Would love to collaborate on this. How are you thinking the support for EIP-7906? A modified full-node that makes the checks at the RPC level?

Author: alex-forshtat-tbk
Date: 2025-03-13T22:57:04.888Z

Hello @odysseas_eth, thank you for your feedback!
Regarding the Solidity defined Assertions, I think this is a great idea which gives a remarkable flexibility in defining the restrictions for a transaction. This is something that, unfortunately, will never be possible with a pre-determined set of restrictions like in EIP-7906.
It is not very clear if this approach of using full-fledged Solidity code for restrictions is practical for the Ethereum mainnet, but it may be worth it to think about having some minimal scripting support for restrictions in EIP-7906.

I have been ideating on a wallet/user-facing integration of the above concept, with wallets being able to offer “pre-defined” assertions for users to enable.

Yes, in general I would hope that it becomes a common practice for smart contract developers and dapps to provide the transactions’ restrictions in the same way they currently provide raw calldata, and for the wallets to have a list of “pre-defined” restrictions for all major known contract types.
For instance, an ERC-20 token transfer will have a very simple “pre-defined” restriction saying “your balance goes down by X, another balance goes up by X, nothing else happens anywhere”, and this restriction is basically “hard-coded” in the wallet’s immutable code.
And for a transaction to a contract that is unknown to the wallet, the dApp would provide a restriction to the wallet saying “writes slots X,Y,Z in contract A and writes any slot in contract B and nothing else happens anywhere”.
There is already a set of RPC APIs around EIP-2930 access lists that could be used to prepare the restrictions.
The wallet will need to present this information to the user in a somewhat human-readable way. And in an “advanced” mode users should be able to get involved and modify the proposed restrictions, for example adding an extra ban on moving some especially valuable asset.

How are you thinking the support for EIP-7906? A modified full-node that makes the checks at the RPC level?

With this being an “EIP”, if this proposal were to be accepted all full nodes in Ethereum would be modified in order to support the restrictions. We may require some modifications to the RPC methods but in general once the transaction is broadcast through the eth_sendRawTransaction RPC method there is no difference with other transactions, and the receipt will just state that the transaction reverted on-chain if the restrictions are violated.

Would love to collaborate on this.

Sure, that would be great! Please feel free to share any feedback on the proposal itself and if there are any additional details about the assertions mechanism you have built, I would be happy to learn more.

Author: odysseas_eth
Date: 2025-03-14T18:44:20.133Z

alex-forshtat-tbk:

Regarding the Solidity defined Assertions, I think this is a great idea which gives a remarkable flexibility in defining the restrictions for a transaction. This is something that, unfortunately, will never be possible with a pre-determined set of restrictions like in EIP-7906.
It is not very clear if this approach of using full-fledged Solidity code for restrictions is practical for the Ethereum mainnet, but it may be worth it to think about having some minimal scripting support for restrictions in EIP-7906.


Well, following the same philosophy of the EIP, we could send the EVM bytecode as part of the request, communicating that the EVM bytecode must not revert if executed after the transaction is applied to the state.
One thing that I like with the EIP is that because of the restricted nature of what constraints can be expressed, it doesn’t need to handle the complexity of adding a turing-complete user-defined computation at the end of a state transition.



 alex-forshtat-tbk:

For instance, an ERC-20 token transfer will have a very simple “pre-defined” restriction saying “your balance goes down by X, another balance goes up by X, nothing else happens anywhere”, and this restriction is basically “hard-coded” in the wallet’s immutable code.


Yes, I have the exact same concept in mind.



 alex-forshtat-tbk:

With this being an “EIP”, if this proposal were to be accepted all full nodes in Ethereum would be modified in order to support the restrictions. We may require some modifications to the RPC methods but in general once the transaction is broadcast through the eth_sendRawTransaction RPC method there is no difference with other transactions, and the receipt will just state that the transaction reverted on-chain if the restrictions are violated.


To be honest, I don’t see why we should be limited by the EIP process here. This feature we are describing here, either via EIP-7006 restrictions or the more turing-complete script version that I described with Assertions, could be unilaterally implemented as an experimental RPC path. Getting Infura/Metamask on-board for their default RPC endpoints would probably deliver more than 80% of the value. Instead of the transaction reverting on-chain, it would be instead dropped by the RPC node and then communicated to the user/wallet.
Of-course handling that at the RPC level introduces the risk of an attack which would modify the state inside the block in such a way that the transaction would actually violate the predicates when it’s executed inside the block. That would have been missed at the RPC level, since by necessity it can only check the transaction against the latest finalised state of the blockchain and not against the state on top of which the transaction will be executed when it’s added to the new block.
Will circle back with more comments as I reflect on this EIP.

Author: alex-forshtat-tbk
Date: 2025-03-14T18:58:51.019Z

odysseas_eth:

We could send the EVM bytecode as part of the request, communicating that the EVM bytecode must not revert if executed after the transaction is applied to the state.


Right, however in order to support all features of restrictions this bytecode will probably need to have a mechanism to access private slots of contracts, so it can’t be achieved with a pure  EVM code.



 odysseas_eth:

Getting Infura/Metamask on-board for their default RPC endpoints would probably deliver more than 80% of the value.


My biggest concern with this approach is establishing a false sense of security, which is the worst possible outcome. It is more or less trivial for an attacker to extract the signed transaction from the user’s communication with Infura/Metamask and broadcast it to a non-compliant RPC endpoint.
However, the users may trust the wallet’s message saying that the transaction does not modify any important storage state and sign the transaction on a very shady front-end dapp.
This is a threat in addition to the one you described where the transaction changes its behaviour once it is included on-chain, which can be achieved in many different ways by an attacker.

Author: dror
Date: 2025-03-18T12:03:46.425Z

odysseas_eth:

Instead of the transaction reverting on-chain, it would be instead dropped by the RPC node and then communicated to the user/wallet.


This is a great idea, and I think there are “RPC security proxy” services like this: validating a transaction before forwarding it to the actual blockchain.
But this solution is a completely centralized service: the user trusts the RPC service to perform this validation.
We want the user’s assertion to be enforced by the user (that is, signed by the wallet) and that no party afterwards can bypass this assertion.
Can you think of any other way to achieve this goal ?

Author: SamWilsn
Date: 2025-04-01T16:45:04.687Z

Now that we have 7702, can we emulate this without a protocol change? Just revert the whole transaction if certain properties no longer hold at the end of execution.

Author: alex-forshtat-tbk
Date: 2025-04-01T19:08:07.951Z

Well, some checks can indeed be performed fully on-chain by smart accounts but, in my opinion, one of the most powerful features of protocol-level restrictions is their ability to specify a rule that sounds roughly as “these things are allowed, and absolutely nothing else is guaranteed to happen as part of this transaction”.
Such a rule is simply impossible to check from inside the EVM. For example, the account could theoretically check that all balances of ERC-20 tokens it holds did not change, but it does not seem possible to check that there was no change in allowances. Checking that there were no ERC-721 token transfers during the transaction would require an ownership check for each held token.
Additionally, the on-chain checks would have to rely on the view functions of the contracts involved to provide all the necessary data, which may not always be sufficient. Private fields of smart contracts may also hold information critical for users’ security. For example, an implementation address of an upgradeable contract might be private, and therefore it cannot be checked by an EIP-7702 account.
But, if this upgradeable contract is trusted by the user, unexpected change to the implementation value may be as dangerous as a token transfer.
For me the whole point of EIP-7906 is to explicitly force the protocol change that provides a higher-level control mechanism on top of what can be achieved on-chain, kind of the last line of defence for the users.