Merge branch 'main' of https://github.com/stacksgov/sips

Author: jcnelson

sips/sip-007/sip-007-stacking-consensus.md

@@ -37,7 +37,7 @@ reward in a base cryptocurrency by actively participating in the
 consensus algorithm.
 
 This SIP proposes to change the mining mechanism of the Stacks
-blockchain. [SIP-001](./sip-001-burn-election.md) introduced
+blockchain. [SIP-001](../sip-001/sip-001-burn-election.md) introduced
 proof-of-burn (PoB) where a base cryptocurrency is destroyed to
 participate in mining of a new cryptocurrency. This proposal argues
 that a new mining mechanism called proof-of-transfer (PoX) will be an
@@ -92,7 +92,7 @@ converting electricity and computing power to newly minted tokens, nor
 are they staking their cryptocurrency. Rather they use an existing PoW
 cryptocurrency to secure a new, separate blockchain.
 
-This SIP is currently a draft and proposes to change the mining
+This SIP proposes to change the mining
 mechanism of the Stacks blockchain from proof-of-burn (SIP-001) to
 proof-of-transfer.
 

sips/sip-009/sip-009-nft-standard.md

@@ -20,8 +20,9 @@ Sign-off: Jude Nelson <jude@stacks.org>, Technical Steering Committee Chair
 
 # Abstract
 
-Non-fungible tokens or NFTs are digital assets registered on blockchain with unique identifiers and properties that distinguish them from each other. 
-It should be possible to uniquely identify, own and transfer a non-fungible token.  This SIP aims to provide a flexible and easy-to-implement standard that can be used by developers on the Stacks blockchain when creating their own NFTs. This standard only specifies a basic set of requirements, non-fungible tokens can have more features than what's specified in this standard.
+Non-fungible tokens or NFTs are digital assets registered on blockchain with unique identifiers and properties that distinguish them from each other.
+It should be possible to uniquely identify, own and transfer a non-fungible token. This SIP aims to provide a flexible and easy-to-implement standard that can be used by developers on the Stacks blockchain when creating their own NFTs. This standard only specifies a basic set of requirements, non-fungible tokens can have more features than what's specified in this standard.
+
 # License and Copyright
 
 This SIP is made available under the terms of the Creative Commons CC0 1.0 Universal license, available at https://creativecommons.org/publicdomain/zero/1.0/
@@ -51,23 +52,23 @@ This function must never return an error response. It can be defined as read-onl
 
 ### Token URI
 
-`(get-token-uri (uint) (response (optional (string-ascii 256)) uint))` 
+`(get-token-uri (uint) (response (optional (string-ascii 256)) uint))`
 
 Takes an NFT identifier and returns a response containing a valid URI which resolves to the NFT's metadata. The URI string must be wrapped in an `optional`. If the corresponding NFT doesn't exist or the contract doesn't maintain metadata, the response must be `(ok none)`. If a valid URI exists for the NFT, the response must be `(ok (some "<URI>"))`. The length of the returned URI is limited to 256 characters. The specification of the metadata should be covered in a separate SIP.
 
 This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`.
 
 ### Owner
 
-`(get-owner (uint) (response (optional principal) uint))` 
+`(get-owner (uint) (response (optional principal) uint))`
 
-Takes an NFT identifier and returns a response containing the principal owning the NFT with the given identifier. The principal must be wrapped in an optional. If the corresponding NFT doesn't exist, the response must be `(ok none)`. The owner can be a contract principal. 
+Takes an NFT identifier and returns a response containing the principal owning the NFT with the given identifier. The principal must be wrapped in an optional. If the corresponding NFT doesn't exist, the response must be `(ok none)`. The owner can be a contract principal.
 
 If a call to function `get-owner` returns some principal `A`, then it must return the same value until the `transfer` function is called with principal `A` as the sender.
 
 For any call to `get-owner` with an ID greater than the last token ID returned by the `get-last-token-id` function, the call must return a response `(ok none)`.
 
-This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`. 
+This function must never return an error response. It can be defined as read-only, i.e. `define-read-only`.
 
 ### Transfer
 
