# XGA GTM

[TOC]

> [!NOTE]
> See New Auction Id Format
> https://hackmd.io/@sbacha/eip-slot-id-format

> [!WARNING]
> Contingent fee model is replaced, see `Fees and Rebates`

> v 2025.07.14/16
>
> [name=sam bacha]

## Fees and Rebates

Contingent fees create a free option for winners, leading to overbidding and zero execution/revenue.

Upfront: Pay bid unconditionally.

Contingent: Pay bid only if executed.
Key Details:

${ }^{\circ}$ Asset value: $S_1 \sim F(\cdot)$ (revealed post-auction).
${ }^{-}$Strike price: $K$.
- Payoffs:
- Upfront winner: $V_i= \begin{cases}S_1-K-b & \text { Executed } \\ -b & \text { Not }\end{cases}$

Contingent winner: $V_i= \begin{cases}S_1-K-b & \text { Executed } \\ 0 & \text { Not }\end{cases}$

#### Economic Pathology:

Contingent fees shift payment risk → winners bid until execution is unprofitable.

#### Upfront payments

Upfront payments align incentives:

Bid = option value, execution probability = $P (S_1 > K^*)$

#### **Decoupled Bid-Execution Fees**
- **Upfront Bid + Fixed Execution Fee**: Auction winners pay a bid upfront (for call option) + a fixed, non-bid-contingent fee upon execution (e.g., $0.001 per contract).
- *Breaks bid-strike linkage*: Execution fee is independent of bid size, avoiding effective strike inflation
- $(K \rightarrow K + b)$.
- *Preserves incentives*: Bidders win via upfront bids; execution depends solely on
- \($S_1 > K$\).

