This article will introduce the “Programmable Privacy” feature that provides more advanced transactions and a cross-chain, more open and fairer MEV market design -SUAVE. Before getting into the main topic of explaining SUAVE, please first understand the concept of Intent.

Intent

Current experience using blockchain transactions

Taking Ethereum transactions as an example, assuming a user wants to exchange his USDT for ETH, he may go to the Uniswap web page to check the price, and after setting the allowed price slip, sign and send the transaction, and then wait for the transaction result.

His transaction will probably look like this: “I sign and send this transaction, with a Nonce value of 23 and a gas fee of 30 Gwei. It will execute the Uniswap contract to swap my 1000 USDT for 0.5 ETH, with a maximum slippage of 1%.”

△ Nonce? Gwei? Image source:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Suppose Alice is a novice user, and she just wants to exchange her USDT for ETH, but she has to cross many thresholds to fulfill this small wish:

• The first is to find the exchange channel. Suppose she Googles and finds the Uniswap page (at least there is a clear digital asset menu and Swap button), and then she needs to understand and set the slippage (or use the default).
• After clicking the Swap button, the transaction signature screen pops up, which contains the Nonce and Gwei of the handling fee.
• Finally she sends the transaction, but probably nothing happens and Alice can only wait in confusion and pray that the transaction will be executed successfully.

Each level is a question that novice users don’t actually need to understand but are forced to make a choice: Where to redeem? Do you want to set a slippage? What percentage should be set for slippage? Do you want to adjust the gas fee (handling fee)? How many Gwei does it need to be adjusted to? Why did the transaction fail? Why is the transaction stuck there for so long (maybe it’s a problem with the Nonce or the handling fee)? What should I do?

Intent transaction usage experience

Unlike Transaction, which requires specifying various details of a transaction, Intent only requires the user to specify the results he wants to achieve and the conditions for execution, and leave the rest to more professional people.

In the Intent, Alice specified that 1000 USDT should be exchanged for 0.5 ETH, but considering the handling fee, the price was adjusted to 0.495 ETH, and then the order was signed and sent. Alice’s transaction will look like this: “I sign and send this order. I want to exchange 1000 USDT for 0.495 ETH. This order is valid as long as I can get 0.495 ETH.”

It’s very simple, right? This is the experience of using a limit order (Limit Order), and it is also the general experience of using DEX Aggregators (such as 1inch and Tokenlon).

△ The difference between Transaction (top) and Intent (bottom). With Intent, users only need to specify the conditions and do not need to worry about how to achieve them. Caption:https://www.paradigm.xyz/2023/06/intents

Through Intent, users no longer need to deal with and worry about various tedious and confusing details between the generation, signing, and execution of transactions. They don’t even need to figure out the problem and continue to try when a transaction fails. Moreover, different chains will have different transaction processes and pitfalls!

Through Intent, the user only needs to specify the execution conditions and expected results of his Intent. The rest is for the professional Solver to realize the user’s Intent – how to send transactions, monitor transactions, accelerate transactions, etc. Handling troublesome issues such as transaction failure, and Intent can only be implemented when the execution conditions and expected results are met, so users do not have to worry about whether an accident will cause assets to disappear.

Intent will greatly enhance the blockchain experience.

Reading Tip 1: In fact, there are already many examples of using Intent, such as the signature of a multi-signature wallet, the concept of Session Key that grants a third party specific execution permissions and time limits, or a batch matching transaction mechanism such as CowSwap. Even in the Web2 world, there are traces of Intent, such as search engines (I enter what I want to query, and the search engine finds relevant information for me through various channels) or e-commerce online shooting (I enter what I want to buy) Something, the e-commerce company found it through various channels and delivered it to me). It’s just that the word Intent has only recently become popular in the Web3 world.

Reading tip 2: In English, the word Imperative (“imperative”) is used to describe the experience of using Transaction, which is to issue a complete command to complete the goal; while the word “Declarative” (“Statement”) is used to describe the experience of using Intent. Descriptive, indicating that it is used by stating execution conditions and execution results.

Intent in the cross-chain world

In cross-chain applications such as cross-chain bridges and cross-chain DEX, because two or more chains are involved, users have to deal with more transactions on different chains.

Excluding cross-chain applications through the project party’s multi-signature, it can provide a better user experience (for example, after the user sends a transaction on the source chain, the project party’s multi-signature will automatically send the assets to the user on the target chain) The specified address does not require the user to perform any operations on the target chain). Other more decentralized cross-chain applications such as Nomad and Succinct do not have such a good experience. Users may need to send transactions to the target chain to complete the operation.

Therefore, the improvement of user experience that Intent can bring is even more important and urgent in the cross-chain world.

Through Intent, cross-chain operations will only require users to sign, and they no longer have to worry about the transaction rules and details of each chain. Users will be able to operate different chains with the same user experience, and will not even perceive the fact that there are different chains.

SUAVE

The full name of SUAVE is Single Unifying Auction for Value Expression, the purpose is to become a unified MEV market across multiple chains. In this market, users can express the closing conditions and rewards of a transaction in an efficient way. At the same time, executors (Executors) will compete with each other, and Will cooperate efficiently to complete user requests.

SUAVE can serve as a transaction pool for a blockchain and also act as a Builder role responsible for producing block content of that blockchain. However, SUAVE is not intended to replace the existing transaction pool and Builder functionality of a blockchain, but rather to seamlessly connect to an existing blockchain in a plug and play manner.

After SUAVE is connected to a blockchain, the blockchain is equivalent to having a decentralized, very professional and powerful Builder that spans multiple blockchain transaction sources. Having multiple blockchain transaction sources at the same time will provide huge advantages in the cross-domain MEV market that will gradually grow in the future. Builders with this advantage will be more competitive than builders operating on a single chain.

From Flashbot to MEV-Boost to SUAVE

From Flashbot to MEV-Boost, the spirit they uphold is to acknowledge the existence of MEV and strive to bring hidden economic activities to the forefront. They aim to establish a public market where anyone can participate, in order to avoid the scenario where a few individuals silently control and dominate this immense economic interest, gradually leading to the concentration of resources in their hands and ultimately impacting the decentralization and security of the entire blockchain network.

But as people learn more and more about MEV, they gradually realize that in addition to the mature MEV market on Ethereum, there are also cross-chain and cross-border MEV markets. This cross-border MEV market will be much larger than Ethereum’s, and cross-chain transactions will have more opportunities to extract MEV than transactions on the same chain.

If there had not been someone like Flashbot to expose the cross-chain MEV market, bring it to light, and enable fair participation for everyone, the few individuals who exploit cross-chain MEV would have even more advantage, ultimately affecting the security of the entire blockchain network.

Another phenomenon that will affect centralization and security is Private Order Flow: users’ transactions no longer flow to the public transaction pool, but directly to the Searcher or Builder. Private Order Flow may come from Searcher or Builder purchasing the right to earn income from users’ transactions, or Builder providing attractive services, such as (1) free cancellation of transactions or DEX orders sent by users, or (2) providing Pre-Confirmation , before the transaction is received, the user is assured how quickly the transaction will be received, so that the user does not need to worry about whether the transaction will be received and how long it will take to be received.

While Private Order Flow may initially benefit users, in the long run, it will result in centralization. Searchers/Builders with Private Order Flow will have a competitive advantage and gain more benefits compared to those without it, leading to a detrimental impact on competition. Additionally, since there is no incentive for sharing Private Order Flow with new Searchers/Builders, these newcomers will be at a disadvantage when starting the game.

Why do the blocks from the user’s transactions to the Bundle created by Searcher have to be collected through Private Order Flow? This is because the transaction and Bundle contents are public and unencrypted. If they are seen and obtained by others, it can lead to harm for the user or the Searcher. For example, others can extract the MEV of the user’s transaction through a pincer attack or dismantle the Bundle, snatching away the MEV. This is why both users and Searchers currently have to trust the Builder, as they need to hand over the original content of the transaction and Bundle to the Builder and trust that the Builder will not cause any harm.

The emergence of SUAVE is to solve the centralization risks caused by cross-border MEV and Private Order Flow.

First, by establishing a public market that serves cross-chain MEV, users or Searchers can express their income conditions for transactions or bundles in this market. For example, if a user has two transactions that need to be routed to Ethereum and Arbitrum respectively, and both transactions must be included and executed before a certain time, they can specify these conditions in the market. The Executors in the market (which can be Searchers or Builders) will compete to fulfill these requests in order to earn rewards. But how can users or Searchers trust throwing their transactions or bundles into this public market? This is where privacy technology comes in. By encrypting the transactions, users or Searchers no longer need to worry about potential harm caused by others viewing their transactions. Only with transaction privacy can an Open Order Flow be possible.

