Documentation

ACE (Application Controlled Execution) is a framework that lets Solana protocols define their own transaction execution rules. Instead of relying on default validator ordering -- where the leader node decides transaction sequence based on fees and arrival time -- protocols can specify exactly how their transactions are sequenced, batched, matched, and filtered.

In the default Solana execution model, validators process transactions in whatever order they choose. This creates an opportunity for MEV (Maximal Extractable Value) searchers to insert their own transactions before or after yours, extracting profit at your expense. ACE changes this by giving the application control over execution, not the validator.

The term "application controlled" is key. It means the protocol itself -- the DEX, the lending platform, the perpetuals exchange -- gets to define transaction ordering rules, not the block producer. This is a fundamental shift in how Solana transactions are processed. The protocol becomes the authority on execution policy.

ACE rules are deployed through Jito BAM (Block Auction Marketplace), the infrastructure layer that connects protocols to Solana validators. When a protocol publishes ACE rules to BAM, validators that participate in the Jito network agree to respect those rules when producing blocks. This creates an enforceable contract between the protocol and the network.

BAM also integrates with TEE-based encrypted mempools (Trusted Execution Environments). Transactions are encrypted before entering the mempool, so validators and searchers cannot read transaction contents until after ordering decisions are made. This provides a cryptographic guarantee that MEV extraction is not possible, even if a validator is compromised.

MEV (Maximal Extractable Value) refers to the profit that block producers and searchers can extract by manipulating the order of transactions within a block. On Solana, MEV extraction is estimated to cost regular users $5-10 million per day -- a hidden tax on every swap, every trade, and every DeFi interaction.

Front-running is a simpler variant: a bot sees your pending transaction, submits the same trade with a higher fee to ensure it executes first, and profits from the price movement your transaction will cause. This is possible because default Solana ordering prioritizes fee-paying transactions.

Transaction reordering is the most general form of MEV. Validators or searchers rearrange transaction order within a block to maximize their own profit. This can affect liquidations, arbitrage opportunities, oracle updates, and any time-sensitive DeFi operation.

For regular users, MEV is an invisible cost. You set 1% slippage on a swap thinking that is your maximum cost, but MEV bots consistently push you to that slippage limit, extracting the difference as profit. Over time, this amounts to billions of dollars transferred from regular users to sophisticated automated systems.

Today, writing ACE rules requires deep expertise in Rust, Solana's runtime, the Anchor framework, and the Jito BAM SDK. A typical rule configuration takes 3-7 days of manual coding by an experienced Solana developer, and around 40% of Jito BAM setups fail on the first attempt due to configuration complexity, parameter mismatches, or dependency errors.

This means only well-funded protocol teams with dedicated Solana developers can protect their users from MEV. Smaller protocols, individual traders, and new projects are left exposed.

Kazt is a visual ACE rule builder. It replaces the entire manual coding process with a drag-and-drop canvas where you assemble rule blocks, connect them to define execution flow, simulate with sample transactions, and export production-ready code. No Rust knowledge required. No command-line tools. No configuration files to manually edit.

Kazt provides five fundamental building blocks that combine to form any ACE rule configuration. Each block represents a distinct phase of transaction processing. Blocks are connected on the forge canvas to define the execution pipeline -- transactions flow through each block in sequence.

You can use any combination of blocks. A minimal rule might use only a Filter and an Ordering block. A comprehensive rule set for a DEX might chain all five: Filter incoming transactions, Batch them into groups, Order within each batch, Match buy and sell sides, then apply Priority scoring for execution preference.

Each block type has configurable parameters that control its behavior. When you select a block on the forge canvas, its parameters appear in the properties panel on the right side. This section is a complete reference for every parameter available on each block type.

Parameters with enum types present a dropdown selector. Numeric parameters show a slider with min/max bounds. Boolean parameters are toggles. Address arrays open an editor where you can paste Solana public keys one per line.

The simulator is your testing ground before deploying rules to mainnet. It generates realistic sample transactions and runs them through your rule pipeline, showing you exactly how each transaction would be processed. This catches configuration errors, unexpected filter behavior, and performance issues before they affect real users.

You can run simulations with 1 to 20 transactions per run. The simulator generates a mix of transaction types: normal swaps, potential sandwich attack pairs, large transactions near size limits, and edge cases specific to your block configuration. Each simulation run produces a detailed SimulationReport.

Interpreting conflict warnings: If the simulator detects that two blocks produce conflicting results (for example, a Priority block promotes a transaction that a Filter block would reject), it generates a conflict warning. Conflict warnings do not prevent the simulation from completing, but they indicate that your rule set may behave unpredictably. Resolve all warnings before exporting for production use.

Once your rules pass validation and simulation, you can export them in two formats. The format you choose depends on your workflow and tier level.

The tier system controls access to Kazt features based on how many $KAZT tokens you hold in your connected wallet. Tiers are determined in real time -- the moment your token balance crosses a threshold, your tier updates automatically. There is no staking or locking required; simply holding the tokens in your wallet is sufficient.

The tier system exists for two reasons: (1) to align incentives between power users and the protocol, and (2) to manage backend resources. Higher tiers consume more compute (simulation, code generation, on-chain deployment), so token holding ensures sustainable infrastructure costs.

The Template Marketplace is where experienced ACE rule builders publish verified rule sets and other users purchase them. Think of it as a library of battle-tested MEV protection configurations that you can buy, load into your forge, customize, and deploy -- all without building from scratch.

Templates are priced in $KAZT tokens. The standard fee split is 95% to the seller, 5% to the protocol treasury. Whale tier sellers enjoy a reduced protocol fee of 2.5%, receiving 97.5% of each sale. This incentivizes experienced builders to create and maintain high-quality templates.

This section is for technically curious users who want to understand how Kazt is built under the hood. Kazt follows a standard modern web architecture with a Next.js frontend, a FastAPI backend, and integrations with Solana infrastructure.

+----------+    +----------+    +-----------+
|          |    |          |    |           |
|  User    +--->+  Web App +--->+  Rule     |
| (Browser)|    | (Next.js)|    |  Canvas   |
|          |    |          |    | (React    |
+----------+    +-----+----+    |  Flow)    |
                      |         +-----+-----+
                      |               |
                +-----v----+   +------v------+
                |          |   |             |
                | FastAPI  |   | Validator   |
                | Backend  |   | (conflict   |
                | (Python) |   |  detection) |
                |          |   |             |
                +-----+----+   +------+------+
                      |               |
                +-----v----+   +------v------+
                |          |   |             |
                | Postgres |   | Simulator   |
                | + Redis  |   | (test txns) |
                |          |   |             |
                +----------+   +------+------+
                                      |
                               +------v------+
                               |             |
                               | Exporter    |
                               | (JSON /     |
                               |  Anchor)    |
                               +------+------+
                                      |
                               +------v------+
                               |             |
                               | Jito BAM    |
                               | (on-chain   |
                               |  deploy)    |
                               +-------------+