#### **Bid Rebate Pools**
- **Redistribute Unearned Fees**: Contingent fees from unexecuted options fund rebates for executed orders (e.g., 50% fee rebate if \($S_1 > K$\)
- *Self-balancing economics*: Penalizes non-execution while subsidizing profitable trades, neutralizing the "free option" effect.
- *Behavioral nudge*: Rebates incentivize execution without altering strike prices.
> *Note*: Requires escrow smart contracts; transparent pool accounting.

### **Fee and Rebate Evaluations**
| **Proposal** | **Approach** | **Risk Mitigated** | **Calibration Need** |
|---------------------------|---------------------------------------|----------------------------|----------------------|
| Decoupled Fees | Separates bid & execution costs | Strike inflation | Low (fixed fees) |
| Bid Rebate Pools | Cross-subsidizes execution | Revenue collapse | Medium (rebate %) |

---

## Validator and Node Operator Rewards

## Motivation

The core objective is to ensure the system's security and performance, which often correlates with the total economic value "staked" or committed to the network. However, naive reward mechanisms, such as those proportional to stake, can lead to a "rich-get-richer" dynami

## Axioms

Axiom of Random Opportunity: Committee selection is based on pure chance among eligible validators, independent of stake size. The probability of selection is uniform: P[selected]=x/∣Seligible​∣.

Axiom of Relative Performance: Once a committee is selected, rewards are determined by an agent's relative stake rank within that small group, not their absolute stake size.

Axiom of Discretized Competition: The continuous ranking of stake is mapped to a discrete set of tiers, each with a fixed reward share (Tierj​,Rj​). This creates distinct competitive brackets.

Axiom of Static Design: The key parameters of the mechanism—the number of tiers (k), the size of each tier (mj​), and the rewards for each tier (Rj​)—are constant and fixed at the protocol level.

Axiom of Fungible Stake: The input to the ranking function, T(si​), is the simple quantity of tokens staked.

### Committee and Payments

A validator's "effective stake," used for ranking within a committee, is not their current token balance but a time-weighted measure of their committed capital. This makes long-term, stable participation more valuable than newly-created Sybil stakes.

In each slot, the protocol selects two (or more) committees, CA​ and CB​, of size x. Both committees perform the required consensus task in parallel (e.g., propose a block). The total reward pool Rtotal​ is then split between the committees based on a performance metric. The "winning" committee gets a larger share of the rewards, which are then distributed

> : This creates a multi-level tournament. It incentivizes not only individual stake accumulation (for intra-committee rank) but also contributes to collective success (for inter-committee rewards).

After the committee of size x is selected and ranked, the total reward Rtotal​ is distributed according to a continuous, monotonically decreasing function of rank.

> a single, interpretable parameter, p. It creates a smooth incentive gradient, removing the boundary-gaming problem and simplifying analysis.

| $S$ | total set of stakers in the network. |
| :--- | :--- |
| $s_i$ | individual staker in $S$. |
| $T\left(s_i\right)$ | amount of tokens staked by $s_i$. |
| $S_{\text {min }}$ | minimum stake required to participate in the protocol. |
| $x$ | number of stakers randomly selected per slot. |
| $k$ | number of tiers defined in the protocol. |
| $m_j$ | number of stakers in tier $j$, where $1 \leq j \leq k$. |
| $R_j$ | total reward allocated to tier $j$, where $1 \leq j \leq k$. |
| $r_{i j}$ | reward for staker $i$ in tier $j$. |
| $f(g)$ | random selection function to choose $x$ stakers from $S$. |
| $O$ | ordered set of selected stakers sorted by $T\left(s_i\right)$, in descending order. |

1. Each staker $s_i \in S$ is eligible if they have minimum amount of stake: $T\left(s_i\right) \geq S_{\min }$ The global set of eligible stakers thus defined as: $S _{\text {eligible }}=\left\{s_i \in S \mid T\left(s_i\right) \geq S_{\min }\right\}$
2. The protocol randomly select $x$ stakers for the slot: $S _{\text {selected }}=f\left( S _{\text {eligible }}, x\right)$
3. Selected stakers are sorted in descending order by their amount of stake: $O =\operatorname{Sort}\left( S _{\text {selected }}, T\left(s_i\right)\right)$
4. The ordered set $O$ is then subdivided into $k$ tiers according to their stake-rank in the slot, i.e., top $x_1$ stakers among the selected go into tier 1 , next $x_2$ stakers go into tier 2 etc.:

$$
\text { Tier }_j=\left\{s_i \in O \mid \text { first } m_j \text { stakers }\right\} \quad \text { and } \quad \sum_{j=1}^k m_j=x
$$

The union across all tiers in a slot thus equals:

$$
O =\bigcup_{j=1}^k \text { Tier }_j \quad \text { and } \quad \mid \text { Tier }_j \mid=m_j
$$

5. Rewards are distributed equally within each tier:

$$
r_{i j}=\frac{R_j}{m_j}, \quad \forall s_i \in \text { Tier }_j
$$

The total rewards distributed to stakers across all tiers in a slot should equal:

$$
\sum_{j=1}^k R_j=R_{\text {total }}
$$

where $R_{\text {total }}$ is the total reward available for a slot, as defined by protocol parametrization.

By combining this probability with the reward assigned to each tier $R_j$, we can therefore calculate the expected per slot reward for any validator as:

$$
E \left[R_i\right]=\sum_{j=1}^k P(\text { validator } i \text { in tier } j) \cdot \frac{R_j}{x_j}
$$

where $x_j$ is the number of validators in tier $j$ and $R_j$ is the number of validators is the total reward allocated to tier $j$ for a given slot.

This deterministic reward modeling is critical in order for validators to participate in the protocol, by allowing them to make decisions based on analyzing the marginal reward benefit of increasing their stake (i.e., moving from rank $i$ to $i-1$ ). This can also be used by protocol designers to detect potential discontinuities that might encourage gaming, such as splitting or merging their stake to cross tier thresholds.

---

# Transaction Contention mitigation by Sub Bundling

> This is an extenstion to the OpenMEV Router v1 with many lessons from that here

### 1. **Core Challenge: The "Ripple Effect"**
- In CFMMs, transaction execution is **state-dependent**. Executing a transaction changes the pool's reserves \((x, y)\), which affects:
- The execution price/output of *subsequent* transactions.
- The MEV value generated by later transactions.

- This creates a "wavlet/ripple" where transactions cannot be evaluated or executed independently. Optimizing one transaction's placement affects others.

### Independent Sub-Bundles**
The ISB mechanism decomposes the bundle into **|M| + 1 isolated sub-bundles**:
- **|M| sub-bundles** (one per pending transaction in \(M\)).
- **1 sub-bundle** for the initial state \(s_0\) (rebalancing arbitrage).

Each sub-bundle is **self-contained** and **leaves the pool state unchanged** after execution.

### **Structure of Each Sub-Bundle**
- **For a user transaction $(\textsf{TX}_j\)** (if \(\max_i V_i(\textsf{TX}_j) \geq 0))$
- Construct a "**sandwich**" around \(\textsf{TX}_j\):
1. **Front-run transaction**: Moves the pool from the **initial state $(s_0 = (x_0, y_0))$** to the **limit state \$((x_j^\ell, y_j^\ell))$ ** where $(\textsf{TX}_j\)$ executes with worst-case slippage (maximizing MEV).
2. **Execute \(\textsf{TX}_j\)**: Runs at the limit state.
3. **Back-run transaction**: Returns the pool from \((x_j^\ell + \Delta x_j, y_j^\ell + \Delta y_j)\) **back to \(s_0\)**.
- *Effect*: The sub-bundle starts and ends at \(s_0\), so it has **zero net impact** on the pool state for other sub-bundles.

- **For the initial state \(s_0\)**:
- A single **rebalancing arbitrage transaction** (e.g., \(\mathcal{X} \rightarrow \mathcal{Y}\) or \(\mathcal{Y} \rightarrow \mathcal{X}\)) moving the pool from \(s_0\) to the no-arbitrage state \((x^*, y^*)\) based on the winner's reported price \(q_{w'}\).
- *Note*: This sub-bundle *does not* return to \(s_0\), but it executes last and is independent of prior sub-bundles.

