feat: Multi Token Standard Contract [NEP]

README.md

@@ -22,6 +22,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 |[0178](https://github.com/near/NEPs/blob/master/neps/nep-0178.md)   | Non Fungible Token Approval Management | @chadoh @thor314 | Final |
 |[0181](https://github.com/near/NEPs/blob/master/neps/nep-0181.md)   | Non Fungible Token Enumeration | @chadoh @thor314 | Final |
 |[0199](https://github.com/near/NEPs/blob/master/neps/nep-0199.md)   | Non Fungible Token Royalties and Payouts | @thor314 @mattlockyer | Final |
+|[0245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md)   | Multi Token Standard | @zcstarr @riqi @jriemann @marcos.sun | Draft |
 |[0297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md)   | Contract Events Standard | @telezhnaya | Final |
 |[0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md)   | Contract Metadata | @BenKurrek | Review |
 

specs/Standards/MultiToken/Enumeration.md

@@ -0,0 +1,81 @@
+# Multi Token Enumeration([NEP-245](https://github.com/near/NEPs/discussions/246))
+
+
+Version `1.0.0`
+
+## Summary
+
+Standard interfaces for counting & fetching tokens, for an entire Multi Token contract or for a given owner.
+
+## Motivation
+
+Apps such as marketplaces and wallets need a way to show all tokens owned by a given account and to show statistics about all tokens for a given contract. This extension provides a standard way to do so.
+
+While some Multi Token contracts may forego this extension to save [storage] costs, this requires apps to have custom off-chain indexing layers. This makes it harder for apps to integrate with such Multi Token contracts. Apps which integrate only with Multi Token Standards that use the Enumeration extension do not even need a server-side component at all, since they can retrieve all information they need directly from the blockchain.
+
+Prior art:
+
+- [ERC-721]'s enumeration extension
+- [Non Fungible Token Standard's](../NonFungibleToken/Enumeration.md) enumeration extension
+
+## Interface
+
+The contract must implement the following view methods:
+
+// Metadata field is optional if metadata extension is implemented. Includes the base token metadata id and the token_metadata object, that represents the token specific metadata.
+
+```ts
+// Get a list of all tokens
+//
+// Arguments:
+// * `from_index`: a string representing an unsigned 128-bit integer,
+//    representing the starting index of tokens to return
+// * `limit`: the maximum number of tokens to return
+//
+// Returns an array of `Token` objects, as described in the Core standard,
+// and an empty array if there are no tokens
+function mt_tokens(
+  from_index: string|null, // default: "0"
+  limit: number|null, // default: unlimited (could fail due to gas limit)
+): Token[] {}
+
+// Get list of all tokens owned by a given account
+//
+// Arguments:
+// * `account_id`: a valid NEAR account
+// * `from_index`: a string representing an unsigned 128-bit integer,
+//    representing the starting index of tokens to return
+// * `limit`: the maximum number of tokens to return
+//
+// Returns a paginated list of all tokens owned by this account, and an empty array if there are no tokens
+function mt_tokens_for_owner(
+  account_id: string,
+  from_index: string|null, // default: 0
+  limit: number|null, // default: unlimited (could fail due to gas limit)
+): Token[] {}
+```
+
+The contract must implement the following view methods if using metadata extension:
+
+```ts
+// Get list of all base metadata for the contract
+//
+// Arguments:
+// * `from_index`: a string representing an unsigned 128-bit integer,
+//    representing the starting index of tokens to return
+// * `limit`: the maximum number of tokens to return
+//
+// Returns an array of `MTBaseTokenMetadata` objects, as described in the Metadata standard, and an empty array if there are no tokens
+function mt_tokens_base_metadata_all(
+  from_index: string | null,
+  limit: number | null
+  ): MTBaseTokenMetadata[]
+```
+
+
+## Notes
+
+At the time of this writing, the specialized collections in the `near-sdk` Rust crate are iterable, but not all of them have implemented an `iter_from` solution. There may be efficiency gains for large collections and contract developers are encouraged to test their data structures with a large amount of entries. 
+
+  [ERC-721]: https://eips.ethereum.org/EIPS/eip-721
+  [storage]: https://docs.near.org/docs/concepts/storage-staking

specs/Standards/MultiToken/Events.md

@@ -0,0 +1,184 @@
+# Multi Token Event([NEP-245](https://github.com/near/NEPs/discussions/246))
+
+
+Version `1.0.0`
+
+## Summary
+
+Standard interfaces for Multi Token Contract actions.
+Extension of [NEP-297](../EventsFormat.md)
+
+## Motivation
+
+NEAR and third-party applications need to track
+ `mint`, `burn`, `transfer` events for all MT-driven apps consistently. This exension addresses that.
+
+Note that applications, including NEAR Wallet, could require implementing additional methods to display tokens correctly such as [`mt_metadata`](Metadata.md) and [`mt_tokens_for_owner`](Enumeration.md).
+
+## Interface
+Multi Token Events MUST have `standard` set to `"nep245"`, standard version set to `"1.0.0"`, `event` value is one of `mt_mint`, `mt_burn`, `mt_transfer`, and `data` must be of one of the following relavant types: `MtMintLog[] | MtBurnLog[] | MtTransferLog[]`:
+
+
+
+```ts
+interface MtEventLogData {
+  EVENT_JSON: {
+    standard: "nep245",
+    version: "1.0.0",
+    event: MtEvent,
+    data: MtMintLog[] | MtBurnLog[] | MtTransferLog[]
+  }
+}
+```
+
+```ts
+// Minting event log. Emitted when a token is minted/created. 
+// Requirements
+// * Contract MUST emit event when minting a token
+// Fields 
+// * Contract token_ids and amounts MUST be the same length 
+// * `owner_id`: the account receiving the minted token
+// * `token_ids`: the tokens minted
+// * `amounts`: the number of tokens minted, wrapped in quotes and treated
+//    like a string, although the numbers will be stored as an unsigned integer
+//    array with 128 bits.
+// * `memo`: optional message
+interface MtMintLog {
+    owner_id: string,
+    token_ids: string[],
+    amounts: string[],
+    memo?: string
+}
+
+// Burning event log. Emitted when a token is burned.  
+// Requirements
+// * Contract MUST emit event when minting a token
+// Fields 
+// * Contract token_ids and amounts MUST be the same length 
+// * `owner_id`: the account whose token(s) are being burned
+// * `authorized_id`: approved account_id to burn, if applicable
+// * `token_ids`: the tokens being burned
+// * `amounts`: the number of tokens burned, wrapped in quotes and treated
+//    like a string, although the numbers will be stored as an unsigned integer
+//    array with 128 bits.
+// * `memo`: optional message
+interface MtBurnLog {
+    owner_id: string,
+    authorized_id?: string,
+    token_ids: string[],
+    amounts: string[],
+    memo?: string
+}
+
+// Transfer event log. Emitted when a token is transfered.  
+// Requirements
+// * Contract MUST emit event when transferring a token
+// Fields 
+// * `authorized_id`: approved account_id to transfer
+// * `old_owner_id`: the account sending the tokens "sender.near"
+// * `new_owner_id`: the account receiving the tokens "receiver.near"
+// * `token_ids`: the tokens to transfer 
+// * `amounts`: the number of tokens to transfer, wrapped in quotes and treated
+//    like a string, although the numbers will be stored as an unsigned integer
+//    array with 128 bits.
+interface MtTransferLog {
+    authorized_id?: string,
+    old_owner_id: string,
+    new_owner_id: string,
+    token_ids: string[],
+    amounts: string[],
+    memo?: string
+}
+```
+
+## Examples
+
+Single owner minting (pretty-formatted for readability purposes):
+
+```js
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_mint",
+  "data": [
+    {"owner_id": "foundation.near", "token_ids": ["aurora", "proximitylabs_ft"], "amounts":["1", "100"]}
+  ]
+}
+```
+
+Different owners minting:
+
+```js
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_mint",
+  "data": [
+    {"owner_id": "foundation.near", "token_ids": ["aurora", "proximitylabs_ft"], "amounts":["1","100"]},
+    {"owner_id": "user1.near", "token_ids": ["meme"], "amounts": ["1"]}
+  ]
+}
+```
+
+Different events (separate log entries):
+
+```js
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_burn",
+  "data": [
+    {"owner_id": "foundation.near", "token_ids": ["aurora", "proximitylabs_ft"], "amounts": ["1","100"]},
+  ]
+}
+```
+
+Authorized id:
+
+```js
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_burn",
+  "data": [
+    {"owner_id": "foundation.near", "token_ids": ["aurora_alpha", "proximitylabs_ft"], "amounts": ["1","100"], "authorized_id": "thirdparty.near" },
+  ]
+}
+```
+
+```js
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_transfer",
+  "data": [
+    {"old_owner_id": "user1.near", "new_owner_id": "user2.near", "token_ids": ["meme"], "amounts":["1"], "memo": "have fun!"}
+  ]
+}
+
+EVENT_JSON:{
+  "standard": "nep245",
+  "version": "1.0.0",
+  "event": "mt_transfer",
+  "data": [
+    {"old_owner_id": "user2.near", "new_owner_id": "user3.near", "token_ids": ["meme"], "amounts":["1"], "authorized_id": "thirdparty.near", "memo": "have fun!"}
+  ]
+}
+```
+
+## Further methods
+
+Note that the example events covered above cover two different kinds of events:
+1. Events that are not specified in the MT Standard (`mt_mint`, `mt_burn`)
+2. An event that is covered in the [Multi Token Core Standard](https://nomicon.io/Standards/MultiToken/Core.html#mt-interface). (`mt_transfer`)
+
+This event standard also applies beyond the three events highlighted here, where future events follow the same convention of as the second type. For instance, if an MT contract uses the [approval management standard](https://nomicon.io/Standards/MultiToken/ApprovalManagement.html), it may emit an event for `mt_approve` if that's deemed as important by the developer community.
+
+Please feel free to open pull requests for extending the events standard detailed here as needs arise.
+
+## Drawbacks
+
+There is a known limitation of 16kb strings when capturing logs.
+This can be observed from `token_ids` that may vary in length
+for different apps so the amount of logs that can
+be executed may vary.