Is ERC-404 Not Aligned? Unlocking RWA Liquidity and Housing the Commons

I think the previous answers cover this question. To reiterate, it would be easier starting from digital nomads comm, but we also welcome regular tenants to participate in the experiment.

The success of this experiment depends on whether we have the appropriate properties, tenants, and landlords.

We haven’t designed such details yet, but should get an experienced estate agent and lawyer to design it.

Already answered.

Lets have a look at the code of ERC-404

Its uniqueness lies in the following:

/// @notice ERC404
///         A gas-efficient, mixed ERC20 / ERC721 implementation
///         with native liquidity and fractionalization.
abstract contract ERC404 is Ownable {
    // Mapping for balance and approvals
    mapping(address => uint256) public balanceOf;
    mapping(uint256 => address) public getApproved;

    // Events for transfers and approvals
    event ERC20Transfer(address indexed from, address indexed to, uint256 amount);
    event Transfer(address indexed from, address indexed to, uint256 indexed id);

    // Function that manages FT and NFT transfers
    function transferFrom(
        address from,
        address to,
        uint256 amountOrId
    ) public virtual {
        if (amountOrId <= minted) { // NFT transfer logic
            // Ownership and approval checks and updates
        } else { // FT transfer logic
            // Handle token amount adjustments and possible mint/burn
        }
    }
    
    // Safe transfer functions ensuring the recipient can handle the NFT
    function safeTransferFrom(
        address from,
        address to,
        uint256 id,
        bytes calldata data
    ) public virtual {
        transferFrom(from, to, id);
        require(to.code.length != 0 && ERC721Receiver(to).onERC721Received(msg.sender, from, id, data) ==
            ERC721Receiver.onERC721Received.selector, "Unsafe recipient");
    }
}

its features:

  1. Native Liquidity and Fractionalization Support:
  • The ERC404 contract has key features that handle the liquidity between FTs and NFTs natively within the contract. For instance, the transferFrom and _transfer methods manage the transfer of both NFTs (identified by ID) and FTs (identified by amount), ensuring proper association and handling between NFTs and FTs.
  1. Independence from External Contracts:
  • The contract is self-contained and does not require calls to external contracts to perform its functions. All functionalities, including ownership transfers, approvals, and transfers, are managed internally using its own logic and storage to maintain state consistency and data integrity.
  1. Handling FT and NFT Interchange:
  • In the transferFrom method, the contract distinguishes between transferring NFTs and FTs. For NFTs, it handles updates to ownership and approval status; for FTs, it deals with adjusting quantities and potential minting or burning operations to maintain accuracy in the total supply.
  1. Security and Efficiency Enhancements:
  • The contract employs a whitelist mechanism to identify addresses that can bypass certain costs (like minting and burning), optimizing gas consumption during transactions.
  • It uses the safeTransferFrom method to add checks for receiving contracts, ensuring NFTs are securely transferred to contracts that can handle ERC721 tokens.
  1. Constraints and Optimizations in Details:
  • By setting constraints such as decimals and totalSupply, the contract ensures that operations with FTs can effectively integrate with the encoding and processing of NFT IDs, supporting token fractionalization and efficient resource management.

I’m very grateful for @Valerie_Shieh’s detailed reply and insights into the current erc404, which not only enriched the content of the topic but also presented more possibilities for deeper thinking. The infrastructure for the 404 protocol is still weak, but the emergence of new protocols always brings new hope, right? I hope that this event can attract more like-minded people to build together.

1 Like