Title: ERC_7527__Token_Bound_Function_Oracle_AMM_Contract
Category: ERCs

Author: lanyinzly
Date: 2023-09-30T03:35:05.174Z

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.


github.com/ethereum/ERCs








Add ERC: Token Bound Function Oracle AMM


master ← lanyinzly:lanyinzly-patch-1



          opened 02:01AM - 31 Oct 23 UTC




            lanyinzly
          



+527
-0






When opening a pull request to submit a new EIP, please use the suggested templa…te: 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 <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.

Author: matt_2929
Date: 2023-10-03T00:26:07.402Z

Very good idea, can you expand on it?

Author: kaliwdsn
Date: 2023-10-06T01:20:02.099Z

Where can I view the code? I want to develop the core components of a full-chain game based on this.

Author: lanyinzly
Date: 2023-10-06T16:42:20.012Z

You can click the GitHub link and find the most updated version under “commits.”
The current version is: Add EIP: Token Bound Function Oracle AMM Contract by lanyinzly · Pull Request #7797 · ethereum/EIPs · GitHub
Keep clicking the blue “Expand Down” Button at left bottom corner if you cannot see the full script.

Author: lanyinzly
Date: 2023-10-06T16:49:41.377Z

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.

Author: likeaixi
Date: 2023-10-07T05:51:43.888Z

Looking forward to approval！

Author: amandafanny
Date: 2023-10-07T06:27:37.650Z

Very good idea,Looking forward to approval！

Author: Mani-T
Date: 2023-10-08T02:11:22.751Z

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.

Author: Peter.G
Date: 2023-10-08T07:34:11.429Z

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.

Author: DanceChange
Date: 2023-10-10T07:50:19.041Z

Perhaps, EIP-7797 will become the infrastructure for decentralized credit in the crypto world

Author: xsstc
Date: 2023-10-16T13:14:41.457Z

看了eip7527示例合约代码，我想问下，eip7527是怎样在amm提供流动性的。如果封装和解封装的fee是给流动性提供者，那么应该怎样成为流动性提供者

Author: SamWilsn
Date: 2024-01-12T21:38:06.009Z

These two requirements seem weird together:

Accounts MUST implement a receive function.
Accounts MAY perform arbitrary logic to restrict conditions under which Ether can be received.

So it’s perfectly valid for an implementation to reject all ether, but it still has to define a receive function?

Author: lanyinzly
Date: 2024-02-07T14:40:34.905Z

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.