Continuing from the previous discussion.

The entire blockchain industry is a history of expansion evolution. Various routes are being explored to speed up and reduce costs, but each has its own ceiling. Until AO, a paradigm different from traditional blockchain emerged. Through clever design, the block space on AO is no longer a fixed supply scarce resource, but an infinitely creatable resource based on demand, thus granting AO the ability for infinite scalability!

This also makes the financial model aimed at Agents—AgentFi—possible. Compared to traditional DeFi, AgentFi has a broader range of application scenarios.

Traditional DeFi protocols originated from Ethereum. Although various L2s and high-performance new public chains have emerged, people's imagination of the DeFi construction paradigm has always been limited to Ethereum. Now, let us step into a platform with no performance limitations, reminiscent of the internet's evolution from read-only to read-write, to algorithms, and to autonomy, and reimagine what on-chain finance should look like. Does a brand new picture emerge in your mind? A scene where all users can create financial Agents, and any computational unit can become a "financial institution," providing customized financial services in a financially equitable landscape!

Why is a standard protocol for Agents needed?

On the AO computer, processes communicate with each other through messages, and message transmission follows certain specifications. The same applies in financial scenarios.

Customization is the starting point of diversification. If different types of financial Agents develop independently, it will inevitably lead to different protocol specifications, making interaction between Agents a significant challenge. How can Agents communicate with each other and facilitate transactions?

To avoid the interoperability issues caused by a lack of unified standards, the FusionFi Protocol (FFP) was born.

As an interaction protocol between Agents, FusionFi Protocol defines the interaction rules among Agents, allowing various financial services created based on Agents to be interconnected and integrated. At the early stage of AgentFi, such a protocol can be considered quite forward-looking.

FFP (FusionFi Protocol)

FusionFi Protocol is a protocol launched by EverVision founder outprog at the 2024 Arweave Asia conference.

The key concept in FusionFi Protocol is Note. It is an abstract representation model of a commitment, which can take the form of tokens, bonds, certificates, contract rights, etc. By using the Note model as a medium, FusionFi Protocol can support a rich variety of financial scenarios, such as trading, lending, and staking.

FusionFi Protocol not only provides a protocol specification but also offers developers a set of development tools for AgentFi (FFP SDK), helping developers create AgentFi more efficiently and simply.

Currently, FusionFi Protocol has two instances: AMM Agent and Orderbook Agent.

AMM Agent

Taking AMM Agent as an example, each AMM Agent can be understood as a liquidity pool of "personal sovereignty," where the market-making rules of this liquidity pool can be set independently. This means that users do not need to rely on external platforms, such as a liquidity pool using a unified market-making algorithm, to autonomously implement swap functions and can seek any suitable counterpart across the network. In other words, when users create an Agent, they are essentially creating a decentralized exchange belonging to themselves. Then, FusionFi Protocol allows many such "personal exchanges" to form a peer-to-peer network for more efficient and flexible matching.

Here are the core processes of the AMM Agent:

| STEP | Explanation | |---------------|------------------------------------------------------------------------| | 1. Create AMM Agent | Create an Agent by calling the createAMMAgent method. The Agent exists as an AO process, and unlike smart contracts, it is controlled by the user. | | 2. Deposit Assets | Users deposit tokens into the AMM Agent to prepare for providing liquidity. | | 3. Add Liquidity | Call the agent.addLiquidity method to add a certain amount of assets to the liquidity pool. | | 4. Automatic Exchange | The AMM Agent uses algorithms (such as the constant product formula) to automatically calculate exchange prices, and market-making rules can be set independently. | | 5. Remove Liquidity | When users need to withdraw funds, they can use the agent.removeLiquidity method to remove liquidity. |

It seems simple, but for LPs, it still appears to be a standard process of creating, depositing, adding, exchanging, and withdrawing. However, the difference is that the Agent is controlled by the user, meaning the assets are in their hands. This is actually the capability of AgentFi itself, and FusionFi establishes a relatively unified entry point (and data structure) for this capability.

You can understand that, as an LP, all you need to do is perform deposit and withdrawal operations by calling a unified entry function. The function itself can link to multiple DeFi projects, and how they interact and operate afterward can be disregarded. This is the value of the protocol standard. It's similar to how applications adapt to users after the establishment of standards like ERC20.

Below is a specific code example for adding liquidity.

You can see that only a few lines of core code are needed to quickly implement this functionality. >

`const minLiquidity = await agent.getMinLiquidityByX(helloAmount, ammSlippageOfPercent)// Set amount and slippage
const addLiquidityMessageId = await agent.addLiquidity(minLiquidity)// Initiate the message to add liquidity
const addLiquidityResult = await getProcessResult(addLiquidityMessageId, ammProcess)// Get the result
`

Code example source: https://github.com/permadao/ffp-demo

Note Lifecycle

Here we can switch to the perspective of Note and take a look at the transaction process between users and AMM Agents.

