Skip to content
Get help

Spend Limits

Spend Limits enable third-party signers to spend assets (native and ERC-20 tokens) from users' wallets. Once granted, spend limits 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 Limits and ERC-20 permits:

  • Spend Limits supports all ERC-20 assets, whereas permits only support ERC-20s that implement the permit standard
  • Spend Limits enable spending native tokens
  • Spend Limits 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 limit 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 Limits are managed by a single manager contract, the SpendLimitManager, which tracks the approval/revocation statuses of all limits and enforces accurate spending limits and accounting.

Approving

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

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.

Spenders can call SpendPermissionManager.revokeAsSpender to revoke their own permissions without requiring user interaction.

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

Cycle accounting

Spend Limits 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 limit, 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 limits can be used for non-recurring allowances, either indefinite or with expiry, by setting a period duration that spans the entire range between start and end.

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

Additional resources

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