SUAVE further proposes the concept of Programmable Privacy, whereby users or searchers can choose whether to disclose specific parts of transactions or bundle contents (such as the contract address of transaction execution) instead of being limited to choosing between complete encryption or no encryption.

Compared to completely encrypted transactions, transactions that disclose specific information can be incorporated into bundles or blocks more effectively and quickly, and even receive kickbacks, as detailed in the fourth article’s MEV-Share section. By disclosing specific information, Searchers can even collaborate with each other. Searcher B can build on top of Searcher A’s bundle: Searcher A’s bundle follows the user’s transaction for arbitrage, and Searcher B’s bundle follows Searcher A’s bundle for arbitrage. Privacy is essential for an open order flow. Privacy enables Searchers to have the opportunity to cooperate with each other, benefiting each other rather than competing for MEV opportunities.

Other benefits of SUAVE

• Through SUAVE, cross-chain DEX transactions can obtain better prices, and cross-chain Intents can be executed more efficiently.
• If SUAVE is regarded as a huge but decentralized Builder, it will have more advantages than a centralized Builder because it gathers more Order Flows, which can also attract more Builders to join SUAVE, and can further Reduce the risks caused by Builder centralization.
• Through SUAVE, each chain does not have to build its own private transaction pool and its own chain’s MEV market, and can focus its resources and energy on solving other problems or providing better services.

SUAVE architecture

Bulletin Board for User Preference

SUAVE can be described as a “User Preference bulletin board”. The term “User” here does not necessarily refer to general blockchain users, but Searchers can also be Users of SUAVE. In the following, “User” will refer to general blockchain users, and “SUAVE User” will refer to users of SUAVE.

SUAVE’s User Preference is like a specialized Intent that focuses on transaction sorting. It is not like the general Intents that readers may see elsewhere, which can specify various conditions. Similar to how users specify preferences and conditions in Intents, in Preference, SUAVE Users specify preferences or conditions for “transactions or bundle income entering the block,” such as:

• “I want my transaction to be sorted before the 0xabcd transaction and be included before block 110050.” In fact, it is just like the conditions specified by the Bundle of Searcher when using Flashbot.
• “I want my Bundle to be included and bring me 0.05 ETH in revenue.”
• “I want Intent A and Intent B to be included in block 1001 of chain X and block 50900 of chain Y respectively.” \

Reading tip: Users can also send general blockchain transactions (without specifying any Preference) to SUAVE, that is, simply use SUAVE as a general trading pool or Flashbot, such as directly sending his ETH transfer transactions or Uniswap transactions to SUAVE that.

Of course, if you just specify conditions, there is no need to design a new architecture to do this, just use the original Flashbot. So in fact, the Preferences specified in SUAVE must be matched with rewards, otherwise no one will be willing to complete your Preferences unconditionally. Of course, the prerequisite for payment must be that the Preferences have been achieved.

By making Preference designation and rewards into smart contracts to be fulfilled, demand parties (such as users or Searchers) will be able to put forward more detailed and diverse Preference requirements, and these requirements are met by economic incentives rather than Rely on the kindness of the Builder.

• “I want my transaction to be sorted before the 0xabcd transaction and be included before block 110050. If it is achieved, I will give you 3 ETH.”
• “I want my Bundle to be included and bring me 0.05 ETH in income. If it is achieved, I will give you 0.02 ETH.”
• “I want Intent A and Intent B to be included in the 1001st block of chain X and the 50900th block of chain Y respectively. If this is achieved, I will give you 1.8 ETH”。

Architecture

SUAVE can be viewed as consisting of three components: Preference Environment, Execution Market and Decentralized Block Building.

• The Preference Environment is a place that accommodates User Preferences and rewards from various chains, including the SUAVE chain and its transaction pool. SUAVE User may be a general user or Searcher.
• The Execution Market is a group of professional Executors who find and execute User Preferences (executing User Preferences by packaging them into Bundles) to earn rewards. Executor may be Searcher or Builder
• Decentralized Block Building is the process of assembling multiple Bundles into blocks for one or more chains.

