nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

add token reserve kind

Browse Source
This commit is contained in:
pablof7z 2024-11-03 12:53:32 -03:00
parent c275ae74eb
commit 9de097815a
2 changed files with 15 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
60.md
View File

@ -12,10 +12,12 @@ The purpose of this NIP is:
This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet. This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
# High-level flow # Event Kinds
1. A user has a `kind:37375` event that represents a wallet. - `kind:37375` contains relevant info for a wallet. Clients **SHOULD** check the current info event when loading the wallet.
2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key. - `kind:7373` wallet's reserved proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional. - `kind:7374` tracks pending quotes from a mint. This event **MAY** be used to keep track of the quote ID and its expiration.
- `kind:7375` represents the wallet's unspent proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
- `kind:7376` provides the wallet's transaction history. The history is provided only for informational purposes and is not part of the wallet state.
## Wallet Event ## Wallet Event
```jsonc ```jsonc
@ -57,7 +59,7 @@ Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content`
Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag. Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
## Token Event ## Token Event
Token events are used to record the unspent proofs that come from the mint. Token events are used to store proofs of a wallet.
There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event. There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
@ -87,6 +89,9 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
### Spending proofs ### Spending proofs
When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event. When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
### Reserving proofs
A wallet can reserve proofs by deleting them from a `kind:7375` event and creating a `kind:7373` event. `kind:7373` and `kind:7375` events have the same structure.
## Spending History Event ## Spending History Event
Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes. Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
@ -203,3 +208,6 @@ Application developers are encouraged to use local state when possible and only
## Appendix 1: Validating proofs ## Appendix 1: Validating proofs
Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof. Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof.
## Appendix 2: Validating relays
Clients might want to optionally check that the relays the user chooses to store the proofs respond well to [[NIP-09]] event deletion requests and, periodically, check that the different relays are consistent with the state they report. These checks are left up to particular implementations to decide when and why to do them.

3
README.md
View File

@ -142,7 +142,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `5000`-`5999` | Job Request | [90](90.md) | | `5000`-`5999` | Job Request | [90](90.md) |
| `6000`-`6999` | Job Result | [90](90.md) | | `6000`-`6999` | Job Result | [90](90.md) |
| `7000` | Job Feedback | [90](90.md) | | `7000` | Job Feedback | [90](90.md) |
| `7374` | Reserved Cashu Wallet Tokens | [60](60.md) | | `7373` | Reserved Cashu Wallet Tokens | [60](60.md) |
| `7374` | Pending minting quotes | [60](60.md) |
| `7375` | Cashu Wallet Tokens | [60](60.md) | | `7375` | Cashu Wallet Tokens | [60](60.md) |
| `7376` | Cashu Wallet History | [60](60.md) | | `7376` | Cashu Wallet History | [60](60.md) |
| `9000`-`9030` | Group Control Events | [29](29.md) | | `9000`-`9030` | Group Control Events | [29](29.md) |