|
1 | 1 | # SNIP-20 Reference Implementation |
2 | 2 |
|
3 | | -This is an implementation of a [SNIP-20](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-20.md), [SNIP-21](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-21.md), [SNIP-22](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-22.md), [SNIP-23](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-23.md), [SNIP-24](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-24.md), [SNIP-25](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-25.md) and [SNIP-26](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-26.md) compliant token contract. |
| 3 | +This is an implementation of a [SNIP-20](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-20.md), [SNIP-21](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-21.md), [SNIP-22](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-22.md), [SNIP-23](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-23.md), [SNIP-24](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-24.md), [~~SNIP-25~~](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-25.md), [SNIP-26](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-26.md), [~~SNIP-50~~](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-50.md) and [SNIP-52](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-52.md) compliant token contract. |
4 | 4 |
|
5 | 5 | > **Note:** |
6 | 6 | > The master branch contains new features not covered by officially-released SNIPs and may be subject to change. When releasing a token on mainnet, we recommend you start with a [tagged release](https://github.com/scrtlabs/snip20-reference-impl/tags) to ensure compatibility with SNIP standards. |
@@ -66,112 +66,27 @@ All transactions are encrypted, so if you want to see the error returned by a fa |
66 | 66 |
|
67 | 67 | `secretcli q compute tx <TX_HASH>` |
68 | 68 |
|
69 | | -# SNIP 25 Security Update |
70 | | - |
71 | | -## Security Changes |
72 | | -1. Implemented the ability to have decoy addresses for every operation that access account's balance |
73 | | -2. Converted every add operation related to account's balance and total supply |
74 | | -3. Started using u128 instead of Uint128 |
75 | | - |
76 | | -## Decoys |
77 | | -### Transaction That Support Decoys |
78 | | -1. Redeem |
79 | | -2. Deposit |
80 | | -3. Transfer |
81 | | -4. TransferFrom |
82 | | -5. Send |
83 | | -6. SendFrom |
84 | | -7. Burn |
85 | | -8. BurnFrom |
86 | | -9. Mint |
87 | | -10. BatchTransfer - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
88 | | -11. BatchSend - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
89 | | -12. BatchTransferFrom - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
90 | | -13. BatchSendFrom - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
91 | | -14. BatchMint - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
92 | | -15. BatchBurnFrom - For every action (The strength of the decoys will be the minimal strength of all of the actions) |
93 | | - |
94 | | -### Example |
95 | | -```secretcli tx compute execute <contract-address> '{"transfer":{"recipient":"<address>","amount":"<amount>", "entropy":"<base64_encoded_entropy>", "decoys":<[addresses_list]>}}' --from <account>``` |
96 | | - |
97 | | -## Future Work |
98 | | -| Topic | Immediate-term solution | Medium-term solution | Long-term solution | |
99 | | -| --- | --- | --- | --- | |
100 | | -| Receiver privacy | Decoys - offer limited privacy, since it depends a lot on how you choose decoys. There’s probably no way to select decoys effectively enough, and thus it only makes it a bit harder but effectively doesn’t provide receiver privacy to a sophisticated long-term attacker | Some sort of bucketing? - still no clear path forward| ORAM? - still no clear path forward | |
101 | | -| Transfer amount privacy - subtractions (Transfer/Send/Burn) | None | None | Merkle proofs for storage reads - will make it very difficult to simulate transactions and play with storage. | |
102 | | - |
103 | | -# SNIP 25 Other Updates |
104 | | - |
105 | | -## All Allowances |
106 | | -Adds the ability for an owner to query for all allowances they have given out, as well as for a spender to query for all allowances they have received. |
107 | | - |
108 | | -## Queries |
109 | | - |
110 | | -### AllowancesGiven |
111 | | - |
112 | | -This query MUST be authenticated. |
113 | | - |
114 | | -Returns the list of allowances given out by the current account as an owner, as well as the total count of allowances given out. |
115 | | - |
116 | | -Results SHOULD be paginated. Results MUST be sorted in reverse chronological order by the datetime at which the allowance was first created (i.e., order is not determined by expiration, nor by last modified). |
117 | | - |
118 | | -#### Request |
119 | | - |
120 | | -| Name | Type | Description | optional | |
121 | | -| ---- | ---- | ----------- | -------- | |
122 | | -| [with_permit].query.allowances_given.owner | string | Account from which tokens are allowed to be taken | no | |
123 | | -| [with_permit].query.allowances_given.page_size | number | Number of allowances to return, starting from the latest. i.e. n=1 will return only the latest allowance | no | |
124 | | -| [with_permit].query.allowances_given.page | number | Defaults to 0. Specifying a positive number will skip page * page_size txs from the start. | yes | |
125 | | - |
126 | | -#### Response |
127 | | -```json |
128 | | -{ |
129 | | - "allowances_given": { |
130 | | - "owner": "<address>", |
131 | | - "allowances": [ |
132 | | - { |
133 | | - "spender": "<address>", |
134 | | - "allowance": "Uint128", |
135 | | - "expiration": 1234, |
136 | | - }, |
137 | | - { "...": "..." } |
138 | | - ], |
139 | | - "count": 200 |
140 | | - } |
141 | | -} |
142 | | -``` |
143 | | - |
144 | | -### AllowancesReceived |
145 | | - |
146 | | -This query MUST be authenticated. |
147 | | - |
148 | | -Returns the list of allowances given to the current account as a spender, as well as the total count of allowances received. |
149 | | - |
150 | | -Results SHOULD be paginated. Results MUST be sorted in reverse chronological order by the datetime at which the allowance was first created (i.e., order is not determined by expiration). |
151 | | - |
152 | | -#### Request |
153 | | - |
154 | | -| Name | Type | Description | optional | |
155 | | -| ---- | ---- | ----------- | -------- | |
156 | | -| [with_permit.]query.allowances_received.spender | string | Account which is allowed to spend tokens on behalf of the owner | no | |
157 | | -| [with_permit.]query.allowances_received.page_size | number | Number of allowances to return, starting from the latest. i.e. n=1 will return only the latest allowance | no | |
158 | | -| [with_permit.]query.allowances_received.page | number | Defaults to 0. Specifying a positive number will skip page * page_size txs from the start. | yes | |
159 | | - |
160 | | -#### Response |
161 | | - |
162 | | -```json |
163 | | -{ |
164 | | - "allowances_received": { |
165 | | - "spender": "<address>", |
166 | | - "allowances": [ |
167 | | - { |
168 | | - "owner": "<address>", |
169 | | - "allowance": "Uint128", |
170 | | - "expiration": 1234, |
171 | | - }, |
172 | | - { "...": "..." } |
173 | | - ], |
174 | | - "count": 200 |
175 | | - } |
176 | | -} |
177 | | -``` |
| 69 | +## Privacy Enhancements |
| 70 | + |
| 71 | + - All transfers/sends (including batch and *_from) use the delayed write buffer (dwb) to address "spicy printf" storage access pattern attacks. |
| 72 | + - Additionally, a bitwise trie of bucketed entries (dwb) creates dynamic anonymity sets for senders/owners, whose balance must be checked when transferring/sending. It also enhances privacy for recipients. |
| 73 | + - When querying for Transaction History, each event's `id` field returned in responses are deterministically obfuscated by `ChaChaRng(XorBytes(ChaChaRng(actual_event_id), internal_secret)) >> (64 - 53)` for better privacy. Without this, an attacker could deduce the number of events that took place between two transactions. |
| 74 | + |
| 75 | +## SNIP-52: Private Push Notifications |
| 76 | + |
| 77 | +This contract publishes encrypted messages to the event log which carry data intended to notify recipients of actions that affect them, such as token transfer and allowances. |
| 78 | + |
| 79 | +Direct channels: |
| 80 | + - `recvd` -- emitted to a recipient when their account receives funds via one of `transfer`, `send`, `transfer_from`, or `send_from`. The notification data includes the amount, the sender, and the memo length. |
| 81 | + - `spent` -- emitted to an owner when their funds are spent, via one of `transfer`, `send`, `transfer_from` or `send_from`. The notification data includes the amount, the recipient, the owner's new balance, and a few other pieces of information such as memo length, number of actions, and whether the spender was the transaction's sender. |
| 82 | + - `allowance` -- emitted to a spender when some allower account has granted them or modified an existing allowance to spend their tokens, via `increase_allowance` or `decrease_allowance`. The notification data includes the amount, the allower, and the expiration of the allowance. |
| 83 | + |
| 84 | +Group channels: |
| 85 | + - `multirecvd` -- emitted to a group of recipients (up to 16) when a `batch_transfer`, `batch_send`, `batch_transfer_from`, or `batch_send_from` has been executed. Each recipient will receive a packet of data containing the amount they received, the last 8 bytes of the owner's address, and some additional metadata. |
| 86 | + - `multispent` -- emitted to a group of spenders (up to 16) when a `batch_transfer_from`, or `batch_send_from` has been executed. Each spender will receive a packet of data containing the amount that was spent, the last 8 bytes of the recipient's address, and some additional metadata. |
| 87 | + |
| 88 | + |
| 89 | +## Security Features |
| 90 | + |
| 91 | + - Transfers to the contract itself will be rejected to prevent accidental loss of funds. |
| 92 | + - The migration allows for a one-time processing of refunding any previous transfers made to the contract itself. |
0 commit comments