△ The PE on the left gathers Intents and arbitrage transactions on various chains, and then the Executors in the middle try to satisfy these Preferences and package them into Bundles, and hand these Bundles to the role on the right that has the right to produce blocks to assemble the blocks. Image source:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE will have its own chain and transaction pool. SUAVE calls the chain Settlement Layer and the transaction pool Messaging Layer.

Smart contracts can be deployed on the chain to establish contracts between Preference and rewards. The transaction pool will be filled with transactions in which SUAVE User declares Preference and Executor receives rewards.

The life cycle of a SUAVE transaction

1. Preference Expression: SUAVE User specifies Preference and bids for one or more of his Intents/Transactions.
2. Execution Optimization: Executor finds an execution path that satisfies User Preference, and can even find the optimal path for it.
3. Preference Settlement: The Executor’s Bundle(s) are successfully included in the block of the target chain and meet the Preference specified by SUAVE User.
4. Payment Settlement: Oracle returns the target chain status to the SUAVE Chain, and the Executor executes the smart contract. After the contract confirms that the Preference has been satisfied, the SUAVE User reward is given to the Executor.

△ Preference four steps from establishment to execution to settlement. Image source:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE needs to be able to write Preference in a programming language and convert it into a smart contract in order to fulfill the contract between SUAVE User and Executor. SUAVE is expected to design a MEV-specific EVM based on EVM - MEVM.

MEVM will add a new Precompile contract and transaction type specifically for MEV. User Preference, Packaging Bundle, and Block Building functions can all be easily completed in MEVM.

The sample program code in the figure below writes the Effective Gas Price (EGP) Block Building algorithm using Solidity and MEVM Precompile contracts.

EGP Block Building sorts the Bundles according to the Gas Price given by each Bundle. Bundles with higher Gas Price will be ranked at the front of the block:

△ The pink function in the picture is the Precompile function of MEVM, which is specially designed for MEV use. Image source:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Reading tip: The execution of the Block Building algorithm does not actually occur on the SUAVE Chain chain, but the Block Builder simulates the execution off the chain (just like the node will simulate the execution of a transaction locally), so this execution process It will not really become a transaction that occupies the block space and computing resources of SUAVE Chain, nor will it be limited by the output performance of SUAVE Chain.

Through the composability of the EVM contract, Searcher and Searcher or Searcher and Builder will be able to cooperate through contracts, replacing the original one-sided trust relationship. Cooperation will also further improve Bundle efficiency and extract more MEV , which can benefit every participant in the MEV supply chain. In addition, participants can directly use EVM-based development tools and infrastructure, such as RPC Provider, testing tools such as Foundry, etc., and the development experience will be very good.

Moreover, MEVM will provide the function of transaction privacy, because without privacy, there is no possibility of cooperation. Without privacy, Searchers have to worry about their MEV being stolen. In the early stage, this privacy will be achieved through trusted hardware SGX. The transaction will be encrypted and then sent to SGX for execution. It is believed that SGX will execute its designated program code without stealing MEV at will. In the future, when other advanced cryptographic technologies gradually mature, cryptography can be used to replace trusted hardware. For more details, please refer to the previous article on Encrypted Mempools.

Reading tip: However, there are also disadvantages based on EVM, such as EVM is too Expressive: In fact, to write the functions required by MEV, you do not need many Opcodes in EVM. Allowing the use of these Opcodes may allow people who are willing to write very complex executions. , and then let the transaction fail at the end of execution, causing the node to waste a bunch of computing resources, which is a DoS attack. The Anoma project redesigns a programming language and execution environment specifically for expressing and executing Intents. In the future, SUAVE may also use Anoma’s architecture to replace MEVM.

Plug-N-Play SUAVE

If the block developer or Validator of a chain knows the existence of SUAVE and intends to use SUAVE, then it will regard SUAVE as a Block Builder. If SUAVE provides a higher bidding price for the blocks it builds, then Miners or Validators will use SUAVE’s blocks. Taking the current MEV-Boost on Ethereum as an example, the blocks composed by SUAVE will be converted into a format that complies with the MEV-Boost bidding mechanism through the plug-in provided by SUAVE. The Proposer does not need to make any changes in order to adopt SUAVE’s blocks.

