Skip to content

[Deprecated] Improve CaveatBuilders to be less risky #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from

Conversation

jeffsmale90
Copy link
Collaborator

📝 Description

This changes how a developer interacts with CaveatBuilders in order to reduce the risk of signing delegations with insufficient attenuation.

🔄 What Changed?

List the specific changes made:

  • rename allowEmptyCaveats to allowInsecureUnrestrictedDelegation
  • require allowInsecureUnrestrictedDelegation not just when creating a CaveatBuilder, but also when creating, and when signing a Delegation
  • createCaveatBuilder moved from root export to /utils
  • All CaveatBuilders now accept config object, rather than positional arguments
  • Standardised callData to calldata in the ExactCalldata terms builder
  • Introduces UnitOfAuthority CaveatBuilder factories as the primary interface to creating caveats

🚀 Why?

Even with the allowEmptyCaveats flag, there is a high risk of developers creating delegations with less attenuation than they expect. Because of this, we have made two general changes:

  1. It's not much harder to accidentally create empty caveat collections, because the configuration flag is more likely to stand out as a problem, because of it's name. It is now required with creating and signing delegations, which will capture cases when the CaveatBuidler interface is not used, and generally introduces more friction to high risk full authority delegations.

  2. Instead of a developer starting with Full Authority, and attenuating that through addition of Caveats, a developer now starts with a "Unit of Authority", which constrains the delegation to interact with a native token, erc20, erc721, ownership, etc, with specific constraints out of the box. The developer may then further attenuate the permission.

🧪 How to Test?

There is reasonable amount of coverage of this new behaviour. A test dapp could be created that creates delegations using these new UnitOfAuthority factories, such as:

// create a caveat builder allowing transfer of an amount of a specified ERC20 token
const caveatBuilder = createErc20CaveatBuilder({
  environment,
  tokenAddress,
  maxAmount
});

// further attenuate with limitedCalls, meaning the entire maxAmount must be spent in a single transaction
caveatBuilder.addCaveat("limitedCalls" , { limit: 1 });
  • Automated tests added/updated
  • All existing tests pass

⚠️ Breaking Changes

List any breaking changes:

  • No breaking changes

  • Breaking changes (describe below):

  • CaveatBuilder now accepts config object for all caveat types

  • CaveatBuilder may no longer be imported from the root export, but now from the /utils export (we should encourage use of the UnitOfAuthority caveat builder factories.

  • @metamask/delegation-core terms builder now accepts calldata parameter, rather than callData (but this is unreleased, so maybe doesn't count).

📋 Checklist

Check off completed items:

  • Code follows the project's coding standards
  • Self-review completed
  • Documentation updated (if needed)
  • Tests added/updated
  • Changelog updated (if needed)
  • All CI checks pass

🔗 Related Issues

Link to related issues:
Closes #
Related to #

📚 Additional Notes

Any additional information, concerns, or context:

@jeffsmale90 jeffsmale90 requested a review from a team as a code owner July 2, 2025 04:55
@jeffsmale90 jeffsmale90 marked this pull request as draft July 2, 2025 04:56
@jeffsmale90 jeffsmale90 force-pushed the feat/secureCaveatBuilders branch from 470ef93 to 17b50f6 Compare July 4, 2025 04:52
@jeffsmale90 jeffsmale90 force-pushed the feat/secureCaveatBuilders branch from 17b50f6 to 456a574 Compare July 4, 2025 04:53
@jeffsmale90 jeffsmale90 changed the title Improve CaveatBuilders to be less risky [Deprecated] Improve CaveatBuilders to be less risky Jul 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant