Thanks, both of those are my misses. I took “the principal’s hop is the root” as given and never tried the chain where the delegate is the root delegator, and I only reasoned about one copy of the caveat.
I read 728482a4. The write rule now sits in the Executor section, and _authorizer still reverts with UNAUTHORIZED_DELEGATE when take returns zero, which is what the nested case rests on. Agreed that my suggested line is not needed. Nothing further from me on the record.
Thanks for pulling these together. Being able to see what’s still available, lower a limit in one step without an old one lingering, and get a clear reason when something would fail covers the main things I’d want as a user.
Tested with our ERC-8001 profile on a local EVM: a cap cut after consent blocks the top-up without changing grant usage, funds or the order revision. Code and reproduction.
Thanks, you’re right on #13: if the replacement reaches the delegate first, the exposure is the sum of both grants, not the larger one. Holding the replacement back until the revocation is final is the right fix. Agreed on not adding replaces too: revoking on the first spend under the new grant would let the delegate decide when the old one ends.
@ted0x thanks for building this. I’ve linked agent-order-amendments from the README under “Integrations built by others” (pinned at d73681f), and covered it in a write-up of the integrations so far: ERC-8427 integrations: what has been tested so far | Long Run Advisory
Your cap-cut-after-consent test shows nicely that update binds the counterparty immediately. If you ever want it in-tree, a PR adding it to test/integrations/ is welcome.
Thanks Chris, appreciate the write-up and the invitation to add the test upstream.