Add invariant tests for spending limits across redelegation chains

Open
  • Is something wrong?
#216 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
53/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
solidity
Domain
blockchain, testing

Research direction

Read test/DelegationChainWithCaveatsTest.t.sol for existing chain test setup and documents/CaveatEnforcers.md for hook order. The proposed file is test/invariants/RedelegationSpendLimit.invariant.t.sol; begin by tracing how those tests construct links and inspect spentMap. Done means the stated balance, per-link limit, disabled-link, and redelegator-balance properties hold across generated redemption and toggle sequences.

Written by the indexing model from the issue text.

Description

Description

I'd like to add Foundry invariant tests for the amount enforcers when they sit on more than one link of a delegation chain.

The suite has no invariant or fuzz tests today, and the test files for the cumulative enforcers use root delegations only. Limits on a redelegation appear in fixed integration scenarios such as _createAdapterRedelegation in VedaLending.t.sol. A tree of delegations has more states than those reach: siblings sharing a parent's budget, batched redemptions, links disabled and re-enabled between spends.

Technical Details
  • One new test file, test/invariants/RedelegationSpendLimit.invariant.t.sol. No change to src/, foundry.toml or CI; run length is set inline with forge-config.
  • A handler redeems down a fixed four-link tree, singly and in two-context batches, and disables or re-enables links between calls. Each link carries ERC20TransferAmountEnforcer, and sibling limits add up to more than their parent's.
  • Ghost totals per link are compared with spentMap and token balances after every call.

I have a working draft. On main at b4b8c41 all the properties below hold over 256 runs of 128 calls, in under 20 seconds. To check the tests can fail, I weakened four things in a local copy and each was caught: the enforcer's limit check, storing spent, the disabled-delegation check, and running beforeHook on every link.

Acceptance Criteria

Over any sequence of redemptions, batches and enable or disable calls:

  • The root delegator's balance falls by at most the root link's limit.
  • spentMap for each link stays within that link's limit.
  • spentMap for each link equals what left through it, so reverted redemptions count nothing.
  • Nothing moves through a disabled link.
  • Redelegators' balances don't move.

Scenario:

  • GIVEN a root link limited to 100, with redelegations to A (60) and B (70)
  • WHEN A and B redeem in any order and any amounts
  • THEN root pays at most 100, A's path at most 60 and B's at most 70
References
  • test/DelegationChainWithCaveatsTest.t.sol, the fixed three-level chain with per-call limits
  • documents/CaveatEnforcers.md, hook order across a chain

If this is useful, I'll open the PR against this issue. The native, period and streaming enforcers could follow separately if you want them.

AI use: an AI assistant helped write the tests and this issue; I reviewed both before posting.

Dominant language
Solidity
Stars
230
Forks
122
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MetaMask/delegation-framework

All issues in MetaMask/delegation-framework

Similar issues

More Blockchain issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.