You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documents/CaveatEnforcers.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,26 +83,26 @@ Balance Change Enforcers are ideal for:
83
83
2.**No Aggregation**: Each enforcer operates independently and doesn't consider other enforcers in the chain
84
84
3.**Delegation Chain Issues**: In complex delegation chains, the same balance change might satisfy multiple enforcers, potentially bypassing intended security measures
85
85
86
-
**When to Use Regular vs Total Balance Enforcers**:
86
+
**When to Use Regular vs Multi Operation Balance Enforcers**:
87
87
- Use **Regular Balance Enforcers** for simple, single-enforcer scenarios
88
-
- Use **Total Balance Enforcers** when multiple enforcers might track the same recipient in a delegation chain
88
+
- Use **Multi Operation Balance Enforcers** when multiple enforcers might track the same recipient in a delegation chain
89
89
90
90
91
-
### Total Balance Change Enforcers
91
+
### Multi Operation Balance Enforcers
92
92
93
93
This includes:
94
-
-`ERC20TotalBalanceChangeEnforcer`
95
-
-`ERC721TotalBalanceChangeEnforcer`
96
-
-`ERC1155TotalBalanceChangeEnforcer`
97
-
-`NativeTokenTotalBalanceChangeEnforcer`
94
+
-`ERC20MultiOperationBalanceEnforcer`
95
+
-`ERC721MultiOperationBalanceEnforcer`
96
+
-`ERC1155MultiOperationBalanceEnforcer`
97
+
-`NativeTokenMultiOperationBalanceEnforcer`
98
98
99
99
Use these when multiple total-balance constraints may apply to the same recipient and token within a single redemption, and you need a single, coherent end-of-redemption check.
100
100
101
101
#### Key differences from Regular Balance Change Enforcers
102
102
103
103
**Regular Balance Change Enforcers** (e.g., `NativeBalanceChangeEnforcer`) check deltas around one execution using `beforeHook`/`afterHook`. Because multiple enforcers watching the same recipient can be satisfied by the same balance movement, they are best for independent, per-delegation constraints.
104
104
105
-
**Total Balance Change Enforcers** are designed for coordinated multi-step flows and now behave as follows:
105
+
**Multi Operation Balance Enforcers** are designed for coordinated multi-step flows and now behave as follows:
106
106
107
107
1.**Redemption-wide tracking**: Balance is tracked from the first `beforeAllHook` to the last `afterAllHook` for a given state key. The state key is defined by the recipient; for token-based variants it also includes the token address, and for ERC1155 it additionally includes the token ID. The state is scoped to the current `DelegationManager`. Any balance changes caused between those points (including by other enforcers, even those that modify state in `afterAllHook`, such as `NativeTokenPaymentEnforcer` even tho mixing with `NativeTokenPaymentEnforcer` is not recomended) are included in the final check.
108
108
2.**Initialization rule**: The first enforcer that starts tracking must be created by the account whose balance is being constrained. In other words, for the first `beforeAllHook` on a state key, the delegator must equal the recipient. If this is not true, the enforcer reverts.
@@ -127,7 +127,7 @@ Use these when multiple total-balance constraints may apply to the same recipien
127
127
- Alice → Bob: “Treasury can lose max 100 ETH”
128
128
- Bob → Dave: “Treasury can lose max 50 ETH” (stricter)
129
129
- With Regular enforcers, each delegation enforces its own limit, so the effective cap is 50 ETH.
130
-
-**Coordinated multi-operation transactions (one complex flow with multiple steps)**: Use Total Balance Change Enforcers. Example: a swap + fee + settlement that together must result in a minimum net profit for a recipient, or must not exceed a net loss cap across the whole flow. The owner may aggregate multiple requirements; redelegations can only make them stricter.
130
+
-**Coordinated multi-operation transactions (one complex flow with multiple steps)**: Use Multi Operation Balance Enforcers. Example: a swap + fee + settlement that together must result in a minimum net profit for a recipient, or must not exceed a net loss cap across the whole flow. The owner may aggregate multiple requirements; redelegations can only make them stricter.
131
131
132
132
Why accumulation is appropriate in coordinated flows: the intention is to verify the final end state of the recipient after all steps complete, not to enforce separate independent limits. In contrast, for independent limits, prefer Regular enforcers so each delegation remains self-contained.
0 commit comments