Merge branch 'master' into master

ERCS/erc-1363.md

@@ -99,6 +99,7 @@ interface ERC1363 /* is ERC20, ERC165 */ {
    * and then call `onApprovalReceived` on spender.
    * @param spender address The address which will spend the funds
    * @param value uint256 The amount of tokens to be spent
+   * @return true unless throwing
    */
   function approveAndCall(address spender, uint256 value) external returns (bool);
 
@@ -108,6 +109,7 @@ interface ERC1363 /* is ERC20, ERC165 */ {
    * @param spender address The address which will spend the funds
    * @param value uint256 The amount of tokens to be spent
    * @param data bytes Additional data with no specified format, sent in call to `spender`
+   * @return true unless throwing
    */
   function approveAndCall(address spender, uint256 value, bytes memory data) external returns (bool);
 }

ERCS/erc-7092.md

@@ -4,8 +4,7 @@ title: Financial Bonds
 description: Represents debt issued by entities to investors.
 author: Samuel Gwlanold Edoumou (@Edoumou)
 discussions-to: https://ethereum-magicians.org/t/financial-bonds/14461
-status: Last Call
-last-call-deadline: 2024-02-07
+status: Final
 type: Standards Track
 category: ERC
 created: 2023-05-28

ERCS/erc-7527.md

@@ -252,7 +252,7 @@ interface IERC7527Factory {
 
 ### Prior Interfaces
 
-[ERC-5679](./eip-5679.md) proposed `IERC5679Ext721` interface for introducing a consistent way to extend [ERC-721](./eip-721.md) token standards for minting and burning. To ensure the backward compatibility, considering some contracts which do not implement `ERC721TokenReceiver`, `IERC7527App` employ `mint` function instead of `safeMint`. To ensure the safety and the uniqueness of mutual bound, the `_from` parameter of the `burn` function in `IERC5679Ext721` must be the contract address of the bounded angency. Thus, `burn` function in `IERC7527App` does not contain the `_from` parameter. 
+[ERC-5679](./eip-5679.md) proposed `IERC5679Ext721` interface for introducing a consistent way to extend [ERC-721](./eip-721.md) token standards for minting and burning. To ensure the backward compatibility, considering some contracts which do not implement `ERC721TokenReceiver`, `IERC7527App` employ `mint` function instead of `safeMint`. To ensure the safety and the uniqueness of mutual bound, the `_from` parameter of the `burn` function in `IERC5679Ext721` must be the contract address of the bounded agency. Thus, `burn` function in `IERC7527App` does not contain the `_from` parameter. 
 
 ### Mutual Bound
 

ERCS/erc-7590.md

@@ -179,6 +179,10 @@ Caution is advised when dealing with non-audited contracts.
 
 Implementations MUST use the message sender as from parameter when they are transferring tokens into an NFT. Otherwise, since the current contract needs approval, it could potentially pull the external tokens into a different NFT.
 
+When transferring [ERC-20](./eip-20.md) tokens in or out of an NFT, it could be the case that the amount transferred is not the same as the amount requested. This could happen if the [ERC-20](./eip-20.md) contract has a fee on transfer. This could cause a bug on your Token Holder contract if you do not manage it properly. There are 2 ways to do it, both of which are valid:
+1. Use the `IERC20` interface to check the balance of the contract before and after the transfer, and revert if the balance is not the expected one, hence not supporting tokens with fees on transfer.
+2. Use the `IERC20` interface to check the balance of the contract before and after the transfer, and use the difference to calculate the amount of tokens that were actually transferred. 
+
 To prevent a seller from front running the sale of an NFT holding [ERC-20](./eip-20.md) tokens to transfer out such tokens before a sale is executed, marketplaces MUST beware of the `erc20TransferOutNonce` and revert if it has changed since listed.
 
 [ERC-20](./eip-20.md) tokens that are transferred directly to the NFT contract will be lost.

ERCS/erc-7627.md

@@ -22,11 +22,11 @@ With the emergence of Layer 2 chains boasting sub-second block times and the pro
 
 ### Objectives
 
-1. Provide a standardized interface for implementing messaging systems in smart contracts, including user registration and message sending functionalities.
-2. Enhance flexibility and scalability for messaging systems by defining enumerations for public key algorithms and a structure for user information.
-3. Define events for tracking message sending to enhance the observability and auditability of the contract.
-4. Using a custom sessionId allows messages to be organized into a conversation.
-5. Encrypt message content using the recipient's public key during message transmission.
+- Provide a standardized interface for implementing messaging systems in smart contracts, including user registration and message sending functionalities.
+- Enhance flexibility and scalability for messaging systems by defining enumerations for public key algorithms and a structure for user information.
+- Define events for tracking message sending to enhance the observability and auditability of the contract.
+- Using a custom sessionId allows messages to be organized into a conversation.
+- Encrypt message content using the recipient's public key during message transmission.
 
 ### Interface
 
@@ -39,6 +39,8 @@ pragma solidity ^0.8.0;
 
 interface IERC7627 {
 
+    enum PublicKeyAlgorithm { RSA, ECDSA, ED25519, DSA, DH, ECDH, X25519 }
+    
     // Events
 
     /**
@@ -48,7 +50,7 @@ interface IERC7627 {
      * @param sessionId The session ID of the message.
      * @param encryptedMessage The encrypted message.
      */
-    event MessageSent(address indexed from, address indexed to, string sessionId, bytes encryptedMessage);
+    event MessageSent(address indexed from, address indexed to, bytes32 sessionId, bytes encryptedMessage);
 
     /**
      * @dev Event emitted when a user updates their public key.
@@ -65,15 +67,15 @@ interface IERC7627 {
      * @param _publicKey The public key of the user.
      * @param _algorithm The algorithm used for the public key.
      */
-    function updatePublicKey(bytes memory _publicKey, PublicKeyAlgorithm _algorithm) external;
+    function updatePublicKey(bytes calldata _publicKey, PublicKeyAlgorithm _algorithm) external;
 
     /**
      * @dev Function to send an encrypted message from one user to another.
      * @param _to The address of the recipient.
      * @param _sessionId The session ID of the message.
      * @param _encryptedMessage The encrypted message.
      */
-    function sendMessage(address _to, string memory _sessionId, bytes memory _encryptedMessage) external;
+    function sendMessage(address _to, bytes32 _sessionId, bytes calldata _encryptedMessage) external;
 
     /**
      * @dev Function to retrieve a user's public key and algorithm.
@@ -87,7 +89,7 @@ interface IERC7627 {
 
 ## Rationale
 
-Traditional messaging lacks security and transparency for blockchain communication. The choice of asymmetric encryption ensures the confidentiality and integrity of messages, which is why we opted for this encryption method. Providing a unified interface enables easy integration of encrypted communication into smart contracts, thereby fostering innovation. Encrypted messaging guarantees adherence to best practices in data security. The interface supports various encryption methods, enhancing adaptability. Event tracking enhances the observability and auditability of the contract, aiding compliance efforts. Standardization promotes interoperability, facilitating seamless communication across platforms.
+Traditional messaging lacks security and transparency for blockchain communication. The choice of asymmetric encryption ensures the confidentiality and integrity of messages, which is why we opted for this encryption method. Providing a unified interface enables easy integration of encrypted communication into smart contracts, thereby fostering innovation. Encrypted messaging guarantees adherence to best practices in data security. Due to security reasons, public keys need to be regularly updated, hence we have added a feature that allows users to autonomously update their public keys. The interface supports various encryption methods, enhancing adaptability. Event tracking enhances the observability and auditability of the contract, aiding compliance efforts. Standardization promotes interoperability, facilitating seamless communication across platforms.
 
 ## Reference Implementation
 
@@ -105,18 +107,18 @@ contract ERC7627 {
 
     mapping(address => UserInfo) public pk;
 
-    event MessageSent(address indexed from, address indexed to, string sessionId, bytes encryptedMessage);
+    event MessageSent(address indexed from, address indexed to, bytes32 sessionId, bytes encryptedMessage);
     event PublicKeyUpdated(address indexed user, bytes newPublicKey, PublicKeyAlgorithm algorithm);
 
     // Function to register a user with their public key
-    function updatePublicKey(bytes memory _publicKey, PublicKeyAlgorithm _algorithm) public {
+    function updatePublicKey(bytes calldata _publicKey, PublicKeyAlgorithm _algorithm) public {
         pk[msg.sender].publicKey = _publicKey;
         pk[msg.sender].algorithm = _algorithm;
         emit PublicKeyUpdated(msg.sender, _publicKey, _algorithm);
     }
 
     // Function to send an encrypted message from one user to another
-    function sendMessage(address _to, string memory _sessionId, bytes memory _encryptedMessage) public {
+    function sendMessage(address _to, bytes32 _sessionId, bytes calldata _encryptedMessage) public {
         emit MessageSent(msg.sender, _to, _sessionId, _encryptedMessage);
     }
 
@@ -130,13 +132,17 @@ contract ERC7627 {
 
 ## Security Considerations
 
-1. Utilization of Latest Secure Encryption Algorithms: When selecting encryption algorithms, it is essential to stay informed about the latest security news and recommendations. Avoid using asymmetric encryption algorithms with known vulnerabilities or those not recommended to ensure the confidentiality and integrity of messages. Regularly update encryption algorithms to address evolving security threats.
+#### Utilization of Latest Secure Encryption Algorithms
+When selecting encryption algorithms, it is essential to stay informed about the latest security news and recommendations. Avoid using asymmetric encryption algorithms with known vulnerabilities or those not recommended to ensure the confidentiality and integrity of messages. Regularly update encryption algorithms to address evolving security threats.
 
-2. Strict Encryption Using Public Keys for Message Content: To maintain message confidentiality, the content of sent messages must be strictly encrypted using the recipient's public key. Any plaintext information transmitted could lead to information leakage and security risks. Encrypt message content at all times during transmission and storage to prevent unauthorized access to sensitive information.
+#### Strict Encryption Using Public Keys for Message Content
+To maintain message confidentiality, the content of sent messages must be strictly encrypted using the recipient's public key. Any plaintext information transmitted could lead to information leakage and security risks. Encrypt message content at all times during transmission and storage to prevent unauthorized access to sensitive information.
 
-3. Key Management and Protection: Robust key management and protection measures are necessary for both user public and private keys. Ensure secure storage and transmission of keys to prevent leakage and tampering. Employ multi-factor authentication and key rotation strategies to enhance key security and regularly assess key management processes to mitigate potential security risks.
+#### Key Management and Protection
+Robust key management and protection measures are necessary for both user public and private keys. Ensure secure storage and transmission of keys to prevent leakage and tampering. Employ multi-factor authentication and key rotation strategies to enhance key security and regularly assess key management processes to mitigate potential security risks.
 
-4. Auditing and Monitoring: Implement auditing and monitoring mechanisms to track message sending and receiving, as well as key usage. Promptly identify anomalous activities and potential security threats and take appropriate response measures. Record critical operations and events for security incident investigation and traceability purposes.
+#### Auditing and Monitoring
+Implement auditing and monitoring mechanisms to track message sending and receiving, as well as key usage. Promptly identify anomalous activities and potential security threats and take appropriate response measures. Record critical operations and events for security incident investigation and traceability purposes.
 
 ## Copyright
 

ERCS/erc-7631.md

@@ -0,0 +1,123 @@
+---
+eip: 7631
+title: Dual Nature Token Pair
+description: A specification for a co-joined fungible and non-fungible token pair
+author: vectorized (@optimizoor), Thomas (@0xjustadev), Quit (@0xQuit), Michael Amadi (@AmadiMichaels), cygaar (@0xCygaar), Harrison (@PopPunkOnChain)
+discussions-to: https://ethereum-magicians.org/t/erc-7631-dual-nature-token-pair/18796
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-02-21
+requires: 20, 721
+---
+
+## Abstract
+
+A fungible [ERC-20](./eip-20.md) token contract and non-fungible [ERC-721](./eip-721.md) token contract can be interlinked, allowing actions performed on one contract to be reflected on the other. This proposal defines how the relationship between the two token contracts can be queried. It also enables accounts to configure if ERC-721 mints and transfers should be skipped during ERC-20 to ERC-721 synchronization.
+
+## Motivation
+
+The ERC-20 fungible and ERC-721 non-fungible token standards offer sufficient flexibility for a co-joined, dual nature token pair. Transfers on the ERC-20 token can automatically trigger transfers on the ERC-721 token, and vice-versa. This enables applications such as native ERC-721 fractionalization, wherein purchasing ERC-20 tokens leads to the automatic issuance of ERC-721 tokens, proportional to the ERC-20 holdings.
+
+Dual nature token pairs maintain full compliance with both ERC-20 and ERC-721 token standards. This proposal aims to enhance the functionality of dual nature token pairs.
+
+To facilitate querying the relationship between the tokens, extension interfaces are proposed for the ERC-20 and ERC-721 tokens respectively. This enables various quality of life improvements such as allowing decentralized exchanges and NFT marketplaces to display the relationship between the tokens.
+
+Additionally, users can configure if they want to skip ERC-721 mints and transfers during ERC-20 to ERC-721 synchronization.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### Overview
+
+A dual nature token pair comprises of an ERC-20 contract and an ERC-721 contract.
+
+For convention, the ERC-20 contract is designated as the base contract, and the ERC-721 contract is designated as the mirror contract.
+
+### ERC-20 Extension Interface
+
+The ERC-20 contract MUST implement the following interface.
+
+```solidity
+interface IERC7631Base {
+    /// @dev Emitted when the skip NFT status of `owner` is changed by
+    /// any mechanism.
+    ///
+    /// This initial skip NFT status for `owner` can be dynamically chosen to
+    /// be true or false, but any changes to it MUST emit this event.
+    event SkipNFTSet(address indexed owner, bool status);
+
+    /// @dev Returns true if ERC-721 mints and transfers to `owner` SHOULD be
+    /// skipped during ERC-20 to ERC-721 synchronization. Otherwise false.
+    /// 
+    /// This method MAY revert (e.g. contract not initialized).
+    ///
+    /// Once a true or false value has been returned for a given `owner`,
+    /// this method MUST NOT revert for the given `owner`.
+    function getSkipNFT(address owner) external view returns (bool);
+
+    /// @dev Sets the caller's skip NFT status.
+    ///
+    /// This method MAY revert (e.g. due to insufficient permissions).
+    ///
+    /// Emits a {SkipNFTSet} event.
+    function setSkipNFT(bool status) external;
+
+    /// @dev Returns the address of the mirror NFT contract.
+    ///
+    /// This method MAY revert or return the zero address
+    /// to denote that a mirror ERC721 contract has not been linked.
+    ///
+    /// If a non-zero address is returned, the returned address MUST
+    /// implement `IERC7631Mirror` and its `baseERC20()` method MUST
+    /// return the address of this contract.
+    ///
+    /// Once a non-zero address has been returned, this method
+    /// MUST NOT revert and the returned value MUST NOT change.
+    function mirrorERC721() external view returns (address);
+}
+```
+
+### ERC-721 Extension Interface
+
+The ERC-721 contract MUST implement the following interface.
+
+```solidity
+interface IERC7631Mirror {
+    /// @dev Returns the address of the mirror NFT contract.
+    /// This method MAY revert or return the zero address
+    /// to denote that a base ERC-20 contract has not been linked.
+    ///
+    /// If a non-zero address is returned, the returned address MUST
+    /// implement `IERC7631Base` and its `mirrorERC721()` method MUST
+    /// return the address of this contract.
+    ///
+    /// Once a non-zero address has been returned, this method
+    /// MUST NOT revert and the returned value MUST NOT change.
+    function baseERC20() external view returns (address);
+}
+```
+## Rationale
+
+A useful pattern is to make the `getSkipNFT(address owner)` return true by default if `owner` is a smart contract. This allows ERC-20 liquidity pools to avoid having ERC-721 tokens automatically minted to it by default whenever there is an ERC-20 transfer.
+
+The `mirrorERC721()` and `baseERC20()` returning addresses suffice to signal that the contracts implement the required interfaces. As such, [ERC-165](./eip-165.md) is not required.
+
+The ERC-20 contract is designated as the base contract for convention, as a typical implementation can conveniently derive ERC-721 balances from the ERC-20 balances. This does not prohibit one from implementing most of the logic in the ERC-721 contract if required.
+
+This proposal does not cover the token synchronization logic. This is to leave flexibility for various implementation patterns and novel use cases (e.g. automatically rebased tokens).
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+## Security Considerations
+
+A dual nature token pair will need synchronization logic. The external functions for synchronization logic must be guarded such that only the other contract is authorized to call.
+
+Minting, transferring, burning multiple ERC-721 tokens, and selection of ERC-721 token IDs incur O(n) gas costs instead of the O(1) gas costs for ERC-20 tokens. Synchronization logic must consider ERC-721 related gas costs to prevent denial of service issues.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).