|
1 |
| -# Burning the Aptos Coin Mint Capability |
2 |
| -We begin with a brief section on the [procedure and intended outcomes](#procedure-and-intended-outcomes) of burning the Aptos Coin mint capability. |
| 1 | +# Destroying the Aptos Coin Mint Capability |
| 2 | +We begin with a brief section on the [procedure and intended outcomes](#procedure-and-intended-outcomes) of destroying the Aptos Coin mint capability. |
3 | 3 |
|
4 | 4 | We then evaluate the means of [reversing this procedure](#reversing-the-procedure) and the potential [side effects](#side-effects) of doing so.
|
5 | 5 |
|
6 | 6 | We then list all identified [call sites](#call-sites) using the Aptos Coin mint capability.
|
7 | 7 |
|
8 | 8 | Finally, we the evaluate the following potential usages of the Aptos Coin mint capability as would affect critical system properties. These are:
|
9 | 9 |
|
10 |
| -1. **[Transaction `prologue` and `epilogue`](#transaction-epilogue-and-prologue):** we assert whether the removal of the mint capability would cause failures of the transaction `prologue` and `epilogue` and thus general transaction processing. |
11 |
| -2. **[Token transfers](#token-transfers):** we assert whether the removal of the mint capability would cause failures of token transfers. |
12 |
| -3. **[FA migration](#fa-migration):** we assert whether the removal of the mint capability would cause failures of FA migration. |
| 10 | +1. **[Transaction `prologue` and `epilogue`](#transaction-epilogue-and-prologue):** we assert that destroying the mint capability would cause failures of the transaction `prologue` and `epilogue` and thus general transaction processing under the Governed Gas Pool feature flags. |
| 11 | +2. **[Token transfers](#token-transfers):** we assert destroying the mint capability would not cause failures of token transfers. |
| 12 | +3. **[FA migration](#fa-migration):** we assert that destroying the mint capability would not cause failures of FA migration. |
13 | 13 |
|
14 | 14 | ## Procedure and intended outcomes
|
15 | 15 | > [!WARNING]
|
16 | 16 | > In general, a user who has access to the `core_resource_account` signer has the ability to make and publish changes to the framework which can remove restrictions on minting, recreate capabilities, etc. However, we maintain that under the Biarritz Model, these are a tolerable risk--particularly as structures and their storage are preserved by the Aptos Move VM inherently and thus can be restored.
|
17 | 17 | >
|
18 |
| -> Our evaluation thus concerns effectively burning the mint capability in such a manner that a user who holds the `core_resource_account` signer would need to introduce a new framework to restore it--as opposed to simply running a series of transactions against existing code. This renders exploits costly, but not impossible. |
| 18 | +> Our evaluation thus concerns effectively destroying the mint capability in such a manner that a user who holds the `core_resource_account` signer would need to introduce a new framework to restore it--as opposed to simply running a series of transactions against existing code. This renders exploits costly, but not impossible. |
19 | 19 |
|
20 | 20 | ### Framework changes
|
21 | 21 | Because Aptos Move scripts cannot borrow structs but instead need to call `public` functions, we must update the framework to expose an `aptos_coin::destory_mint_capability_v2` which wraps the existing `public(friend) aptos_coin::destory_mint_capability`. The body of this function would be as follows:
|
|
0 commit comments