ethereum · 0xAxiom · May 10, 2026
@@ -10,7 +10,7 @@
 ---


 ## Simple Summary

 A data format describing a smart contract software package.

@@ -39,14 +39,14 @@
 practices in mind.

 -   Updates the schema for a *package manifest* to be compatible with
 	the [metadata](https://solidity.readthedocs.io/en/latest/metadata.html) output for compilers.
 -   Updates the `"sources"` object definition to support a wider range of source file types and serve as [JSON input](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description) for a compiler.
 -   Moves compiler definitions to a top-level `"compilers"` array in order to:
 	-   Simplify the links between a compiler version, sources, and the
 		compiled assets.
 	-   Simplify packages that use multiple compiler versions.
 -   Updates key formatting from `snake_case` to `camelCase` to be
 	more consistent with [JSON convention](https://google.github.io/styleguide/jsoncstyleguide.xml?showone=Property_Name_Format#Property_Name_Format).

 ### Guiding Principles

@@ -92,7 +92,7 @@
 “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
 document are to be interpreted as described in RFC 2119.

 -   <https://www.ietf.org/rfc/rfc2119.txt>


 #### Prefixed vs Unprefixed
@@ -118,7 +118,7 @@
 -   Duplicate keys in the same object are invalid.

 -   The document **must** use
    [UTF-8](https://en.wikipedia.org/wiki/UTF-8)
    encoding.

 -   The document **must** not have a trailing newline.
@@ -133,7 +133,7 @@
 be included. Custom fields **should** be prefixed with `x-` to prevent
 name collisions with future versions of the specification.

 * **See Also**: Formalized ([JSON-Schema](https://json-schema.org)) version of this specification: [package.spec.json](../assets/eip-2678/package.spec.json)
 * **Jump To**: [Definitions](#object-definitions)

 ### EthPM Manifest Version
@@ -174,7 +174,7 @@
    registry.

 -   This value **should** conform to the
    [semver](http://semver.org/) version numbering
    specification.

 * **Required**: If `name` is included.
@@ -470,7 +470,7 @@

 The `license` field declares the license associated with this package.
 This value **should** conform to the
 [SPDX](https://spdx.org/licenses/)
 format. Packages **should** include this field. If a file [Source
 Object](#the-source-object) defines its own license, that license takes
 precedence for that particular file over this package-scoped `meta`
@@ -663,7 +663,7 @@

 * **Required**: No
 * **Type**:  Array
 * **Format**: **Must** conform to the [Ethereum Contract ABI JSON](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json) format.

 #### UserDoc: `userdoc`

@@ -947,7 +947,7 @@
         ...
     }
 
-A deployed instance of the `Wallet` contract would be of of type
+A deployed instance of the `Wallet` contract would be of type
 `Wallet`.
 
 #### Identifier  

@@ -11,15 +11,15 @@
 ---

 ## Simple Summary
 This standard defines a ERC-721 token called assembly token which can represent a combination of assets.

 ## Abstract
 The ERC-1155 multi-token contract defines a way to batch transfer tokens, but those tokens must be minted by the ERC-1155 contract itself. This EIP is an ERC-721 extension with ability to assemble assets such as ether, ERC-20 tokens, ERC-721 tokens and ERC-1155 tokens into one ERC-721 token whose token id is also the asset's signature. As assets get assembled into one, batch transfer or swap can be implemented very easily.

 ## Motivation
 As NFT arts and collectors rapidly increases, some collectors are not satisfied with traditional trading methods. When two collectors want to swap some of their collections, currently they can list their NFTs on the market and notify the other party to buy, but this is inefficient and gas-intensive. Instead, some collectors turn to social media or chat group looking for a trustworthy third party to swap NFTs for them. The third party takes NFTs from both collector A and B, and transfer A's collections to B and B's to A. This is very risky.

 The safest way to do batch swap, is to transform batch swap into atomic swap, i.e. one to one swap. But first we should "assemble" those ether, ERC-20 tokens, ERC-721 tokens and ERC-1155 tokens together, and this is the main purpose of this EIP.

 ## Specification
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
@@ -70,7 +70,7 @@
 ```
 
 ## Rationale
-There are many reasons why people want to pack their NFTs together. For example, a collector want to pack a set of football players into a football team; a collector has hundreds of of NFTs with no categories to manage them; a collector wants to buy a full collection of NFTs or none of them. They all need a way a assemble those NFTs together.
+There are many reasons why people want to pack their NFTs together. For example, a collector want to pack a set of football players into a football team; a collector has hundreds of NFTs with no categories to manage them; a collector wants to buy a full collection of NFTs or none of them. They all need a way to assemble those NFTs together.
 
 The reason for choosing ERC-721 standard as a wrapper is ERC-721 token is already widely used and well supported by NFT wallets. And assembly token itself can also be assembled again. Assembly token is easier for smart contract to use than a batch of assets, in scenarios like batch trade, batch swap or collections exchange.
 

@@ -105,7 +105,7 @@ In other words, currently, a royalty split works the same way no matter what typ
 
 With this proposal, multiple **types** of royalty scenarios are allowed. A classic case is the music industry, in which we have writing/composition royalties and recording/master royalties. Different licensing types will pay different percentages to different parties based on context.
 
-In the case of a song cover, a license payment formula can be created so that that 
+In the case of a song cover, a license payment formula can be created so that 
 a) Original IP's writers get paid for using the lyrics or composition of the song
 b) recording artists of the original song do not get paid since their recording is not used
 c) recording artists of the new IP will get paid

@@ -36,7 +36,7 @@ Transaction Flow:
 
  - A customer purchases an item from an online retailer, checking out leads the customer to an option to mint a NFT.
  - The smart contract provides the user with a Digital Receipt Non-Fungible Token.
- - When fulfilling the order, the retailer will upload the digital receipt specified in in the JSON schema below as the metadata to the previously minted NFT.
+ - When fulfilling the order, the retailer will upload the digital receipt specified in the JSON schema below as the metadata to the previously minted NFT.
 
 ### Digital Receipt JSON Schema