@@ -82,6 +83,7 @@ After a successful call to `transfer`, the function `get-owner` must return the
 For any call to `transfer` with an ID greater than the last token ID returned by the `get-last-token-id` function, the call must return an error response.
 
 It is recommended to use error codes from standardized list of codes and implement the function for converting the error codes to messages function that are defined in a separate SIP.
+
 ## Trait
 
 ```
@@ -90,7 +92,7 @@ It is recommended to use error codes from standardized list of codes and impleme
     ;; Last token ID, limited to uint range
     (get-last-token-id () (response uint uint))
 
-    ;; URI for metadata associated with the token 
+    ;; URI for metadata associated with the token
     (get-token-uri (uint) (response (optional (string-ascii 256)) uint))
 
      ;; Owner of a given token identifier
@@ -115,7 +117,9 @@ The native asset functions include:
 - `nft-transfer?`
 
 The following requirements for using native asset functions are defined:
+
 ### Transfer
+
 If the `transfer` function is called from a client without a [post-condition](https://docs.blockstack.org/understand-stacks/transactions#post-conditions) in deny mode or without any NFT condition about a changed owner, then the function call must fail with `abort_by_post_condition`.
 
 # Using NFTs in applications
@@ -135,6 +139,7 @@ For example, when applications call the `transfer` function, they should _always
 NFTs are an established asset class on blockchains. Read for example [here](https://www.ledger.com/academy/what-are-nft).
 
 ## EIP 721
+
 Ethereum has [EIP 721](https://eips.ethereum.org/EIPS/eip-721) that defined non-fungible tokens on the Ethereum blockchain. Notable differences are that the transfer function in EIP 721 uses a different ordering of the arguments ending with the token id. The transfer function in this SIP uses the token ID as the first argument which is in line with the other native functions in Clarity. Furthermore, this SIP only defines a function for getting the URI pointing to the metadata of an NFT. The specifications for schema and other properties of the token metadata should be defined in a separate SIP.
 
 # Backwards Compatibility
@@ -150,5 +155,12 @@ A trait that follows this specification is available on mainnet as [`SP2PABAF9FT
 # Reference Implementations
 
 ## Source code
+
 ### Friedger's clarity-smart-contracts
+
 https://github.com/friedger/clarity-smart-contracts/blob/master/contracts/sips/nft-trait.clar
+
+## Deployed Contracts
+
+- mainnet: [SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait](https://explorer.stacks.co/txid/SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait?chain=mainnet)
+- testnet: [ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.nft-trait.nft-trait](https://explorer.stacks.co/txid/ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.nft-trait?chain=testnet)

sips/sip-010/sip-010-fungible-token-standard.md

@@ -236,3 +236,8 @@ Other examples of Clarity contracts that implement fungible tokens, although not
 
 - [@psq's trait and implementation](https://github.com/psq/flexr/blob/master/contracts/src20-trait.clar)
 - [@friedger's fungible token implementation](https://github.com/friedger/clarity-smart-contracts/blob/master/contracts/tokens/fungible-token.clar)
+
+## Deployed Contracts
+
+- mainnet: [SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait](https://explorer.stacks.co/txid/SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard?chain=mainnet)
+- testnet: [ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.sip-010-trait-ft-standard.sip-010-trait](https://explorer.stacks.co/txid/ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.sip-010-trait-ft-standard?chain=testnet)

sips/sip-015/sip-015-network-upgrade.md

@@ -973,7 +973,7 @@ to interact with exchanges that follow this convention.
 
 ```clarity
 (as-contract
-  (stx-transfer? u50 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY tx-sender 0x00)) ;; Returns (err u4)
+  (stx-transfer-memo? u50 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY tx-sender 0x00)) ;; Returns (err u4)
 (stx-transfer-memo? u60 tx-sender 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY 0x010203) ;; Returns (ok true)
 ```