This proposal defines a system which embeds a Function Oracle that can wrap fungible tokens to non-fungible token and unwrap the non-fungible back to fungible tokens. The preset Function Oracle provides its own Automated Market Maker(AMM) so that it standardize the process of a creating pool for the issuer of vouchers.
Under current framework of pool, it is hard for user to define how to manage the pool without coding. However, we believe it should be more accessible for users to define and create their own pools to energize the market. Through employing FTs as premium for NFTs under a customizable framework, such an approach standardize the process of creating a pool and allows users to gain the ability to “do it yourself.”
We want to propose an infrastructure for decentralized platforms and prompt the development of the decentralized voucher system.
Yes, we will continue post our updates for rationale and more general ideas behind the design. And we will provide some examples on how to implement it and possibilities for future application.
This is awesome. By standardizing the process of creating a pool for voucher issuers, this system provides liquidity to credit assets. This liquidity can make credit assets more accessible and tradable in various scenarios.
The EIP7797 is very cool. This will be a disruptive asset issuance protocol. I think there are at least two things that are subversive:
Asset issuance rights are controlled by users, not the so-called project parties
Asset issuance has sufficient liquidity.
The project party only formulates the rules for asset issuance. Both project parties and users need to mint assets according to the rules, and these assets will automatically enter the Pool. Any asset holder can redeem their assets at any time. Not only NFT artists, but also games, social media, and even any influential organization or individual can use this standard to issue assets without worrying about unfair asset issuance and insufficient asset liquidity. Very good, looking forward to further development.
If Factory is implemented, it does not distinguish what kind of currency would be received by the Agency. For conciseness, we require Agency to implement a receive function.
We can change it to be when Factory is implemented and able to accept ETH as Asset, accounts in Agency MUST implement a receive function.
So it’s perfectly valid for an implementation to reject all ether, but it still has to define a receive function?
This case can happen if Agency only accepts ERC20.