# Welcome
# The Urani App {% hint style="info" %} Soon. {% endhint %} # MEV Projects At Urani, we are experimenting with **DeFi gamification** and **toxic-MEV minimization**. Here are some of our long-term R\&D projects, beyond the [**Urani App**](/urani-app/urani-app)**:** ➡ [**Urani Protocol**](/urani-protocol/urani-protocol-overview) is an onchain-agnostic orderbook conducting batch competitions among agents for the largest surplus and efficiency. The protocol provides various strategies to ensure fairness and meritocracy. At a high level, the protocol: * 1️⃣ Collects order intents. * 2️⃣ Places them into batches. * 3️⃣ Assigns the batches to operators. * 4️⃣ Ranks the solutions from each agent for the largest surplus, efficiency, and ingenuity. * 5️⃣ Ensures the orders from the winning solutions are settled. * 6️⃣ Rewards operators and users from internalized MEV. The protocol provides various strategies to ensure operators from all backgrounds have opportunities to succeed, promoting accessibility and meritocracy. ➡ [**MEV Agent templates**](/mev-agents/agents) are open-source algorithms (bots) for the Urani protocol, allowing hackers to plug in their private strategies and start playing our MEV games. Advanced strategies and AI-centric agents are continuously researched and developed in our labs. Additionally, we have in-house agents for gauging and fallback mechanisms. ➡ [**Urani Swap**](/urani-swap/overview) is the interface and SDK facilitating the submission of order intents for consumption by the Urani Protocol, supporting usage by both retail users and other protocols. ➡ [**Urani Arena**](/urani-arena/urani-arena-overview)[ ](/urani-arena/urani-arena-overview)is a *real-time* visual infrastructure for orderflow auction competition and peer-to-peer matches, designed to commoditize MEV agents and engage their fans. {% hint style="info" %} In the next sections, we dive into the technical details of each of these projects. {% endhint %} # Swap tl; dr [**Urani Swap**](https://urani.ag/) is a feature within the [**Urani App**](https://www.urani.app/) serving as both an interface and SDK, enabling users and other protocols to submit order intents for processing within the [**Urani Protocol**.](/urani-protocol/urani-protocol-overview)

Urani Swap v1.

