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.
Hi,
I’ve been reading 7527 closely while mapping prior art for a related design, and I have a question about one specific choice.
As I read the spec, the premium transferred into the Agency cannot move except through unwrap, and executing unwrap is the only thing that triggers the burn. That makes the wrapped value genuinely inseparable from the token. That invariant is the one I care about too, and out of roughly fifteen standards and products I’ve gone through 551, 998, 7401, vesting NFTs, liquidity positions, the redeemables and 7527 is the only one that actually gets there. Everywhere else the contents can leave without destroying the token.
Where I’m heading differs on the accounting rather than on the invariant: a per-tokenId composition, fixed at mint, where what comes back on burn is exactly what went into that specific token. No shared reserve, no pricing function.
So my question is about the reserve model. Was per-token accounting considered and rejected during design, or was the shared-reserve-plus-function-oracle approach the starting point from the beginning? I’d like to understand what the FOAMM pricing buys you that per-token accounting cannot, because I suspect the answer says something useful about the limits of what I’m doing.
I’m writing this up as a draft proposal at the moment. If any of you would be interested in tearing it apart once there’s something concrete to read, I’d welcome it you’ve thought about this problem longer than I have.