Add filteredFundsRecipient ArbOS state field and precompile#4347
Add filteredFundsRecipient ArbOS state field and precompile#4347Tristan-Wilson merged 3 commits intomasterfrom
Conversation
When transaction filtering redirects funds away from filtered transactions, the chain owner needs to control where those funds go. This adds a configurable filteredFundsRecipient address to ArbOS state, exposed through ArbOwner (setter + getter) and ArbOwnerPublic (getter). The setter emits a FilteredFundsRecipientSet event for transparency. When not explicitly set, the zero-address default causes the runtime to fall back to networkFeeAccount as the redirect destination. A centralized FilteredFundsRecipientOrDefault() helper encapsulates this resolution. All three new methods are version-gated at ArbosVersion_TransactionFiltering.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4347 +/- ##
==========================================
- Coverage 33.18% 32.95% -0.23%
==========================================
Files 488 488
Lines 57843 57866 +23
==========================================
- Hits 19196 19072 -124
- Misses 35302 35470 +168
+ Partials 3345 3324 -21 |
❌ 9 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
I have a couple of questions/concerns about the design and the rationale behind it.Design concern: fallback to networkFeeAccountWhy do we fall back to networkFeeAccount for restricted funds? From a business-logic perspective, that doesn’t feel like a convincing or safe default. My expectation would be that restricted funds should go to an isolated escrow-like account, ideally with metadata linking the funds to the original restricted address. That way, if the address is later unrestricted, the owner could reclaim their funds. We don’t need to implement reclaim/withdrawal functionality right now, but preserving the option by keeping funds in an isolated, untouchable place seems important. Conceptually, networkFeeAccount can spend those funds at any time, which makes the restriction effectively irreversible—even though restriction may be temporary. Precompile-methods guardsAnother question i have, I can see the precompile-methods guards, but why we have more check on other method like |
It's a reasonable default because funds there can be used by the chain owner, so if chain owner wants to refuns someone they can. If we do an isolated escrow-account the funds will be locked and nobody will be able to use them until we also implement a way to use that escrow account, which is really out of scope.
Adding a transaction filterer changes the security properties of the chain, which is why we don't let the chain owner do it immediately but with a 7-day delay. As long as there is no filterer, security of the chain itself does not change so we don't need to put that guard on other configs. |
3 participants
When transaction filtering redirects funds away from filtered transactions, the chain owner needs to control where those funds go. This adds a configurable filteredFundsRecipient address to ArbOS state, exposed through ArbOwner (setter + getter) and ArbOwnerPublic (getter). The setter emits a FilteredFundsRecipientSet event for transparency.
When not explicitly set, the zero-address default causes the runtime to fall back to networkFeeAccount as the redirect destination. A centralized FilteredFundsRecipientOrDefault() helper encapsulates this resolution.
All three new methods are version-gated at ArbosVersion_TransactionFiltering.
pulls in OffchainLabs/nitro-precompile-interfaces#32
fixes NIT-4482