Ensure caveat enforcers are capable of requiring payment

[danfinlay]

A user might want to charge for using a permission they have, and this should be supported.

Examples:

• Using an NFT minting right to sell that NFT before minting it.
• Creating a monetized sales link, or adding a commission fee to a sales link.

This may require a schema change for caveat enforcers which allow them to accept tx-contextual additional information from the caller, to provide things like additional delegations enabling withdrawing a payment, for example.

[danfinlay]

Ok I'm starting to think the "paid caveats" goal is not worth optimizing for in v2. Reasons:

• Not compatible with 4337
• Can be approximated (with a small extra gas cost) by batching transfers to the caveat enforcer before the paid operation (probably to a method that identifies what it's for). Will incur a 5k gas cost for having written state if it cleans it up, but that's not huge.

[DaveAppleton]

It could still be useful to pass these items to the caveat

intendedSender , the root signer
canGrant , the current delegator
delegation.delegate , the current delegatee

This would allow much more flexibility, for example checking that each of these has some other kind of authorisation.

Of course this would still not allow final delegate to pay everybody in the chain.

[DaveAppleton]

Final thought - certainly possible (I did it) but it needs significant code and schema changes to avoid stack too deep errors in DelegatableCore and DelegatableRelayCore

Security is an issue - I made the paid caveat enforcer only callable from the specific contract to avoid an attacker calling the enforcer and stealing funds between a user making an allowance and using it.