Skip to content

Commit

Permalink
Update sample repo and lint
Browse files Browse the repository at this point in the history
ilikesymmetry committed Nov 8, 2024

Verified

This commit was signed with the committer’s verified signature.
ilikesymmetry Conner Swenberg
1 parent bba2451 commit e9b2b88
Showing 2 changed files with 174 additions and 71 deletions.
30 changes: 14 additions & 16 deletions docs/pages/guides/spend-permissions/overview.mdx
Original file line number Diff line number Diff line change
@@ -1,17 +1,18 @@
# 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 of signatures, unlocking use cases like subscriptions & trading bots. The reduced signing friction
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 of 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

- 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

```solidity
@@ -28,33 +29,29 @@ struct SpendPermission {
}
```

Spend Permissions are managed by a single manager contract, the `SpendPermissionManager`, which tracks the approval/revocation
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](https://eips.ethereum.org/EIPS/eip-712) typed object that contains
the spend permission properties. This signature and the corresponding spend permission details are then submitted to
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.
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,
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).
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
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.
@@ -65,4 +62,5 @@ a period durantion that spans the entire range between start and end.
A comprehensive example of spend permission accounting can be found [here](https://github.com/coinbase/spend-permissions/blob/main/docs/SpendPermissionAccounting.md).

## Additional resources

Contract sourcecode, diagrams, and additional documentation can be found in the open-source [contracts repository](https://github.com/coinbase/spend-permissions).
Loading

0 comments on commit e9b2b88

Please sign in to comment.