---

### 4. **Key Innovations & Implications**
- **Independence**:
- Each sub-bundle is **unaffected by others** because:
- All user-transaction sub-bundles reset to $(s_0)$.
- The rebalancing sub-bundle depends *only* on $(s_0)$ (not intermediate states).
- This allows parallel computation of:
- Winners (\(w_j\) for each \(\textsf{TX}_j\), \(w'\) for \(s_0\)).
- Payments/refunds.
- **MEV Capture**:
- The winner of \(\textsf{TX}_j\) captures \(V_{w_j}(\textsf{TX}_j)\) via the sandwich.
- The winner of \(s_0\) captures \(\phi_{w'}(s_0)\) via rebalancing.
- **Mitigating Ripple Effect**:
- By fixing the start/end state of each sub-bundle, transaction **ordering within the bundle becomes irrelevant**. Sub-bundles could be executed in any sequence without changing outcomes.

### **Why This Works**
Suppose two pending transactions \(\textsf{TX}_1\), \(\textsf{TX}_2\):
- **Without OpenMEV**: Executing \(\textsf{TX}_1\) first might change the pool state, reducing the MEV from \(\textsf{TX}_2\) (or vice versa).
- **With OpenMEV**:
- The sub-bundle for \(\textsf{TX}_1\) executes as:
\(s_0 \xrightarrow{\text{Front-run}} \text{Limit state} \xrightarrow{\textsf{TX}_1} \text{Post-tx state} \xrightarrow{\text{Back-run}} s_0\).
- The sub-bundle for \(\textsf{TX}_2\) starts *fresh* from \(s_0\) and resets to \(s_0\).
- The rebalancing arbitrage runs last from \(s_0\).

### Order Invariant Bundling

We can mitigate state contention on potential contentious transactions by approximating and by **decoupling transactions into isolated, state-resetting sub-bundles**. This ensures:
1. **MEV values** (\(V_i(\textsf{TX}_j)\), \(\phi_i(s_0)\)) are computed independently.
2. **Winners** can capture their MEV without interference.
3. **Refunds/payments** depend only on local auctions (not global bundle ordering).

---

## References

Michael D. Norman, , Simon Brown, Mallesh Pai, and Laurence Smith. "SPARC: Staking Performance And Reward Coopetition." (2025).