1. When a user initiates a price inquiry request, all AMM Agents with corresponding liquidity will automatically create a quote, which is a Note. This Note has a very short validity period; if it cannot be executed quickly, it will become invalid. AMM Agents act as makers.
2. All Notes will be centrally stored in the system's Note Pool, which serves as a shared storage space for easy access by other entities.
3. Users select the most suitable quote Note from the Note Pool through the front-end webpage and submit it to the Settlement Center for settlement. The Settlement Center is responsible for executing specific settlement operations, such as swaps.
4. The Note is marked as "settled," and the swap is successfully executed.

Here, the Settlement Center is a key component of the FusionFi Protocol, responsible for handling various Note settlement operations within the system.

The same applies to the Orderbook Agent; the limit orders in the Orderbook Agent are also Notes, and their settlement process is identical to that of the quotes created by the AMM Agent. This means that the FusionFi Protocol can actually integrate liquidity from both AMM and order books.

This integration brings significant benefits. In swap scenarios, liquidity can come from user quotes or market-making nodes. Users can leverage routing protocols to search for liquidity across the entire Note pool to achieve the best execution price. AMM provides basic liquidity to the market but faces issues of significant price impact and impermanent loss, while order books allow users to place orders independently, suitable for large transactions and users with specific price requirements. After integration, AMM provides continuous liquidity, while order books reduce price impact and increase depth, making large transactions more efficient. This model meets the needs of different types of users, allowing both retail and institutional participants to find suitable trading methods, thereby improving capital utilization and further maturing the market.

Multi-Note Atomic Settlement

The above case is limited to settling one Note at a time, but in fact, the FusionFi Protocol can also support settling multiple Notes at once, and this settlement is atomic. All Notes in a single settlement must be completed before the status of the Notes can be changed. Otherwise, the status of all Notes will remain unchanged.

This brings some very useful features:

• Large Order Splitting: Large orders are difficult to be filled by a single counterparty. FFP supports splitting large orders to fully utilize dispersed liquidity.
• Multiple Transactions Merging: Multiple transactions can be merged into a single atomic order. This can enhance transaction speed, which is crucial for high-frequency traders and complex trading scenarios.
• Multi-hop Trading: Multi-hop trading is an extension of the merging function. Suppose in a swap scenario, you want to complete a swap from A to C, but there is no direct path from A to C; however, there is a path from A to B to C. FFP can achieve the merging of A to B and B to C. Moreover, this multi-hop trading is atomic, meaning there won't be a situation where A to B succeeds, but B to C fails.
• Zero-Capital Arbitrage: This is what is known as "making a profit without investment." Essentially, it involves arbitrageurs simultaneously settling two Notes that have an interest rate differential. See the diagram below.

Image source: https://x.com/Permaswap/status/1854212032511512992

Permaswap is the first AgentFi DEX built on the FusionFi Protocol and is currently the most mature DEX in the AO ecosystem. If you're interested, you can experience the above features on Permaswap (aopsn.com).

Settlement Center

Clearly, in the FusionFi Protocol, the Settlement Center is a key component. It processes all Notes based on chronological order, and as long as the AO's SU system is functioning normally, this chronological order can be obtained. Anyone can extract Notes from the Note pool and submit them to the Settlement Center for settlement.

When the volume of processing requests for Notes increases, the Settlement Center can also easily scale through a distributed approach, with multiple settlement processes to share the settlement tasks. The pressure can be calculated based on the Note IDs and distributed to different settlement processes for handling.

Diversified Applications of Notes

The structured format of Notes defined by the FusionFi Protocol has very strong general applicability for various financial services. Therefore, the application methods of Notes are diverse. They can be used not only to represent quotes for spot trading but also for futures trading, contract trading, lending, and other scenarios. Thus, FusionFi can integrate not just liquidity but also various financial forms.

Outlook

In the author's view, the essence of this internet world is multi-point transactions. Therefore, solving high-frequency trading among multiple groups holds significant value, and the AgentFi model can cover almost all DeFi scenarios, while the FusionFi Protocol enables more efficient peer-to-peer matching between Agents, and this matching is cross-protocol. In the face of the DeFi field's competition for liquidity as the primary competitive method, and the model of monopolizing liquidity as a profit-making method, the changes that the FusionFi Protocol can bring are revolutionary!

Of course, the FusionFi Protocol is a brand-new protocol standard that may need to be continuously adjusted and optimized based on business needs. This can refer to the models of BIP (Bitcoin Improvement Proposal) and EIP (Ethereum Improvement Proposals), absorbing ideas through co-creation.

References:

Smart Finance: From AgentFi to FusionFi

https://x.com/perma_daoCN/status/1801474305597050906

FusionFi Protocol: Core Element for Achieving AgentFi Interoperability

https://x.com/Permaswap/status/1854212032511512992

FusionFi Protocol Documentation

https://github.com/zyjblockchain/ffp-doc/blob/main/doc/FusionFiProtocol Introduction.md