If the block developer or Validator of a chain does not know the existence of SUAVE, then SUAVE’s Executor will bid to receive its Bundle through the chain’s fee rules.

Challenges of cross-chain MEV

Each chain has its own block developer and validator. The block B1 of SUAVE being received by the X chain does not mean that the block B2 will also be successfully received by the Validator of the Y chain. The block production mechanisms and markets of the X chain and the Y chain are independent. Unless both X chain and Y chain use Shared Sequencer, and the same Sequencer produces blocks for both chains at the same time, then only by combining SUAVE can we ensure Atomic Inclusion: the two chains must not “collect specified transactions (or blocks) together”. Yuan)”, or “no income at all”.

And even if Shared Sequencer can ensure Atomic Inclusion, it does not mean that the transaction will be “successfully” executed after being included. If both transactions are not executed “successfully”, it means that cross-chain MEV has failed. Assuming that a SUAVE User wants to complete a cross-chain arbitrage, transactions on both chains must be generated in real time and executed successfully before he can benefit：

• If the SUAVE User is not willing to bear the risk of transaction execution failure, then his Preference will require that both transactions must be successfully executed before they are completed, and then the Executor will be paid and the Executor will bear the risk. He can constrain the “result of successful execution” by specifying the status on the chain, for example, specifying that a contract must emit a specific Event, or specifying how much the token balance of a certain address must be greater than. Next, the Executor who is willing to take risks will try to make both transactions real-time and successfully executed. If only one of them ends up being received or the execution of one of the transactions “fails”, the Executor will not get the reward.
• If the SUAVE User is willing to take risks, then his Preference may only require that both transactions are received, and it is also fine if the transaction execution fails (that is, transaction Revert). The Executor will still try its best to execute both transactions successfully (successful execution may result in a higher reward), but as long as there is income, you can get the reward.

Taking the picture below as an example, SUAVE User wants to perform cross-chain transaction arbitrage between Rollup 1 and Rollup 2: buy one ETH at a lower price on Rollup 1, and sell one ETH at a higher price on Rollup 2. .

If both trades are paid in real time and executed successfully, the SUAVE User can earn the price difference. Scenario 1 and 2 in the table in the picture are “SUAVE User is willing to bear the risk himself” and “Executor is willing to bear the risk” respectively.

The bottom three columns of the table are “rewards for both successes”, “rewards for only one success” and “final result for only one success”:

• Rewards for both successful transactions (SUAVE User earns the price difference):
  • Scenario 1: SUAVE User pays $50 handling fee to Executor.
  • Scenario 2: SUAVE User pays a $70 handling fee to the Executor (more expensive because the Executor bears the risk).
• There is only one reward for success (SUAVE User did not earn the spread):
  • Scenario 1: SUAVE User pays $25 handling fee to Executor. SUAVE Users absorb the risks themselves.
  • Scenario 2: SUAVE User does not have to pay fees or take risks.
• There is only one successful result (SUAVE User did not earn the spread):
  • Scenario 1: SUAVE User pays a $25 handling fee to Executor and has an extra ETH in hand.
  • Scenario 2: SUAVE User does not have to pay handling fees to the Executor and will not have an extra ETH on hand. And Executor has one more ETH in his hand.

△ Different execution results under different situations. Image source:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

Cross-chain MEV requires Executors to have capital, be willing to take risks, and have sufficient technology to ensure real-time, Atomic revenue and successful execution. This can be a lucrative but relatively high-barrier job.

Why does SUAVE need its own chain?

Why can’t we simply transfer and share Preferences through the P2P network? Because a pure P2P network cannot prevent the network from being filled with countless Preferences (i.e. DoS attacks). If it is a chain, DoS attacks can be prevented through handling fees.

Why doesn’t SUAVE use the existing chain? Because SUAVE needs its own (MEV) function and its own chain settings such as block time and block size. If you build it directly on Ethereum, you will encounter problems such as too high cost, too long block time, and limited functions.

In addition, because SUAVE needs to obtain information from other chains to verify whether the Preference is satisfied, an independent SUAVE Chain can maintain neutrality by gathering information from all other chains.

