Trade Execution
4 min read
Overview
RAC does not rebalance by placing naive market orders.
Instead, the protocol uses a structured execution layer that translates portfolio changes into controlled trades. This layer is designed to move the basket from its current weights to its target weights in a way that is efficient, modular, and robust across changing market conditions.
The algorithm decides what the portfolio should become. The execution layer is responsible for getting it there.
Why Execution Is Separate
Portfolio construction and portfolio execution are different problems.
A target allocation tells you where the basket should end up, but not how to get there efficiently in live markets.
Execution needs to account for:
- available liquidity
- changing market conditions
- partial completion
- asset-by-asset coordination
- operational reliability
That is why RAC separates optimization from execution.
High-Level Design
RAC uses an intent-based execution model.
At a high level:
- The protocol determines the target portfolio.
- The required changes are translated into asset-specific trade instructions.
- External execution participants fill those instructions.
- The portfolio moves toward the new target allocation.
- Any uncompleted instructions are handled by the protocol and rolled into the next state cleanly.
This makes execution flexible without making it discretionary.
Pricing Model
RAC uses a constrained execution model rather than leaving trades open-ended.
At a high level, the protocol starts with a stricter view of acceptable execution and becomes more flexible if a trade takes longer to complete. This allows RAC to begin from a disciplined position while still adapting to real market conditions when immediate fills are not available.
The goal is not to chase every fill as quickly as possible. The goal is to balance two competing needs:
- execution discipline
- practical completion
This matters because rebalancing is a live market process. If execution is too rigid, trades may fail unnecessarily. If it is too loose, the protocol may accept outcomes that are inconsistent with the quality of the portfolio it is trying to build.
RAC’s pricing model is designed to manage that tradeoff in a structured way.
The broad intuition is simple:
- early in the process, RAC is more selective
- over time, execution becomes more flexible
- that flexibility does not expand forever
This gives the protocol a controlled path from ideal execution toward practical completion, without turning the rebalance into an unconstrained market action.
Rebalancing in Practice
When RAC rebalances, it does not think in terms of a single trade.
It thinks in terms of the basket.
Some assets need to be reduced. Others need to be increased. The execution layer coordinates those changes across the portfolio so the index can transition from one state to the next in an orderly way.
In simple terms:
- assets above target are reduced
- assets below target are increased
- the execution system manages the path between the two
This matters because portfolio rebalancing is a multi-asset process, not a one-off swap.
The Role of External Execution
RAC uses external counterparties to help carry out trades.
These participants interact with protocol-defined execution instructions rather than making portfolio decisions themselves.
That distinction is important.
They do not decide what RAC should hold. They help the protocol implement the allocation RAC has already chosen.
This creates a cleaner separation between:
- portfolio intelligence
- governance
- market execution
Deterministic Portfolio Transitions
A core goal of the execution layer is predictability.
Once RAC has decided to move from one portfolio state to another, the system should behave in a way that is legible and consistent.
That means execution is designed to be:
- asset-aware
- rule-driven
- observable
- compatible with partial completion
- resilient to ordinary market frictions
The result is a portfolio that can adapt without relying on opaque discretionary trading.
Yield-Aware Execution
Some RAC positions may be held in structures that generate passive yield.
The execution layer is built to work with that reality.
In practice, this means RAC can maintain a cleaner separation between:
- the asset exposure the index wants
- the execution path used to move into or out of that exposure
- the protocol’s internal capital efficiency
This allows the portfolio to remain operationally flexible without changing the user-facing logic of the index.
Why This Matters
Trade execution is one of the least visible parts of an index, but it has an outsized effect on outcomes.
A portfolio can have a strong allocation model and still perform poorly if its execution layer is fragile, inefficient, or operationally messy.
RAC treats execution as a core part of the product, not an afterthought.
That means building an execution system that is designed to support:
- dynamic rebalancing
- multi-asset coordination
- changing market regimes
- a portfolio that can move between risk-on and defensive states
What Trade Execution Is Not
Trade execution is not the portfolio algorithm. It is not the veto mechanism. It is not governance.
Its role is narrower:
- implement portfolio changes
- coordinate transitions between current and target weights
- support the operational side of rebalancing
- preserve consistency between portfolio intent and market action
That separation is part of what makes RAC coherent as a system.
Summary
RAC’s trade execution layer exists to turn portfolio decisions into real portfolio changes.
The algorithm decides what the optimal basket should look like. Governance can intervene when needed. The execution layer carries those decisions into the market through a structured, protocol-defined process.
The goal is simple:
move the basket efficiently, cleanly, and reliably from the current state to the next one.