MicahZoltu

MicahZoltu

Member Since 10 years ago

@AugurProject , Philippines

Experience Points
244
follower
Lessons Completed
0
follow
Lessons Completed
5
stars
Best Reply Awards
124
repos

1359 contributions in the last year

Pinned
⚡ Template project that shows how to use ES modules in a browser.
⚡ A simple example of a TypeScript library.
⚡ Example of a simple mono-repo TypeScript project.
⚡ A skeleton for un-bundled react projects.
Activity
Jan
19
11 hours ago
pull request

MicahZoltu pull request MicahZoltu/browser-es-modules-template

MicahZoltu
MicahZoltu

Bump follow-redirects from 1.13.0 to 1.14.7

Bumps follow-redirects from 1.13.0 to 1.14.7.

Commits
  • 2ede36d Release version 1.14.7 of the npm package.
  • 8b347cb Drop Cookie header across domains.
  • 6f5029a Release version 1.14.6 of the npm package.
  • af706be Ignore null headers.
  • d01ab7a Release version 1.14.5 of the npm package.
  • 40052ea Make compatible with Node 17.
  • 86f7572 Fix: clear internal timer on request abort to avoid leakage
  • 2e1eaf0 Keep Authorization header on subdomain redirects.
  • 2ad9e82 Carry over Host header on relative redirects (#172)
  • 77e2a58 Release version 1.14.4 of the npm package.
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

Activity icon
issue

MicahZoltu issue comment MicahZoltu/browser-es-modules-template

MicahZoltu
MicahZoltu

Bump follow-redirects from 1.13.0 to 1.14.7

Bumps follow-redirects from 1.13.0 to 1.14.7.

Commits
  • 2ede36d Release version 1.14.7 of the npm package.
  • 8b347cb Drop Cookie header across domains.
  • 6f5029a Release version 1.14.6 of the npm package.
  • af706be Ignore null headers.
  • d01ab7a Release version 1.14.5 of the npm package.
  • 40052ea Make compatible with Node 17.
  • 86f7572 Fix: clear internal timer on request abort to avoid leakage
  • 2e1eaf0 Keep Authorization header on subdomain redirects.
  • 2ad9e82 Carry over Host header on relative redirects (#172)
  • 77e2a58 Release version 1.14.4 of the npm package.
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

MicahZoltu
MicahZoltu

Closing as this is only used in local testing, so an attacker would only be able to attack themselves IIUC.

pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Move EIP-231 5 to Review

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
MicahZoltu
MicahZoltu

This currently depends on 3540 (Review), 3670 (Review), 3779 (Draft), and 4200 (Draft). Any dependencies need to be at least as far along in the EIP process as the dependent, which means this can't move to Review until 3779 and 4200 are in Review. I didn't dig deep into the technical details for those dependencies, but if they aren't strictly required then an appropriate course of action may be to just remove the dependency. If you decide to go that route, you'll need to remove the external link to EIP-3779 and EIP-4200 in the Specification and Backward Compatibility sections.


External links should be removed before merging into Review. Specifically this line:

The concept goes back to Turing's Automatic Computing Engine of 1946:

I recommend just keeping the text and the attached quote, without the links. If someone wants to look up the source of the quote they can just do an internet search for it, though that shouldn't matter because the argument should stand on its own without needing to appeal to an authority (especially one from 80 years ago).


I personally recommend removing the entire History section. I generally let people include just about whatever they want in the Motivation (aside from external links), so this isn't a blocker but I think history lessons are way out of scope for an EIP. The motivation section should be brief in explaining the value this standard adds to the ecosystem and leave it up to the user or the discussions-to for additional argumentation/context.


Test Cases section should be above the Security Considerations section.


Editor note: I just wanted to say how I appreciate your Test Cases section. Most EIPs don't include any test cases, or if they do they are ill defined. The test cases here are quite above the bar and I'm very happy to see them!

push

MicahZoltu push ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191 (#4677)

  • Typo in eip-191

commit sha: d7d932d4a1240eb06be01e38f784a92df097901f

push time in 7 hours ago
pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

Jan
16
3 days ago
Activity icon
issue

MicahZoltu issue ethereum/EIPs

MicahZoltu
MicahZoltu

@chriseth Following our chat a while ago, would it be possible to add the hint of the struct type to the abi? This is probably the simplest solution before we have @axic ```annotatedTypes```

@chriseth Following our chat a while ago, would it be possible to add the hint of the struct type to the abi? This is probably the simplest solution before we have @axic annotatedTypes

Similar to what @iikirilov said, this will allow for simple identification of the different structs and be code generated accordingly so we can avoid duplication of types generated.

{  
   "components":[  
       {  
          "name":"id",
           "type":"string"
       },
       {  
          "name":"name",
           "type":"string"
       }
   ],
   "name":"_toSet",
   "type":"tuple"
   "namedType": "Foo"
}

Originally posted by @juanfranblanco in https://github.com/ethereum/solidity/issues/3618#issuecomment-475272597

pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

Update eip-4573.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

Update eip-4573.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
Jan
15
4 days ago
open pull request

MicahZoltu wants to merge ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

MicahZoltu
MicahZoltu
    3. User `A` and `B` submit `presigned` transactions to `X`.
pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

MicahZoltu
MicahZoltu

Thinking twice on this, if we are going to fix the typo, we should fix it all the way. 😄

pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

MicahZoltu
MicahZoltu

Thinking twice on this, if we are going to fix the typo, we should fix it all the way. 😄

Activity icon
issue

MicahZoltu issue ethereum/EIPs

MicahZoltu
MicahZoltu

Discussion: 2-hop Blockchain, Combining PoW and PoS Securely on ETH (EIPxxxx)

Instead of moving ETH entirely from PoW to PoS Consensus mechanism, would it be possible to merge both PoW and PoS in parallel on 2-hop Blockchain like the one theorized here https://eprint.iacr.org/2016/716.pdf (2-hop Blockchain: Combining Proof-of-Work and Proof-of-Stake Securely).

"From 1-hop to 2-hop blockchain. Nakamoto’s system is powered by physical computing resources, and the blockchain is maintained by PoW-miners; there, each winning PoW-miner can extend the blockchain with a new block. In our design, as argued above, we (intend to) use both physical resources and virtual resources. That means, in addition to PoW-miners, a new type of players — PoS-holder (stakeholder) — is introduced in our system. Now a winning PoW-miner cannot extend the blockchain immediately. Instead, the winning PoW-miner provides a base which enables a PoS-holder to be “selected” to extend the blockchain. In short, in our system, a PoW-miner and then a PoS-holder jointly extend the blockchain with a new block. If Nakamoto’s consensus can be viewed as a 1-hop protocol, then ours is a 2-hop protocol."

Merging PoW and PoS would prevent possibility of another hardfork by PoW miners after ETH moves to PoS, also it supports the PoW miners who had been supporting the network since its infancy, instead of ditching miners entirely wouldn't it be better to integrate them into a new system where PoS and PoW can work in parallel, supporting each other.

2016-716.pdf

Activity icon
issue

MicahZoltu issue comment ethereum/EIPs

MicahZoltu
MicahZoltu

Discussion: 2-hop Blockchain, Combining PoW and PoS Securely on ETH (EIPxxxx)

Instead of moving ETH entirely from PoW to PoS Consensus mechanism, would it be possible to merge both PoW and PoS in parallel on 2-hop Blockchain like the one theorized here https://eprint.iacr.org/2016/716.pdf (2-hop Blockchain: Combining Proof-of-Work and Proof-of-Stake Securely).

"From 1-hop to 2-hop blockchain. Nakamoto’s system is powered by physical computing resources, and the blockchain is maintained by PoW-miners; there, each winning PoW-miner can extend the blockchain with a new block. In our design, as argued above, we (intend to) use both physical resources and virtual resources. That means, in addition to PoW-miners, a new type of players — PoS-holder (stakeholder) — is introduced in our system. Now a winning PoW-miner cannot extend the blockchain immediately. Instead, the winning PoW-miner provides a base which enables a PoS-holder to be “selected” to extend the blockchain. In short, in our system, a PoW-miner and then a PoS-holder jointly extend the blockchain with a new block. If Nakamoto’s consensus can be viewed as a 1-hop protocol, then ours is a 2-hop protocol."

Merging PoW and PoS would prevent possibility of another hardfork by PoW miners after ETH moves to PoS, also it supports the PoW miners who had been supporting the network since its infancy, instead of ditching miners entirely wouldn't it be better to integrate them into a new system where PoS and PoW can work in parallel, supporting each other.

2016-716.pdf

MicahZoltu
MicahZoltu

https://ethresear.ch/ is a more appropriate place to have a discussion about this. Alternatively, Ethereum Magicians (as the bot suggested) would be another option for discussing such things.

pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Typo in eip-191

I noticed a typo in eip-191, so I thought I would fix it. I couldn't find any contributing guidelines so I hope this is ok.

Activity icon
issue

MicahZoltu issue ethereum/EIPs

MicahZoltu
MicahZoltu

Multi-Fractional Non-Fungible Token Standard


eip: title: Multi-Fractional Non-Fungible Token Standard description: author: David Kim(@powerstream3604) discussions-to: status: Draft type: Standards Track category: ERC created: 2021-01-13 requires: 165

Abstract

This standard outlines a smart contract interface eligible to represent any number of fractionalized non-fungible tokens. Existing projects utilizing standards like EIP-1633 conventionally deploy seperate ERC-20 compatible token standard to fractionalize the non-fungible token into ERC-20 tokens. In contrast, this ERC allows each token ID to represent a token type representing(fractionalizing) the non-fungible token.

This standard is approximate in terms of using _id for distinguishing token types. However, this ERC has a clear difference with ERC-1155 as each _id represents a distinct NFT.

Motivation

The conventional fractionalization process of fractionalizing a NFT to FT requires deployment of a FT token contract representing the ownership of NFT. This leads to inefficient bytecode usage on Ethereum Blockchain and limits functionalities since each token contract is seperated into its own permissioned address. With the rise of multiple NFT projects needing to fractionalize NFT to FT, new type of token standard is needed to back up them.

Specification

/**
    @title Multi-Fractional Non-Fungible Token Standard
    @dev Note : The ERC-165 identifier for this interface is 0x83f5d35f.
*/
interface IMFNFT {
    /**
        @dev This emits when ownership of any token changes by any mechanism.
        The `_from` argument MUST be the address of an account/contract sending the token.
        The `_to` argument MUST be the address of an account/contract receiving the token.
        The `_id` argument MUST be the token type being transferred. (represents NFT)
        The `_value` argument MUST be the number of tokens the holder balance is decrease by and match the recipient balance is increased by.
    */
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _id, uint256 _value);

    /**
        @dev This emits when the approved address for token is changed ot reaffirmed.
        The `_owner` argument MUST be the address of account/contract approving to withdraw.
        The `_spender` argument MUST be the address of account/contract approved to withdraw from the `_owner` balance.
        The `_id` argument MUST be the token type being transferred. (represents NFT)
        The `_value` argument MUST be the number of tokens the `_approved` is able to withdraw from `_owner` balance.
    */
    event Approval(address indexed _owner, address indexed _spender, uint256 indexed _id, uint256 _value);

    /**
        @dev This emits when new token type is added which represents the share of the Non-Fungible Token.
        The `_parentToken` argument MUST be the address of the Non-Fungible Token contract.
        The `_parentTokenId` argument MUST be the token ID of the Non-Fungible Token.
        The `_id` argument MUST be the token type being added. (represents NFT)
        The `_totalSupply` argument MUST be the number of total token supply of the token type.
    */
    event TokenAddition(address indexed _parentToken, uint256 indexed _parentTokenId, uint256 _id, uint256 _totalSupply);

    /**
        @notice Transfers `_value` amount of an `_id` from the msg.sender address to the `_to` address specified
        @dev msg.sender must have sufficient balance to handle the tokens being transferred out of the account.
        MUST revert if `_to` is the zero address.
        MUST revert if balance of msg.sender for token `_id` is lower than the `_value` being transferred.
        MUST revert on any other error.
        MUST emit the `Transfer` event to reflect the balance change.
        @param _to      Source address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @return         True if transfer was successful, false if not
    */
    function transfer(address _to, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Approves `_value` amount of an `_id` from the msg.sender to the `_spender` address specified.
        @dev msg.sender must have sufficient balance to handle the tokens when the `_spender` wants to transfer the token on behalf.
        MUST revert if `_spender` is the zero address.
        MUST revert on any other error.
        MUST emit the `Approval` event.
        @param _spender Spender address(account/contract which can withdraw token on behalf of msg.sender)
        @param _id      ID of the token type
        @param _value   Approval amount
        @return         True if approval was successful, false if not
    */
    function approve(address _spender, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified.
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account.
        MUST revert if `_to` is the zero address.
        MUST revert if balance of holder for token `_id` is lower than the `_value` sent.
        MUST revert on any other error.
        MUST emit `Transfer` event to reflect the balance change.
        @param _from    Source address
        @param _to      Target Address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @return         True if transfer was successful, false if not

    */
    function transferFrom(address _from, address _to, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Sets the NFT as a new type token
        @dev The contract itself should verify if the ownership of NFT is belongs to this contract itself with the `_parentNFTContractAddress` & `_parentNFTTokenId` before adding the token.
        MUST revert if the same NFT is already registered.
        MUST revert if `_parentNFTContractAddress` is address zero.
        MUST revert if `_parentNFTContractAddress` is not ERC-721 compatible.
        MUST revert if this contract itself is not the owner of the NFT.
        MUST revert on any other error.
        MUST emit `TokenAddition` event to reflect the token type addition.
        @param _parentNFTContractAddress    NFT contract address
        @param _parentNFTTokenId            NFT tokenID
        @param _totalSupply                 Total token supply
    */
    function setParentNFT(address _parentNFTContractAddress, uint256 _parentNFTTokenId, uint256 _totalSupply) external;

    /**
        @notice Get the token ID's total token supply.
        @param _id      ID of the token
        @return         The total token supply of the specified token type
    */
    function totalSupply(uint256 _id) external view returns (uint256);

    /**
        @notice Get the balance of an account's tokens.
        @param _owner  The address of the token holder
        @param _id     ID of the token
        @return        The _owner's balance of the token type requested
    */
    function balanceOf(address _owner, uint256 _id) external view returns (uint256);

    /**
        @notice Get the amount which `_spender` is still allowed to withdraw from `_owner`
        @param _owner   The address of the token holder
        @param _spender The address approved to withdraw token on behalf of `_owner`
        @param _id      ID of the token
        @return         The amount which `_spender` is still allowed to withdraw from `_owner`
    */
    function allowance(address _owner, address _spender, uint256 _id) external view returns (uint256);

    /**
        @notice Get the bool value which represents whether the NFT is already registered and fractionalized by this contract.
        @param _parentNFTContractAddress    NFT contract address
        @param _parentNFTTokenId            NFT tokenID
        @return                             The bool value representing the whether the NFT is already registered.
    */
    function isRegistered(address _parentNFTContractAddress, uint256 _parentNFTTokenId) external view returns (bool);
}

interface ERC165 {
    /**
        @notice Query if a contract implements an interface
        @param interfaceID The interface identifier, as specified in ERC-165
        @dev Interface identification is specified in ERC-165. This function
        uses less than 30,000 gas.
        @return `true` if the contract implements `interfaceID` and
        `interfaceID` is not 0xffffffff, `false` otherwise
    */
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

To receive Non-Fungible Token on safe Transfer the contract should include onERC721Received(). Including onERC721Received() is needed to be compatible with Safe Transfer Rules.

/**
    @notice Handle the receipt of an NFT
    @param _operator The address which called `safeTransferFrom` function
    @param _from The address which previously owned the token
    @param _tokenId The NFT identifier which is being transferred
    @param _data Additional data with no specified format
    @return `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
*/
function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes calldata _data) external pure returns (bytes4);

Rationale

Metadata

The symbol() & name() function was not included since the majority of users can just fetch it from the originating NFT contract. Also, copying the name & symbol every time when token gets added might place a lot of redundant bytecode on the Ethereum blockchain. However, according to the need and design of the project it could also be added to each token type by fetching the metadata from the NFT contract.

Design

Most of the decisions made around the design of this ERC were done to keep it as flexible for diverse token design & architecture. These minimum requirement for this standard allows for each project to determine their own system for minting, governing, burning their MFNFT tokens depending on their programmable architecture.

Backwards Compatibility

To make this standard compatible with existing standards, this standard event & function names are identical with ERC-20 token standard with some more events & functions to add token type dynamically.

Also, the sequence of parameter in use of _id for distinguishing token types in functions and events are very much similar to ERC-1155 Multi-Token Standard.

Since this standard is intended to interact with the EIP-721 Non-Fungible Token Standard, it is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token usage and scenario.

Test Cases

Reference Implementation of MFNFT Token includes test cases written using hardhat. (Test coverage : 100%)

References

Standards

Implementations

Multi-Fractional NFT Implementations and Projects

  1. TWIG. https://twig.money/

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

David Kim "EIP-: Multi-Fractional Non-Fungible Token"

Activity icon
issue

MicahZoltu issue comment ethereum/EIPs

MicahZoltu
MicahZoltu

Multi-Fractional Non-Fungible Token Standard


eip: title: Multi-Fractional Non-Fungible Token Standard description: author: David Kim(@powerstream3604) discussions-to: status: Draft type: Standards Track category: ERC created: 2021-01-13 requires: 165

Abstract

This standard outlines a smart contract interface eligible to represent any number of fractionalized non-fungible tokens. Existing projects utilizing standards like EIP-1633 conventionally deploy seperate ERC-20 compatible token standard to fractionalize the non-fungible token into ERC-20 tokens. In contrast, this ERC allows each token ID to represent a token type representing(fractionalizing) the non-fungible token.

This standard is approximate in terms of using _id for distinguishing token types. However, this ERC has a clear difference with ERC-1155 as each _id represents a distinct NFT.

Motivation

The conventional fractionalization process of fractionalizing a NFT to FT requires deployment of a FT token contract representing the ownership of NFT. This leads to inefficient bytecode usage on Ethereum Blockchain and limits functionalities since each token contract is seperated into its own permissioned address. With the rise of multiple NFT projects needing to fractionalize NFT to FT, new type of token standard is needed to back up them.

Specification

/**
    @title Multi-Fractional Non-Fungible Token Standard
    @dev Note : The ERC-165 identifier for this interface is 0x83f5d35f.
*/
interface IMFNFT {
    /**
        @dev This emits when ownership of any token changes by any mechanism.
        The `_from` argument MUST be the address of an account/contract sending the token.
        The `_to` argument MUST be the address of an account/contract receiving the token.
        The `_id` argument MUST be the token type being transferred. (represents NFT)
        The `_value` argument MUST be the number of tokens the holder balance is decrease by and match the recipient balance is increased by.
    */
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _id, uint256 _value);

    /**
        @dev This emits when the approved address for token is changed ot reaffirmed.
        The `_owner` argument MUST be the address of account/contract approving to withdraw.
        The `_spender` argument MUST be the address of account/contract approved to withdraw from the `_owner` balance.
        The `_id` argument MUST be the token type being transferred. (represents NFT)
        The `_value` argument MUST be the number of tokens the `_approved` is able to withdraw from `_owner` balance.
    */
    event Approval(address indexed _owner, address indexed _spender, uint256 indexed _id, uint256 _value);

    /**
        @dev This emits when new token type is added which represents the share of the Non-Fungible Token.
        The `_parentToken` argument MUST be the address of the Non-Fungible Token contract.
        The `_parentTokenId` argument MUST be the token ID of the Non-Fungible Token.
        The `_id` argument MUST be the token type being added. (represents NFT)
        The `_totalSupply` argument MUST be the number of total token supply of the token type.
    */
    event TokenAddition(address indexed _parentToken, uint256 indexed _parentTokenId, uint256 _id, uint256 _totalSupply);

    /**
        @notice Transfers `_value` amount of an `_id` from the msg.sender address to the `_to` address specified
        @dev msg.sender must have sufficient balance to handle the tokens being transferred out of the account.
        MUST revert if `_to` is the zero address.
        MUST revert if balance of msg.sender for token `_id` is lower than the `_value` being transferred.
        MUST revert on any other error.
        MUST emit the `Transfer` event to reflect the balance change.
        @param _to      Source address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @return         True if transfer was successful, false if not
    */
    function transfer(address _to, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Approves `_value` amount of an `_id` from the msg.sender to the `_spender` address specified.
        @dev msg.sender must have sufficient balance to handle the tokens when the `_spender` wants to transfer the token on behalf.
        MUST revert if `_spender` is the zero address.
        MUST revert on any other error.
        MUST emit the `Approval` event.
        @param _spender Spender address(account/contract which can withdraw token on behalf of msg.sender)
        @param _id      ID of the token type
        @param _value   Approval amount
        @return         True if approval was successful, false if not
    */
    function approve(address _spender, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified.
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account.
        MUST revert if `_to` is the zero address.
        MUST revert if balance of holder for token `_id` is lower than the `_value` sent.
        MUST revert on any other error.
        MUST emit `Transfer` event to reflect the balance change.
        @param _from    Source address
        @param _to      Target Address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @return         True if transfer was successful, false if not

    */
    function transferFrom(address _from, address _to, uint256 _id, uint256 _value) external returns (bool);

    /**
        @notice Sets the NFT as a new type token
        @dev The contract itself should verify if the ownership of NFT is belongs to this contract itself with the `_parentNFTContractAddress` & `_parentNFTTokenId` before adding the token.
        MUST revert if the same NFT is already registered.
        MUST revert if `_parentNFTContractAddress` is address zero.
        MUST revert if `_parentNFTContractAddress` is not ERC-721 compatible.
        MUST revert if this contract itself is not the owner of the NFT.
        MUST revert on any other error.
        MUST emit `TokenAddition` event to reflect the token type addition.
        @param _parentNFTContractAddress    NFT contract address
        @param _parentNFTTokenId            NFT tokenID
        @param _totalSupply                 Total token supply
    */
    function setParentNFT(address _parentNFTContractAddress, uint256 _parentNFTTokenId, uint256 _totalSupply) external;

    /**
        @notice Get the token ID's total token supply.
        @param _id      ID of the token
        @return         The total token supply of the specified token type
    */
    function totalSupply(uint256 _id) external view returns (uint256);

    /**
        @notice Get the balance of an account's tokens.
        @param _owner  The address of the token holder
        @param _id     ID of the token
        @return        The _owner's balance of the token type requested
    */
    function balanceOf(address _owner, uint256 _id) external view returns (uint256);

    /**
        @notice Get the amount which `_spender` is still allowed to withdraw from `_owner`
        @param _owner   The address of the token holder
        @param _spender The address approved to withdraw token on behalf of `_owner`
        @param _id      ID of the token
        @return         The amount which `_spender` is still allowed to withdraw from `_owner`
    */
    function allowance(address _owner, address _spender, uint256 _id) external view returns (uint256);

    /**
        @notice Get the bool value which represents whether the NFT is already registered and fractionalized by this contract.
        @param _parentNFTContractAddress    NFT contract address
        @param _parentNFTTokenId            NFT tokenID
        @return                             The bool value representing the whether the NFT is already registered.
    */
    function isRegistered(address _parentNFTContractAddress, uint256 _parentNFTTokenId) external view returns (bool);
}

interface ERC165 {
    /**
        @notice Query if a contract implements an interface
        @param interfaceID The interface identifier, as specified in ERC-165
        @dev Interface identification is specified in ERC-165. This function
        uses less than 30,000 gas.
        @return `true` if the contract implements `interfaceID` and
        `interfaceID` is not 0xffffffff, `false` otherwise
    */
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

To receive Non-Fungible Token on safe Transfer the contract should include onERC721Received(). Including onERC721Received() is needed to be compatible with Safe Transfer Rules.

/**
    @notice Handle the receipt of an NFT
    @param _operator The address which called `safeTransferFrom` function
    @param _from The address which previously owned the token
    @param _tokenId The NFT identifier which is being transferred
    @param _data Additional data with no specified format
    @return `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
*/
function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes calldata _data) external pure returns (bytes4);

Rationale

Metadata

The symbol() & name() function was not included since the majority of users can just fetch it from the originating NFT contract. Also, copying the name & symbol every time when token gets added might place a lot of redundant bytecode on the Ethereum blockchain. However, according to the need and design of the project it could also be added to each token type by fetching the metadata from the NFT contract.

Design

Most of the decisions made around the design of this ERC were done to keep it as flexible for diverse token design & architecture. These minimum requirement for this standard allows for each project to determine their own system for minting, governing, burning their MFNFT tokens depending on their programmable architecture.

Backwards Compatibility

To make this standard compatible with existing standards, this standard event & function names are identical with ERC-20 token standard with some more events & functions to add token type dynamically.

Also, the sequence of parameter in use of _id for distinguishing token types in functions and events are very much similar to ERC-1155 Multi-Token Standard.

Since this standard is intended to interact with the EIP-721 Non-Fungible Token Standard, it is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token usage and scenario.

Test Cases

Reference Implementation of MFNFT Token includes test cases written using hardhat. (Test coverage : 100%)

References

Standards

Implementations

Multi-Fractional NFT Implementations and Projects

  1. TWIG. https://twig.money/

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

David Kim "EIP-: Multi-Fractional Non-Fungible Token"

MicahZoltu
MicahZoltu

Please see https://github.com/ethereum/EIPs/pull/4675/files#r785277821, discussions should be over at Ethereum Magicians forum.

pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Add Multi-Fractional Non-Fungible Token Standard

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
open pull request

MicahZoltu wants to merge ethereum/EIPs

MicahZoltu
MicahZoltu

Add Multi-Fractional Non-Fungible Token Standard

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
MicahZoltu
MicahZoltu

discussions-to should point to a forum thread at https://ethereum-magicians.org/, not a GitHub issue.

Out of curiosity, where did you see that a GitHub issue should be created? We recently changed the policy on this and if there is some place we forgot to update it would be great to find and fix it!

pull request

MicahZoltu merge to ethereum/EIPs

MicahZoltu
MicahZoltu

Add Multi-Fractional Non-Fungible Token Standard

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
open pull request

MicahZoltu wants to merge ethereum/EIPs

MicahZoltu
MicahZoltu

Add Multi-Fractional Non-Fungible Token Standard

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
MicahZoltu
MicahZoltu
eip: 4675

Please also update the file name to EIPS/eip-4675.md

Jan
13
6 days ago
push

MicahZoltu push ethereum/EIPs

MicahZoltu
MicahZoltu

docs: fix a typo in eip-1015.md (#4670)

commit sha: 144a048fbe5a7a284d16af9601d4e517b6bea422

push time in 6 days ago
pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

docs: fix a typo in eip-1015.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

docs: fix a typo in eip-1015.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
pull request

MicahZoltu pull request ethereum/EIPs

MicahZoltu
MicahZoltu

docs: fix a typo in eip-1015.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
Activity icon
issue

MicahZoltu issue comment ethereum/EIPs

MicahZoltu
MicahZoltu

docs: fix a typo in eip-1015.md

Fix a typo

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
MicahZoltu
MicahZoltu

Merging without waiting since this is just a typo fix.

Previous