However, SUAVE has its own chain, which also means that (1) SUAVE User may need to transfer assets from other chains to SUAVE Chain to use SUAVE, and (2) SUAVE needs to rely on Oracle to report information from other chains. This means that SUAVE itself has an additional trust requirement for Oracle. If Oracle is insecure, it will affect the security of the contract on SUAVE.

Reading tip: There are not many details yet about whether SUAVE will have its own token, whether assets need to be transferred to the SUAVE Chain for use, or how to transfer to the SUAVE Chain. It is only mentioned in the video and article “ SUAVE User must first transfer assets from other chains to SUAVE Chain before they can use it.”

The design and security model of SUAVE Chain itself are still under discussion. If SUAVE Chain is a Rollup on Ethereum, then you can directly use the Rollup’s own mechanism to transfer assets and read other Rollup information. This will be better than relying on other rollups. Cross-chain technology and Oracle services bring a lot of security.

If the Validator of the SUAVE Chain can be combined with Eigenlayer, it will be safer and more reliable to directly use the Ethereum Validator as the SUAVE Chain Validator than to generate a set of Validators by SUAVE itself. But of course, these designs also have corresponding shortcomings. For more discussion about SUAVE Chain design, please refer to this article.

Summary of SUAVE’s challenges

• SUAVE Chain block time: The block time of SUAVE Chain needs to be short enough for the SUAVE User to declare its Preference for the Executor to see. If the SUAVE Chain time is longer than the chain it is connected to (such as Solana or other Rollup), it is easy for the SUAVE User to not have time to let the SUAVE Executor know that he wants the transaction to be included in the next block of a certain chain. A block has been produced.
• Oracle risk: Oracle is responsible for providing information on other chains, and may also be responsible for transferring SUAVE User’s assets to SUAVE Chain, so the importance of Oracle is no small matter.
• Cross-chain usage experience: SUAVE User needs to transfer assets to SUAVE Chain which is also a shortcoming in usage experience.
• Economic model: Does SUAVE need to issue its own assets, how to incentivize SUAVE Validator, how to prevent SUAVE’s economic incentive mechanism from affecting the economic security of other chains, etc.
• Privacy technology: In the short term, SUAVE will have to rely on trusted hardware such as SGX to provide transaction privacy functions, but in the long term it will have to switch to a more decentralized and secure approach to reduce risks.
• Appropriate Preference Language: Is EVM suitable as a means of expressing and executing Preferences?

Summary and highlights

• The emergence of SUAVE is to (1) address the centralization risk caused by the difference in advantages of Builders that can result from Cross Domain MEV, and (2) open the door for collaboration between Searchers / Builders through the introduction of programmable privacy, reducing the centralization risk that may arise from Private Order Flow.
• Fully private transactions make the work of Searchers difficult, as they cannot effectively Back-Run user transactions, which leads to decreased on-chain efficiency. However, users do not have to choose between “privacy” and “efficiency.” Instead, they can use programmable privacy to choose to disclose partial information, making the work of Searchers easier and improving on-chain efficiency and Back-run rewards.
• With SUAVE, SUAVE Users can specify their Intent/transactions’ preferences and various conditions, while the rest is handled by professional Executors to achieve the conditions and claim the rewards promised by SUAVE Users upon fulfillment.
• SUAVE will have its own chain because pure P2P cannot prevent DoS attacks, and SUAVE will have its own unique features and settings for the chain (MEV), so the existing chains cannot be directly used. This chain will be based on an EVM modification, adding the necessary functionalities for MEV, called MEVM.
• Cross-chain MEV is a highly challenging operation, as it requires ensuring Atomic Inclusion and guaranteeing “successful execution” of transactions. SUAVE Users can specify states to require that transactions must be executed successfully before rewarding the Executor, thereby transferring the risk to the Executor. The Shared Sequencer can ensure Atomic Inclusion but does not guarantee that transactions will be executed “successfully.”
• SUAVE being its own chain also means that SUAVE Users need to transfer assets to the SUAVE Chain before they can use SUAVE. Moreover, a secure Oracle is required to report information from other chains to the SUAVE Chain for verifying whether the Preferences are satisfied.
• SUAVE still faces many technical and design challenges, such as secure Oracle, secure privacy techniques, Preference language, and economic models, among others.

Disclaimer：

1. This article is reprinted from [ imToken Labs]. All copyrights belong to the original author [Nic]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.