Skip to content
Demo

Spend Permissions

Spend Permissions enable third-party signers to spend assets (native and ERC-20 tokens) from users' wallets. Once granted, spend permissions allow you to move your users' assets without any further signatures, unlocking use cases like subscriptions & trading bots. The reduced signing friction can also be leveraged to enhance UX for high-frequency use cases such as onchain games.

Differences between Spend Permissions and ERC-20 permits:

  • Spend Permissions supports all ERC-20 assets, whereas permits only support ERC-20s that implement the permit standard
  • Spend Permissions enable spending native tokens
  • Spend Permissions offers granular controls for recurrence
  • The logic that controls asset movements is implemented in the user's wallet, not the asset contract

The SpendPermission details

A spend permission is defined by the following parameters

struct SpendPermission {
    address account;
    address spender;
    address token;
    uint160 allowance;
    uint48 period;
    uint48 start;
    uint48 end;
    uint256 salt;
    bytes extraData;
}

Spend Permissions are managed by a single manager contract, the SpendPermissionManager, which tracks the approval/revocation statuses of all perissions and enforces accurate spending limits and accounting.

Approving

A user approves a spend permission by signing an ERC-712 typed object that contains the spend permission properties. This signature and the corresponding spend permission details are then submitted to SpendPermissionManager.approveWithSignature to approve the spend permission onchain.

Multiple spend permissions can be batched and approved with a single signature by constructing a batch spend permission object and approving with SpendPermissionManager.approveBatchWithSignature.

Revoking

Users can revoke permissions at any time by calling SpendPermissionManager.revoke. Revocations are onchain calls that can be batched similar to other ERC-4337 transactions.

Once a spend permission has been revoked, it can never be re-approved. Therefore, if a user wants to re-authorize a revoked spend permission, the spender will need to generate a new spend permission that has a unique hash from the original spend permission. If the parameters of the new spend permission are identical to the revoked permission, the salt field of the permission can be used to generate a unique hash.

Cycle accounting

Spend Permissions offers granular controls for recurrence (e.g. 10 USDC / month). As the third-party signer spends user assets, the SpendPermissionManager contract tracks cumulative spend and enforces the per-period allowance. If there are multiple periods defined during the valid lifespan of the spend permission, the cumulative usage resets to 0 at the beginning of the next period, allowing the spender to once again spend up to the allowance.

This behavior is parameterized by the start, end, period and allowance properties of the permission.

Note that spend permissions can be used for non-recurring allowances, either indefinite or with expiry, by setting a period durantion that spans the entire range between start and end.

A comprehensive example of spend permission accounting can be found here.

Additional resources

Contract sourcecode, diagrams, and additional documentation can be found in the open-source contracts repository.