Leveraging [**state-of-the-art MEV and price discovery research**](https://github.com/urani-labs/solana-mev-literature), users swapping on Urani can gain access to competitive asset prices (we call it a [**multidimensional price free market**](/urani-protocol/technical-considerations/multidimensional-market)), all while being shielded from [**toxic-MEV**](/urani-swap/technical-considerations/mev-on-solana). {% hint style="info" %} Currently, the Swap is designed for the Solana blockchain. Later versions of the Protocol should include support for other blockchains. {% endhint %} # Technicals # MEV tl; dr MEV refers to the "Maximum Extractable Value", [**an economic phenomenon**](https://arxiv.org/abs/1904.05234) representing profit opportunities arising from on-chain transactions. For example, a large swap on a DEX can cause token prices in a pool to fluctuate. Traders might explore the price difference in another pool to generate a positive surplus, and such arbitrage opportunities are considered MEV. In general, arbitrage is an example of healthy MEV, as **finding better quotes is vital in a free market and benefits the end user.** On the other hand, toxic MEV can be detrimental. For example, users may unknowingly trade with high slippage and **fall victim to sandwich attacks.**
{% hint style="info" %} You can find more resources about MEV [**here**](https://www.urani.trade/mev). {% endhint %} *** ## Case Study: Toxic-MEV on Solana [**We have seen an explosion of toxic-MEV on Solana**](https://sandwiched.me/), including sandwichers, backrunners, and snipers (bots that congest the network by abusing spam techniques).
On Solana, block building is a continuous high-speed process with no in-protocol mempool. After Jito deprecated its out-of-protocol mempool in early 2024 (which slowed down transaction processing by 200ms and allowed typical MEV attacks and transaction ordering), attackers now have to be close to validators or RPC nodes (side-dealing) to receive the most accurate state of the network while also observing incoming user transactions. This created new dynamics in the MEV space. Another approach, MEV-protective RPCs, uses various mechanisms (e.g., routing via private mempools or back-running user transactions to return the MEV to users) to minimize toxic-MEV. These out-of-app services create unwanted external dependencies and require users to switch to appropriate RPCs manually. Additionally, although initiatives such as [**the QUIC protocol, Stake QoS, or priority fees** ](https://github.com/urani-trade/solana-mev-literature/blob/main/1_Solana.md#5%EF%B8%8F%E2%83%A3-quic-network-layer)could help mitigate the problem, incentives for bots will always remain as long as MEV opportunities exist. At the application layer, Jupiter, the leading aggregator on Solana, has a few initiatives to help reduce MEV attack vectors for its users: 1. Splitting orders into smaller sizes and statistically optimizing slippage. 2. Providing the option for users to automatically add a Jito tip to their transactions, which will route transactions via Jito bundles directly to validators, as opposed to public RPCs that can potentially leak information to searchers. However, these solutions are not comprehensive, as users have to trust that validators act honestly and are not side-dealing with searchers. Adding Jito tips is an additional cost imposed on users. Although the minimum Jito tip is only $0.00015, assuming $150/SOL, the average tip is around $8.80, which can quickly add up. {% hint style="info" %} Currently, [**Jito MEV tips**](https://explorer.jito.wtf/) are a good way to estimate Solana MEV activity (toxic or non-toxic), which shows that agents are willing to pay extra to validators to prioritize their transactions. For sandwich attacks, [**sandwiched.me**](https://sandwiched.me/) is a good source. {% endhint %} *** ## **Urani's Approach** Urani addresses the toxic-MEV minimization issue at the application layer by:
Additionally, **we coined the term "MEV agents" to distinguish "good" bots from toxic MEV bots**. We refer to the humans behind these bots as "MEV agent operators." At Urani, they are as important as any other actor in the supply chain. # Urani's Intents Intents are a type of orderflow auction mechanism employed in decentralized finance to help mitigate the negative externalities associated with [**MEV toxicities**](/urani-swap/technical-considerations/mev-on-solana), such as high slippage from sandwich attacks. They represent what a user wants to achieve when interacting with a protocol and can incentivize a healthy free market, allowing users to capture the value they create. *** ## How Urani's Intents Work At Urani, an intent is a piece of data binding programmatic commitments to a user's request. It specifies **the asset pair**, **amount to trade**, **and expiration, among other** things. This data initially appears as `JSON`, but internally, it's converted to Solana's native data types ([**PDAs**](https://github.com/urani-labs/solana-dev-onboarding-rs/blob/main/chapters/05_pda.md)). Moreover, users submit a signed "intent to trade" message instead of directly submitting a trade, allowing the Urani Protocol to execute the trade on the user's behalf. The Urani Protocol then aggregates these intents into discrete [**batch auctions** ](/urani-swap/technical-considerations/batch-auctions)(rather than processing orders on a first-come, first-served basis - [**the native method Solana uses to process transactions**](/urani-protocol/technical-considerations/multidimensional-market/on-solana/solana-transactions-overview)), and assigns them to [**MEV Agents**](https://docs.urani.ag/urani-swap/technical-considerations/mev-agent-operators). Once the batch period ends, the optimal execution for each order is settled on-chain. {% hint style="info" %} More details on submitting an intent to the Urani Protocol are available [**here**](/urani-swap/technical-considerations/uranis-intent-specs). {% endhint %} *** ## Benefits of Urani's Intents * [x] ***Lower transaction costs and fewer failed transactions***: Intents can‌ reduce fees and transaction costs by processing transactions in batches. * [x] ***Less network congestion:*** Batches are not only protected from sniping bots but can also be matched directly. * [x] ***Improved price discovery***: Order batches facilitate better price discovery since MEV agents are competing for the best execution prices. * [x] ***Less backrunning:*** Optimal trade paths are chosen by design. * [x] ***Fairness***: Intents can promote a more equitable trading environment, mitigating the advantages of participants with information asymmetry. * [x] ***Enhanced/deep liquidity***: Intents allow order fulfillment from a large amount of liquidity sources. Plus, safer trades for low-cap illiquid tokens. * [x] ***Possibility for P2P and ring matches:*** Once the system reaches network effects, these types of matches bring, by design, the best quote possible since there are zero swap fees or slippage. *** ## Urani's Intents vs. "Request for Quotes" (RFQ) In traditional finance, [**RFQ is a method used to trade securities**](https://www.investopedia.com/terms/r/request-for-quote.asp), particularly in over-the-counter (OTC) markets like bonds, currencies, and derivatives. When a trader wants to buy or sell an asset, they can send an RFQ to multiple dealers or market makers to get quotes for the desired transaction. Here is a high-level explanation of how RQFs work: 1️⃣ The investor specifies the details of the trade they want to execute (e.g., the type and quantity of the asset they want to buy or sell, and any specific terms or conditions). 2️⃣ The RFQ is sent to selected dealers or market makers, who respond with quotes that include the price at which they're willing to buy (bid) or sell (ask) the asset, trade size, and expiration time. 3️⃣ The investor reviews the quotes and decides which one to accept, negotiate further, or decline. Although RFQs and intents operate similarly and are often interchangeable, Urani's intent model differs fundamentally in its direction, democratization of surplus, and focus on the **MEV agents** (and yes, Urani's intents have some resemblances to [**CoW's**](https://www.skatersvscows.fun/) [**coincidence of wants**](https://cow.fi/)). # Intent Transaction Flow In the context of the Urani protocol, the intent transaction flow refers to the structured process by which user-initiated transactions are prepared, submitted, and eventually fulfilled. *** ## Intents on Solana

A high-level overview of how a limit order is processed within Urani's intent paradigm.

*** ### Durable Nonce A durable nonce is a mechanism in Solana that ensures a transaction remains valid even if it is processed later. Transactions typically rely on a recent block hash to prevent double spending and ensure timely processing. However, a durable nonce replaces the blockhash for transactions that must remain valid for an extended period. This nonce is a value stored in a dedicated account, and it gets updated each time the nonce is used in a transaction. *** ### PDAs Program-derived Addresses (PDAs) are a fundamental component of Solana's architecture. They allow programs to generate addresses deterministically based on specific inputs, ensuring consistent and predictable account addresses without managing private keys. PDAs are particularly useful for creating accounts tied to a program's logic. Urani leverages PDAs to store intent data in a Solana-native data structure. Additionally, the Urani Protocol needs to call other programs to find the best match and fulfill the transaction. PDAs are essential to such CPIs (Cross-Program Invocations). Using PDAs, the Urani protocol can effectively manage the data and the flow to accommodate the protocol's needs. *** ### Signatures After the transaction is crafted with the necessary data and with both the nonce and PDA added, we need to add the signatures so the funds can be moved appropriately. In Urani's context, the Nonce Authority signs for the transaction behind the scenes, but we also need to ask for the user's signature with their wallet to allow for the transaction to be completed. The user gets a popup being asked to sign for the signature. Once the signature is approved, we can submit this transaction to the protocol. *** ### Protocol Submission To summarize, here is what happens when the user submits an intent, selecting the tokens and the respective amounts: 1. **Crafting the transaction:** Combining all necessary components, including durable nonces and PDAs, to form a valid transaction. 2. **Signing the transaction:** Ensuring the transaction is properly signed by the necessary parties (especially the user). 3. **Submitting the transaction:** Sending the signed transaction to the Urani for batching, matching, and fulfillment. # Batch Auctions

High-level explanation on how the Urani Protocol could bring great price discovery to users.

The Urani protocol is designed to delegate the price-finding routing optimization problem to **MEV agent operators** as securely and efficiently as possible. In this setup, batches are auctioned off through a [**competition**](/urani-arena/technical-considerations/the-pvp-competition) among agents to find the largest surplus for each order. Everyone in the batch also receives the same price — eliminating sandwiches or other types of MEV. *** ## How a Batch Solution Looks Like 
{
        "orders": [
            {
                "intentId": 77448,
                "srcToken": "9wFF5VMevWxK7EaSg9dLSkY8jZAGs8R4DQ9K9X5Jd2ac",
                "srcAddress": "0ddb0a23e291b4aeb4c031d91ebf7fdea086eff5",
                "srcAmount": 8714,
                "dstToken": "2oNdfRRVxxYE8wRz5xZdqhfv6MFqjVcMkeVusQPh24dP",
                "dstAddress": "0ddb0a23e291b4aeb4c031d91ebf7fdea086eff5",
                "minReceived": 1704,
                "expiration": 1718034091,
                "status": "filled"
            },
            (...)
        ],
        "status": "filled",
        "fillData": {
                "tx": "mocktx123",
                "agentName": "Agent Bet",
                "route": [
                    {
                        "venueName": "Raydium Liquidity Pool AMM",
                        "venueAddress": "5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h",
                        "venueImage": "https://statics.solscan.io/ex-img/5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h.png",
                        "sentToken": "9wFF5VMevWxK7EaSg9dLSkY8jZAGs8R4DQ9K9X5Jd2ac",
                        "sentAmount": 4202
                    },
                    (...)
                },
                "solutions": [
                    {
                        "agentName": "Agent Aleph",
                        "route": [
                            {
                                "venueName": "Raydium Liquidity Pool AMM",
                                "venueAddress": "5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h",
                                "venueImage": "https://statics.solscan.io/ex-img/5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h.png",
                                "sentToken": "9wFF5VMevWxK7EaSg9dLSkY8jZAGs8R4DQ9K9X5Jd2ac",
                                "sentAmount": 4202
                            },
                           (...)
                        ],
                        "score": 94
                    }
                ],
                "batchId": 1234678
}
{% hint style="info" %} In the protocol's v1 (alpha) version, orderflow auctions leverage a trusted party to operate (the protocol packing the batches directly). Participation by MEV agent operators is aimed to be permissionless in future iterations of the protocol. {% endhint %} # Urani's Intent Specs This documentation explains how intents work for a limit order in a Urani Swap v1 (alpha) swap. *** ## Creating an Intent To create an intent for a limit order, a user can send the encapsulated JavaScript object to the `/orders` endpoint using a `POST` request. ```javascript { "intentId": 123456, "srcToken": "9wFF5VM1vWxK7EaSg9dLSkY8jZAGs8R4DQ9K9X5Jd2ac", "srcAddress": "0ddb0a23e291b4aeb4c031d91ebf7fdea086eff5", "srcAmount": 8714, "dstToken": "2oNdfRRaxxYE8wRz5xZdqhfv6MFqjVcMkeVusQPh24dP", "dstAddress": "0dd10a23e291b4aeb4c031d91ebf7fdea086eff5", "minReceived": 1704, "expiration": 1718034091 } ``` Here is a breakdown of each parameter and its purpose: * **intentId**: A unique identifier for the intent. In the provided code, it is generated randomly for demonstration purposes. * **srcToken**: The source token's address (mint address) on the Solana blockchain. * **srcAddress**: The wallet address from which the source tokens will be sent. * **srcAmount**: The amount of source tokens to be swapped. * **dstToken**: The destination token's address (mint address) on the Solana blockchain. * **dstAddress**: The wallet address to which the destination tokens will be sent. * **minReceived**: The minimum amount of destination tokens expected from the swap. * **expiration**: The expiration timestamp of the intent. {% hint style="info" %} Learn how the Swap handles the ingestion of intents: [**"Building a Limit Order Ingestion on Solana"**](https://www.urani.trade/blog/transaction). {% endhint %} # Order Types ## Market Order Urani Swap offers a fallback mechanism that fills the order at the spot price. {% hint style="info" %} It's widely known that regular retail traders without private information about prices should favor limit orders over market orders. In addition, market orders are not protected against toxic-MEV. {% endhint %} *** ## Limit Orders **Limit orders are buy or sell orders automatically placed once an asset hits a specific price.** These orders can generate a surplus, and the user receives the price determined at execution time. By design, limit orders have little or no slippage, so they can bypass certain toxic-MEV attacks. In its simplest form, [**Urani's intents**](/urani-swap/technical-considerations/uranis-intents) work similarly to limit orders, guaranteeing that the settlement solution is at least as good as the on-chain value that could be found directly from any AMM or aggregator. {% hint style="info" %} Limit orders on Urani can be set with a diverse expiration value of 5 minutes to a month. {% endhint %} *** ## Trading vs. Swapping There is little difference between a swap and a trade on DeFi platforms, besides the user experience. While trading platforms are designed with charts, indicators, and tools to time entry and exit from the markets, swaps are used by users who just want to move funds in their wallets. The former benefits the most from Urani Swap. *** ## Other Order Types Other order types will be implemented sequentially in the protocol, such as DCA, stop-loss orders, and TWAP. Additional order possibilities can evolve from the ecosystem, such as conditional intents (allowing an action when one or more conditions are met), multi-step intents (where one intent is solved, starting one or more new intents), programmatic orders, and more. # Protocol tl; dr The Urani Protocol is a novel orderbook aimed to provide [**toxic-MEV minimization**](/urani-swap/technical-considerations/mev-on-solana) from[ **swap trades** ](/urani-swap/overview)through: * [x] A competitive marketplace for **liquidity** routing facilitated by **MEV agents**, creating what we refer to as a [**multidimensional price free market**](/urani-protocol/technical-considerations/multidimensional-market). * [x] A novel peer-to-peer (P2P) and ring-matching price-finding algorithm.

A bird's-eye view of how the Urani Protocol connects to the other parts of the stack.

*** ## Solving the Price-finding Routing Problem One of the most exciting features of the Urani protocol is its implementation of P2P matches for orders with the same assets and compatible quantities. These matches enable trades to achieve the best quotes possible without intrinsic swap fees or slippage.

High-level lifecycle of an order intent in the Urani Protocol.

As you can imagine, this feature allows for secure exchanges between individual swappers. The Urani protocol verifies counterparties' opportunities before exploring alternative liquidity sources. The price-finding routing problem can be modeled as a multidimensional network comprising P2P or ring matches, AMMs, DEXs, LPs, or liquidity sources, where the [**utility function (Ω)**](/urani-protocol/technical-considerations/optimization) of the net trade is maximized. In a vanilla setup, this could initially be represented as an undirected graph where the nodes correspond to tokens, and the edges represent the exchange rates between them. However, this representation is unrealistic due to reality's complexity (for instance, three-pools or multiple CFMMs could not be incorporated). A more intuitive representation of a DeFi network is a hypergraph, where edges can connect multiple vertices. Interestingly, routing (arbitrage, swaps, etc.) over a hypergraph can become a convex optimization problem, so it could be efficiently solved to achieve global optimality. {% hint style="info" %} Although P2P matches will be available for the initial v1 (alpha) launch, more advanced ring (DAG) matches will begin to be implemented in future versions of the protocol. {% endhint %} # Technicals # Optimization Problems Optimization problems involve finding the best set of parameters or conditions that maximize or minimize a particular objective function, subject to a set of constraints. *** ## The Main Underlying Goal Consider an executed user order `s`, where `S` represents its executed `sell` amount and `B` is its executed `buy` amount. Then: $$ f\_{\texttt{surplus}}(s) = \texttt{order surplus} = B - \frac{S}{\pi(s)} $$ where $$ \pi(s) = \texttt{order's limit price} = \frac{\texttt{sell amount}}{\texttt{buy amount}} $$ The order can be executed only if: $$ \pi(s) \geq \frac{S}{B} $$ Moreover, if the order is executed, we must have: $$ S \leq \texttt{sell amount} $$ In the case of a fill-or-kill order, the inequality must be satisfied with equality: $$ S = \texttt{sell amount} $$ Given the above definitions, the goal when matching a user order against liquidity sources is to **maximize the surplus of the user order**: $$ \Omega\_{surplus} = \max \left(f\_{\texttt{surplus}}(s)\right) $$ *** ## The Utility Function (Ω) As seen above, the utility (or objective) function encodes what is desired to maximize under given constraints. Another example is that in the context of optimal arbitrage, the utility function could encode the goal of finding the best net trade that is entirely nonnegative. Yet another example is swapping token `PHI` for token `MU`, aiming to maximize the output of token `MU` given a fixed input of token `PHI` (with arbitrage opportunities captured as part of the swap). # Raking the Agents' Solution ## The Quality of a Solution In the first version of the protocol, the quality `Q(s)` of an order price solution `s` can be defined by: $$ Q(s) = f\_{\texttt{surplus}}(s) + f\_{\texttt{speed}}(s) $$ The agent's goal is to maximize a utility function defined as: $$ \Omega = \max \left({Q(s)}\right) - \min(f\_{\texttt{costs}}(s)) $$ At the conclusion of the auction, solutions are ranked in descending order, and the agent with the highest score (*i.e.,* the largest utility function) wins the round. {% hint style="info" %} In future versions of the protocol, the quality of a solution will include more features. Based on this function, the agent's reward will then be computed as a [**multidimensional agent reward**](/urani-protocol/technical-considerations/multidimensional-market). Additionally, each solution's score will contribute to the agent's overall reputation score in the [**Arena**](/urani-arena/urani-arena-overview). {% endhint %} # Batch Auction Specs Designing an explicit auction poses two primary challenges: * [x] Avoiding reliance on a trusted auctioneer and achieving both low-latency guarantees, and * [x] Maximizing value capture (meaning, the less time a market maker is exposed to an asset's price, the better). *** ## Continuous time vs. Block time {% hint style="info" %} TBA. {% endhint %} *** ## Partial Order Fills {% hint style="info" %} Support for partial fills will begin to be implemented in 2025. {% endhint %} # Ring (DAG) Trades Another exciting feature the Urani Protocol is designed to bring is ring trades (i.e., by discovering directed acyclic graphs in trades). {% hint style="info" %} Great research has been conducted on using DAGs for MEV protection, particularly by [**scientist Dahlia Malkhi**](https://arxiv.org/pdf/2208.00940). {% endhint %} # Order Execution ## How Urani Settles Orders on Solana The Solana network can be thought of as a high-speed stream of blocks, where block production is much faster than on EVM-based blockchains (around 400-600 milliseconds block times, as opposed to 12-13 seconds on Ethereum). The Urani Protocol is designed to collect and aggregate [**intents**](/urani-swap/technical-considerations/uranis-intents) and settle them into [**batches**](/urani-swap/technical-considerations/batch-auctions) within a few seconds. This design choice is similar to leading intent-based projects on EVM-based blockchains (where [**around 20% of the orders are matched within the designated time frame**](https://dune.com/decanus/cow-trades)). However, this can change in future versions of the protocol. Since Urani Protocol's on-chain settlements are derived from batching, order executions have some latency compared to the network's underlying speed. However, as a trade-off, users benefit from secure trading. As the system scales, network effects, and enhanced peer-to-peer and ring matches should allow improvements in the speed at which order flows are settled, reaching parity while offering unmatched price discovery. {% hint style="info" %} Before the system reaches a certain volume and network effects, it's impossible to benchmark performance accurately. Therefore, until then, the protocol will ensure that if the solution of the batches is unavailable within the desired time frame (set to 3 seconds), the order fallbacks will be filled with the current best price available. {% endhint %} *** ## Considerations Regarding Protocol vs. Agent Settlement Generally, protocol execution is more straightforward to implement, but it carries higher centralization risks. Leaving the execution to agents, on the other hand, can be more adaptable to last-minute changes and is directly permissionless. {% hint style="info" %} For the v1 (alpha) launch, we had to choose between prioritizing the agent's full permissionless-ness or eliminating entry barriers (*i.e.*, not relying on KYC or bonds). Since anonymously onboarding anyone who writes code and wants to become a MEV agent operator is our main priority, this first version of the protocol includes settlement managed by the protocol. Once we have the right incentives in place to ensure minimal attack surfaces, we plan to transfer settlement responsibilities to the agents (so that the protocol can become permissionless). {% endhint %} # Multidimensional Price Free Market # On Solana # Solana Fees Overview Blockchain networks use fee markets to prioritize transactions based on the fees paid, acting as a dynamic pricing mechanism for network resources like block space and transaction execution. These markets help maintain network efficiency and prevent spam transactions. On Solana, [**transaction fees**](https://github.com/urani-labs/solana-mev-literature/blob/main/1_Solana.md#8%EF%B8%8F%E2%83%A3-solana-fees) are low-cost and predictable, structured as flat fees based on the number of signatures. Each signature incurs a fee of 5000 lamports, equivalent to 0.000005 SOL. Additionally, Solana's account model can, in theory, dynamically adjust fees in response to state disputes, helping to improve network performance. *** ## Local Fee Market Unlike the typical global fee market found on EVM-based chains, Solana's fee markets are designed to be local to each account, meaning that each program on Solana operates within its own fee market. Referred to as the **local fee market,** this system is still being developed on the blockchain. In this model, for example, the cost required for prioritization in an NFT drop would be inherently distinct from the fee needed for a DEX trade. *** ## Priority Fees What happens if there is a sudden surge in transactions? [**Priority fees**](https://www.helius.dev/blog/solana-fees-in-theory-and-practice#fees-in-practice) are optimal fees designed to dynamically adjust transaction costs based on network conditions, allowing for more accurate demand pricing at any given time. Validators are economically incentivized to schedule transactions with the highest fee per compute unit, thus optimizing resource usage: $$ \texttt{priority fee} = \texttt{compute units} \times \texttt{compute unit price} $$ {% hint style="info" %} Learn how to use priority fees on Solana programs [**here**](https://solana.com/developers/guides/advanced/how-to-use-priority-fees). Please be aware that this system is still under development. {% endhint %} # Solana Transactions Overview The Solana blockchain prioritizes ultra-fast transactions and high capacity through several innovative features. It uses [**Proof-of-History**](https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274) for unique timestamping, the [**Turbine**](https://docs.solana.com/cluster/turbine-block-propagation) protocol for rapid block building, and parallel processing with shards to handle transactions simultaneously. Additionally, Solana does not have an in-protocol mempool; all transactions are sent to leaders for inclusion in a block until the blockhash expires. Transactions can be routed to leaders by proxy via an RPC server or a TPU client.

High-level overview of a lifecycle of a Solana transaction.

# Understanding Slippage ## Slippage and MEV Setting a low slippage tolerance is the simplest defense against toxic-MEV. Since searchers exploit slippage for price manipulation, transactions with lower slippage tolerance could provide less opportunity for toxic-MEV exploitation from trades. Additionally, slippage modeling generally incorporates statistics into a smart order routing algorithm to deliver the optimal trade route. Nevertheless, these solutions are incomplete. Even with optimal slippage, MEV bots may still derive value from your trades. *** ## On Solana In [**Solana's Token Swap Program**](https://github.com/solana-labs/solana-program-library/tree/master/token-swap), a generic swap involves the input `amount_in`, which represents the amount of token the user wants to trade, and `minimum_amount_out`, which denotes the minimum amount of output tokens necessary to avoid excessive slippage: ```rust /// Swap instruction data pub struct Swap { /// SOURCE amount to transfer, output to DESTINATION is based on the exchange rate pub amount_in: u64, /// Minimum amount of DESTINATION token to output, prevents excessive slippage pub minimum_amount_out: u64, } ``` The minimum amount of output tokens is connected to the actual number of output tokens by the slippage, ensuring that: $$ \min(N\_{out}^A) = N\_{out}^A - S^A \times N\_{out}^A $$ The slippage can be derived as follows: $$ S^A = \frac{N\_{out}^A - \min(N\_{out}^A)}{N\_{out}^A} % $$ # Urani's Dynamic Fees Swap fees and the fees generated from an order surplus (the bid-ask spread) should be dynamic, increasing during times of high volatility and decreasing when volatility is low. To achieve this, the Urani Protocol aims to balance several factors, such as transaction speed, price discovery, agent operational costs, and overall network health. {% hint style="info" %} In its v1 (alpha) version, Urani will not charge fees, so all surplus goes to operators and users. Urani's multidimensional fees and agent rewards will be implemented in future protocol versions. {% endhint %} # Oracle Market Data Proxy The Urani Protocol leverages an on-chain oracle as an additional internal method for verifying prices, bolstering its resilience against market manipulation attempts by possible malicious MEV agent operators. {% hint style="info" %} The Protocol's v1 (alpha) version has [**Pyth**](https://www.quicknode.com/guides/solana-development/3rd-party-integrations/pyth-price-feeds) integrated directly into the Swap. The full implementation of the oracle proxy will begin in future versions of the protocol. {% endhint %} *** ## Swap Price Suggestion The v1 (alpha) version of the Swap frontend suggests the current market prices of the selected token conversion using Pyth's real-time market [**price feed API**](https://docs.pyth.network/price-feeds/use-real-time-data/off-chain). It displays the fetched price to the user on limit orders, but the user can change to its desired order price. If the price isn't changed, it gets automatically updated with the latest market data every 30 seconds. # Security Considerations ## Transaction collisions and Frontrunning {% hint style="info" %} TBA. {% endhint %} # Intent Gossip Layer Specs {% hint style="info" %} TBA. {% endhint %} # Settlement Specs {% hint style="info" %} TBA. {% endhint %} # Arena tl; dr At Urani, we recognize the awesomeness of being a **MEV agent operator**: a builder who possesses DeFi and advanced algorithm expertise and is extremely valuable to decentralized finance by finding optimal solutions to access liquidity. Our goal is to treat these agent operators the way they deserve: ✨like stars✨. This means **no KYC, no bond, and lots of rewards and economic incentives**.

Urani Arena v1 (alpha). Note the peer-to-peer match being highlighted.

Additionally, inspired by the world of extreme sports, where enmity and friendship coexist amidst thrilling moments, Urani Arena provides a real-time visual infrastructure for order auction competition. The Arena is designed to provide several strategies to ensure operators from all backgrounds have opportunities to succeed, thus commoditizing MEV agent operators and engaging their fans. {% hint style="info" %} A first MVP of the Arena was open-sourced [**here**](/urani-swap/overview). {% endhint %} # Technicals # The PvP Competition Urani's player-versus-player (PvP) competition unfolds in the Arena, an open battleground where agents compete to optimize transaction routes and maximize user surplus and solution speed. Leveraging their unique algorithms and strategies, operators engage in a *fierce* battle to prove who offers the most advantageous execution paths for trades. The competition takes place in less than a few seconds, and operators can be any developer willing to write optimization algorithms for decentralized finance. This PvP competition fosters innovation and efficiency while ensuring a fair and transparent process, benefiting all participants. # Incentives for Operators Since anonymously onboarding anyone who writes code and wants to become a MEV agent operator is our main priority, this first version of the Protocol is managing the settlement. Later, we plan to move to a permissionless setup through the a novel reputation system. *** ## The Arena is for Everyone To ensure that operators from all backgrounds have opportunities to succeed in the Arena and that senior operators enjoy the setup as well, the Protocol will provide several strategies, including: * [x] Open-source plug-and-play agent templates in several languages, on which both beginners and existing solvers can simply add their private strategies. * [x] Different arena tiers for beginner and advanced operators. These tiers are differentiated by factors such as complexity and size of orders inside the batches. * [x] Rewards escalators, *i.e.,* dynamic rewards that increase over time until an agent is sufficiently incentivized. * [x] Multidimensional reputation and rewarding incentives. * [x] Competition seasons. {% hint style="info" %} These incentives will begin to be implemented in 2025. {% endhint %} # Reputation Dashboard {% hint style="info" %} TBA. {% endhint %} # The Competition Seasons {% hint style="info" %} TBA. {% endhint %} # Agents tl; dr {% hint style="success" %} *"A useful definition of solvers is self-interested actors who are financially incentivized and rewarded for their participation and optimization."* \- Nathan Worsley {% endhint %} A [**MEV agent**](/mev-agents/agents) is a term we coined to denominate an **algorithm (or bot)** authorized by the[ **Urani Protocol**](/urani-protocol/urani-protocol-overview) to receive [**intent**](/urani-swap/technical-considerations/uranis-intents) [**batches**](/urani-swap/technical-considerations/batch-auctions) and return[ **optimized solutions**](/urani-protocol/technical-considerations/optimization) for orders. A **MEV agent operator is the human** who operates this bot. Typically, they are developers who want to take advantage of multiple trading strategies in cryptomarkets. Agents are essential components of the protocol, functioning as matching engines to identify the optimal execution paths for orders to ensure traders receive the best execution, *i.e.*, the most advantageous prices and routes. {% hint style="info" %} We like to think that our MEV agent templates are "customizable skateboards", allowing operators to navigate the hypergraph of the orderflow auction landscape. {% endhint %} *** ## How MEV Agents Work At a high level, agents first analyze the current batch of orders to detect any P2P matches or ring trades that could offer the best prices for [**executing trades or limit orders**](/urani-swap/technical-considerations/order-types). If no such match is found, they deploy their [**graph and combinatorial algorithms**](/mev-agents/operator-onboarding/setting-up-an-agents-graph) to solve the problem by evaluating multiple factors, including liquidity, orderbook depth, price slippage, and exploring multiple venues, including on-chain automated market makers, DEXs, and aggregators.
# Technicals # Urani's In-house Agents In-house agents serve as open-source templates and fallback systems within the Arena. # MEV Agent Aleph
**Agent Aleph** is Urani's first in-house arbitrage agent, written in Python. [**Its source code is open-sourced**](https://www.urani.trade/mev-agent-templates/aleph)**,** allowing operators to use it as a template and plug in their favorite strategies. Agent Aleph is one of the agents running in the Protocol to help with gauging and fallback. Nevertheless, in-house agents are not intended to outperform MEV agents outsourced by operators. *** ## Current Agent Aleph's Strategies In its first version (v1), this agent runs the following algorithm: 1️⃣ Listen for incoming batches. 2️⃣ Parse these batches to extract the order intents. 3️⃣ Check for peer-to-peer matches among the intents. 4️⃣ Spin a new thread for each intent to calculate solutions for best quotes through arbitrage in different liquidity sources. 5️⃣ Pack the solutions and send them to the protocol. {% hint style="info" %} More advanced strategies should be incorporated into future versions of the protocol, both in terms of arbitrage algorithms and liquidity searching. Additionally, agents will also be responsible for the settlement, allowing the system to become fully permissionless. {% endhint %} # MEV Agent Bet
**Agent Bet** is Urani's second in-house arbitrage agent, written in Rust. Its code will be open-sourced in 2025, allowing operators to use it as a template and plug in their favorite strategies. # The Onboarding Process {% hint style="info" %} Details on the onboarding process and incentivisation for operators will be available in 2025. {% endhint %} # Economic Incentives ## Anons are welcome: No KYC or Bond Urani is bringing a new way to onboard operators, ensuring it is accessible and private. For instance, we won't ever ask for KYC or any bond. *** ## Fair Surplus Distribution For limit orders, the surplus (or bid-ask spread) is the difference between what the user wants to pay and what the agent can source. Consequently, agents are primarily driven by the profit from this surplus in each order. {% hint style="info" %} In its first version, the protocol assigns 50% of the surplus to the agent and 50% to the users. This is the first iteration of how the surplus division will work in the protocol and serves as an initial placeholder. Later, many factors will be considered when calculating how much an agent will be rewarded, coinciding with the transition to a permissionless setup. {% endhint %} *** ## Rewards An agent's rewards should be determined based on the value it delivers to end users in each settled batch, and dynamically computed by the protocol. As defined by the [**solution ranking**](/urani-protocol/technical-considerations/raking-the-agents-solution), in the first version of the protocol, the quality of the solution considers: * [x] The surplus generated in the solutions. * [x] The speed of the solutions. In future versions of the protocol, several factors should be incorporated, including: * [x] The innovative nature of solutions. * [x] Prevailing market conditions. * [x] The agent's cumulative reputation in the protocol.\\ *** ## Other Benefits As the protocol transitions to a permissionless, operators will have access to various benefits within the protocol and the community, such as: exclusive events, notoriety, prizes, stakes on a shared DAO like multisig, etc. # MEV Agent Specs {% hint style="info" %} TBA. {% endhint %} # Setting up an Agent's Graph {% hint style="info" %} TBA. {% endhint %} # Building an initial AMM Strategy {% hint style="info" %} TBA. {% endhint %} # Liquidity Strategies MEV Agent operators are free to build strategies on top of any liquidity source within each batch. Liquidity can be sourced from several channels: * [x] AMMs, DEXs, aggregators, such as [**Orca**](https://www.orca.so/), [**Raydium**](https://raydium.io/swap/), [**Meteora**](https://www.meteora.ag/), or [**Jupiter**](https://jup.ag/). * [x] Peer-to-peer (P2P) and ring matches for bids and asks of the same asset. * [x] Private or institutional market makers. * [x] A novel protocol for private liquidity pools. * [x] Any innovative methods operators can devise. # On Solana # Raydium {% hint style="info" %} TBA. {% endhint %} # Phoenix {% hint style="info" %} TBA. {% endhint %} # Orca [**Orca**](https://www.orca.so/) is a protocol built around a Concentrated Liquidity Automated Market Maker (CLAMM) using Solana's [**Token Swap Program**](https://github.com/solana-labs/solana-program-library/tree/master/token-swap). *** ## Setting up Orca's CLAMM Pools into your Agent's Graph {% hint style="info" %} TBA. {% endhint %} # Meteora [**Meteora**](https://www.meteora.ag/)'s Dynamic Liquidity Market Maker (DLMM) is a protocol designed to offer liquidity providers dynamic fees and real-time, precise liquidity concentration. *** ## Setting up Meteora's DLMM Pools into your Agent's Graph {% hint style="info" %} TBA. {% endhint %} # Jupiter {% hint style="info" %} TBA. {% endhint %} # Performance and Reputation The Urani protocol has a built-in reputation, penalty, and performance system to reward the best MEV agents while limiting the abuse of the exclusivity they receive. Rankings are determined through several features, including: * [x] Number of batches solved. * [x] Speed of the solution. * [x] Number of winning batches and settled trades. * [x] Number of trades per batch. * [x] Number of DEX swaps. * [x] Average batch sizes. * [x] Volume of orders settled. * [x] Volume of surplus generated. This is all to create economic incentives that discourage malicious behaviors from operators. # Solving Cryptomarkets # Quantitative Theories and AI-Centric Agents {% hint style="info" %} After our public launch, we plan to allocate some of our resources to publishing research and open-source code for advanced strategies, focused on cryptomarkets. {% endhint %} # DeFi Glossary ## A ### Adverse Selection A situation that occurs when one party in a transaction has more information than the other, leading to an imbalance that can result in suboptimal outcomes. It often occurs in markets where buyers and sellers have different levels of information about the quality or value of a product or service. ### Algorithm Trading Algorithmic trading uses algorithms to automatically execute trades based on predefined strategies. Traditional strategies include trend following, arbitrage, market making, and mean reversion. The main benefits are speed, precision, backtesting, and scalability. However, it also poses risks like system failures, market impact, and overfitting. ### Arbitrage A type of algorithm trading where the purchase and sale of the same asset in different markets to profit from differences in the asset's price. Arbitrage can incentivize a healthy pricing environment if it does not increase toxic order flow. ### Automated Market Maker (AMM) A decentralized exchange that maintains a pool of capital (a liquidity pool) with at least two assets, and a program governs the rules by which traders can purchase and sell assets from the liquidity pool. For context on Ethereum, Uniswap v1 introduced a class of AMM called a Constant Product Market Maker (CPMM), Uniswap v2 introduced the auto-route splitting trades across, while Uniswap v3 introduced a new feature called concentrated liquidity. *** ## **B** ### Backrunning When a transaction sender wishes to have their transaction ordered immediately after an unconfirmed target transaction. ### Blockhash Solana's blockhash is a unique cryptographic identifier for a block that ensures data integrity and immutability. Solana uses the blockhash to timestamp transactions, ensuring they are processed in the correct order. *** ## **C** ### Concentrated Liquidity Automated Market Maker (CLMM) A system where liquidity providers can concentrate their funds within specific price ranges, improving capital efficiency and reducing trading slippage compared to traditional AMMs. This approach, used by platforms like Uniswap V3 and Orca, ensures tighter spreads and better trading conditions by focusing liquidity where it's most needed. ### **Collateralization Ratio** The proportion of the borrowed amount relative to the value of the collateral, indicating the risk level for lenders. *** ## **D** ### Dollar Cost Averaging (DCA) A strategy to help against market volatility where the user agrees on set recurring swaps on a time interval. ### Dutch Auction A Dutch auction is where the price starts high and gradually lowers until a bidder accepts the current price. It is often used for selling items quickly, such as in flower markets or for certain financial securities. ### Dynamic Liquidity Market Maker (DLMM) Inspired by [**Trader Joe’s Liquidity Book**](https://docs.traderjoexyz.com/), DLMMs organize an asset pair’s liquidity into discrete price bins (concentrated liquidity), enhancing the efficiency and effectiveness of liquidity provision. In Solana, Meteora leads this approach. *** ## E ### English Auction An English auction is a type of auction where bidders openly bid higher than the previous bid until no more bids are made. The highest bid wins, and the winner pays their bid amount. *** ## **F** ### **Flash Loan** Uncollateralized loan that must be repaid within the same transaction block. ### Funding Rate Arbitrage A mechanism used in perpetual swap contracts to keep the contract price aligned with the spot price of the underlying asset. It adjusts periodically, transferring funding from one side of the trade to the other based on whether the contract price is above or below the spot price. This system incentivizes traders to maintain the contract's price close to the spot price, reducing the risk of manipulation and ensuring the contract's attractiveness for traders. ### Frontrunning The process by which an adversary observes transactions on the network layer and then acts upon this information by issuing a competing transaction. *** ## **I** ### Intents Intents are defined in the Urani Protocol as the user's desire to swap an amount of a sell token for a buy token. Intents can be used interchangeably with orders. ### Impermanent Loss The rebalance of AMMs to maintain their ratios, due to asset prices change. Also, see Loss vs. Rebalancing. ### **Interest Rate** A percentage charged on a borrowed asset, indicating the cost of borrowing or the return on lending. *** ## **L** ### Leverage The capacity to enhance potential gains or losses by borrowing money to increase exposure to an asset. ### Limit Orders Execution of a trade at a specific price or better. Therefore, buy or sell orders are automatically placed once an asset hits a certain price. ### Liquidation A crucial mechanism to maintain the health of the margin trading protocol and protect lenders from potential losses. It's the automatic process of selling off a trader's assets when their account balance falls below a required maintenance margin. This usually happens in leveraged trading, where borrowed funds are used to increase potential returns. If the market moves against the trader's position and their losses exceed the margin threshold, the exchange or platform forcibly closes the position to prevent further losses and repay the borrowed funds. ### Liquidity Liquidity refers to the ease with which an asset can be bought or sold in the market without significantly affecting its price. It measures how quickly an asset can be converted into cash without causing a substantial change in its value. In the context of DeFi, low liquidity could lead to longer fill times and higher slippage. ### Liquidity Pool A set of funds created by grouping two tokens that form a "pair" and leaving an amount of them in exchange. This setup allows users to buy and sell the tokens that comprise that set of funds. ### **Long Position** A trader's bet on asset price increase. ### Loss vs. Rebalancing LVR or "impermanent loss" is a phenomenon unique to decentralized exchanges and liquidity provision in AMM systems. It refers to the temporary loss of funds that liquidity providers experience when the value of one asset in the pool diverges significantly from the other. Arbitrageurs trading against passive liquidity providers often quote stale prices, leading to consistent losses. *** ## M ### Market Makers A financial intermediary that provides liquidity to markets by being willing to buy and sell securities at any time. They make profits from the difference between the buying price (bid) and the selling price (ask), known as the bid-ask spread. ### Market Orders Immediate execution of a trade at the best available price. Buy or sell orders submitted as soon as possible at the current market rate. They are *fill or kill* instead of partially fillable, so agents must find liquidity for the entire order to submit a solution. ### Mempool The mempool in Ethereum is a temporary storage area where pending transactions are held before they are included in a block and confirmed on the blockchain. Solana does not have an in-protocol mempool, so its validators forward all transactions to up to four leaders on the leader schedule instead. This forces the transactions to hop from leader to leader until blockhash expiration, but it also reduces the overhead of gossip across the cluster. ### MEV-protected RPC endpoints Endpoints that allow users to receive a portion of the proceeds from their order flow as rebates. Searchers compete to backrun transactions, offering a rebate that is paid back to the user. The operation of these endpoints generally depends on trusting the counterparty managing the endpoint to prevent frontrunning or sandwiching. *** ## N ### Nakamoto Coefficient Measures the minimum percentage of nodes an attacker would need to control to compromise the network's security. A higher Nakamoto coefficient indicates a more decentralized network, so an attack would require a larger portion of the nodes to be compromised. *** ## O ### Oracle Extractable Value (OEV) A subset of MEV, when applications rely on an oracle's update for arbitrageurs or liquidators to capitalize on this state inconsistency. ### Order Book Much like conventional financial markets, borrowers and lenders provide their preferred borrowing or lending terms, including the interest rate and loan duration. The pairing of borrowers and lenders is facilitated based on these submitted terms, with interest rates established through the dynamics of supply and demand. *** ## **P** ### Priority Fees An additional fee on each transaction that prioritizes the execution over transactions with lower costs. During network congestion, priority fees can boost a transaction. ### Proof of History (PoH) Solana’s Proof of History mechanism establishes a trustless and verifiable order of events (transactions) on the network. This makes it more challenging to insert, reorder, or delay transactions in a way that would be advantageous for extracting MEV. *** ## **Q** ### Quote Deviation The difference between the quote the user received and the price at which their order was settled. *** ## **S** ### Sandwich Attack On automated market makers, an adversary can create two transactions and insert before and after a victim transaction to profit from it (for instance, from slippage). ### Slippage The price variation (or impact) from the moment a user initiates a trade to its execution. For example, higher slippage should be expected during token launches due to rapid price changes. ### **Short Position** A trader's speculation on the decrease of an asset price. ### **Spot Price** The market price of an asset, for immediate delivery. ### Snipers Due to Solana's low fees, sniper bots are designed to increase the chance of landing a transaction during chain congestion. ### Surplus The price improvement on a user's limit price, similar to the bid-ask spread, which refers to the gap between the bid (from buyers) and the ask (from sellers) prices of an asset. *** ## T ### Time Bandit Attack The manipulation blocks' timestamps in a blockchain to gain certain advantage. Attackers may alter the time settings to control block production, reorder transactions, or perform double-spending attacks. This can disrupt the consensus mechanism of the blockchain, allowing the attacker to potentially reverse transactions, steal funds, or destabilize the network. ### TWAMM [**Time-weighted Average Market Maker**](https://www.paradigm.xyz/2021/07/twamm) breaks long-term orders into infinitely many small pieces, smoothly executing them against a CPAMM over time. ### TWAP Time-Weighted Average Price orders are a type of algorithmic trade ideal for larger orders, as they allow them to be divided into smaller parts and avoid their price impact. *** ## Y ### Yield-bearing Tokens (YBT) Derivatives of another token that can generate yield are typically divided into two components: the main component and the yield component. # In Honor of Jim Simons (1938-2024)
### Our research at Urani is inspired by Dr. Jim Simons, Ph.D., who left an indelible mark on mathematics and finance. His journey from a renowned mathematician to a legendary hedge fund scientist exemplifies the profound impact one individual can have across diverse fields. His life, which spanned 86 years, is a testament to the power of intellect, curiosity, and innovation. *** ## **The Early Years and Academic Achievements** Jim Simons obtained his Ph.D. in mathematics from the University of California, Berkeley, at 23. The mathematical and theoretical physics community celebrates his contributions to differential geometry and topology, particularly his work on the Chern-Simons form. His research has had lasting implications, influencing various mathematics and theoretical physics areas. As a professor at the Massachusetts Institute of Technology and later at Stony Brook University, Simons inspired a generation of mathematicians and physicists (including our CEO). *** ## **Transition to Finance** At age 40, in the late 1970s, Simons made a dramatic career shift, applying his mathematical expertise to finance. He founded Renaissance Technologies in 1982, a hedge fund that utilized quantitative models to predict market movements. Under his leadership, Renaissance Technologies' Medallion Fund became one of history's most successful hedge funds, boasting annualized returns of over 35% before fees. Simons' pioneering work in algorithmic trading demonstrated the profound synergy between advanced mathematics and financial markets, effectively transforming finance. *** ## **Philanthropy and Legacy** Beyond his professional achievements, Jim Simons was a dedicated philanthropist. Through the Simons Foundation, he and his wife Marilyn supported research in mathematics, the basic sciences, and autism. Urani's CEO benefited from this support during [**her PhD at Stony Brook**](https://www.astro.sunysb.edu/steinkirch/). Their generous endowments have funded countless research projects and institutions, fostering advancements in various scientific fields. Simons' commitment to education and science extended to initiatives such as Math for America, which aims to improve mathematics education in the United States. *** ## Thank you, Jim Jim Simons' life is a remarkable intellectual achievement and practical innovation story. His contributions to mathematics, finance, and philanthropy have left a lasting legacy that will continue influencing future generations. In honoring Jim Simons, we celebrate a life driven by curiosity, a commitment to excellence, and a profound impact on multiple fields.