# MEV-X Homelander Source: https://mev-x-project.github.io/Homelander-docs/ ## Introduction MEV-X Homelander is a post-swap, atomic MEV internalization framework for AMM pools. Every user swap creates a short-lived arbitrage opportunity as pool balances adjust — today, that opportunity is almost always captured outside the pool that created it, by external searchers, block builders, and validators. Homelander closes that gap: a post-swap hook triggers an on-chain execution layer that detects and captures the opportunity inside the same transaction as the originating swap, before it can be broadcast, bundled, or extracted by anyone outside the system. The result is a deterministic on-chain revenue channel for the pool itself, distributed to the parties who created the opportunity — the pool's deployer, its liquidity providers, and the protocol — instead of leaking to infrastructure operators uninvolved in creating that liquidity or that trade. ## Economic Impact ### Where the value goes Captured backrun profit settles on-chain, atomically, inside the same transaction as the swap that created it. Self-serve pool deployments use a standard, protocol-wide distribution configuration; exchange and protocol integrations register a distribution configuration negotiated per partner. In both cases, the pool's deployer decides how their own portion is used — kept in full, or partially redirected to the pool's liquidity providers to raise its effective APR. How each path is configured is covered in [How Profit Is Distributed](./integration-overview#how-profit-is-distributed).
```mermaid flowchart TD A0[User swap] --> A1[Pool state shifts] A1 --> A2{Homelander attached?} A2 -->|No| B1[External searcher detects the gap] B1 --> B2[Backrun executed off-pool, off-protocol] B2 --> B3["Profit leaves the system
(validator / builder / searcher)"] A2 -->|Yes| C1["Homelander is triggered
(same transaction)"] C1 --> C2["Execution layer detects and
executes the backrun"] C2 --> C3["Profit settles on-chain,
inside the pool's own economic domain"] C3 --> C4["Distributed to deployer / LPs / protocol
per configured split"] ```
A deployer who redirects part of their share to LPs sets off a compounding loop rather than a one-off payout:
```mermaid flowchart LR D1["Deployer allocates
part of their share to LPs"] --> D2["Higher effective
LP APR"] D2 --> D3["More liquidity
(TVL)"] D3 --> D4["More volume"] D4 --> D5["More backrun
opportunities"] D5 --> D6["More MEV captured
next cycle"] D6 --> D1 ```
### How we measure it Homelander's off-chain layer runs a reference MEV extractor alongside the production system — the same class of bot an external searcher would run against the same pool. Its output is never executed; it exists to compute capture-ratio: the share of the theoretically available backrun that Homelander's on-chain execution actually captures, relative to what an unconstrained external bot would have captured on the same opportunity. This turns effectiveness into a concrete, checkable number, benchmarked against a reference point on every pool. The comparison isn't a one-off calculation. The reference extractor runs continuously against the same live pools as production, so its output reflects current market conditions, not a backtest. A separate off-chain routing layer continuously reprices candidate arbitrage paths and periodically pushes the resulting route parameters into the Router's on-chain configuration — so the routes Homelander draws from at swap time stay current with the market, not fixed at deployment. Our team ran a large-scale study of this exact question — [*The Origins of MEV: Systematic Attribution of Arbitrage Opportunity Creation at Scale*](https://arxiv.org/abs/2604.27979v1) — and found that 96.7% of arbitrage opportunities are traceable to a single source transaction, the empirical basis for capturing MEV atomically, at the point it's created. ## Who It's For **Pool Deployers** Teams launching a token, running market-making operations, or operating a launchpad-style project can deploy a new pool with the Homelander plugin already attached, through a self-serve interface — no separate integration step, no custom contract work. Every swap through that pool internalizes its own backrun automatically, and the deployer's share of captured value settles directly to their wallet with no separate claim step. → [For Pool Deployers](./for-pool-deployers) **LP Providers** Liquidity providers in a Homelander-enabled pool benefit automatically when the pool's deployer chooses to share part of their allocation — reflected directly in the pool's effective APR, with no separate action required from the LP. A dedicated LP-facing distribution flow is on the roadmap; today, participation is passive, through the pool the deployer has configured. → [For LP Providers](./for-lp-providers) **DEX & Protocol Teams** DEX protocols, aggregators, and custom AMM architectures can attach Homelander at the protocol level — through a native hook or plugin, a router-wrapping proxy, or a direct contract call — without modifying core pool logic. This is a partner-managed integration path, with a distribution configuration negotiated at onboarding. → [For DEXs & Protocols](./for-dexs-protocols) **The Wider Ecosystem** Every swap through a Homelander-enabled pool trades against liquidity that compounds rather than erodes — MEV that would otherwise leave the system for validators and block builders instead strengthens the same pool's depth and pricing over time. Aggregators and routers inherit that improved liquidity automatically, and infrastructure partners — plugin marketplaces, AMM framework maintainers — can offer it as a built-in feature of their own platform, without operating any MEV infrastructure themselves. ## Documentation Map - **[Architecture](./architecture-overview)** — the on-chain contracts and off-chain modules that make up the system, how they interact, and where Homelander runs. - **[Integrations](./integration-overview)** — how each type of client connects: self-serve pool deployment, LP participation, or protocol-level integration. - **[Security](./security-overview)** — the guarantees that bound Homelander's execution, and the independent audits that have reviewed it. --- # Architecture Source: https://mev-x-project.github.io/Homelander-docs/architecture-overview/ ## System Properties Homelander operates as an adjunct execution pipeline, isolated from core AMM mechanics. When no profitable opportunity exists, the pipeline stays inactive and adds no cost to the swap. - **Atomicity** — backrun execution and settlement happen inside the same transaction as the swap that created the opportunity. There is no second transaction, no delay, no separate settlement step. - **Zero mempool exposure** — no part of the process is broadcast or observable before it executes. There is nothing for a competing searcher to see or front-run. - **No reentrancy risk** — execution conforms to the callback safety constraints of whichever AMM framework it runs on. - **Mechanism-agnostic compatibility** — the same on-chain core integrates through whichever entry point a given AMM exposes: a native hook or plugin where the framework supports one, a router-wrapping proxy or a direct contract call where it doesn't. See [Deployment Models](#deployment-models). ## On-Chain Layer Three contracts do the work, regardless of how they're triggered: **Router** Evaluates the post-swap state, selects a candidate arbitrage route, and computes the parameters for it. The Router holds its own Route Registry — the candidate routes that the off-chain layer keeps current (see [Data Flow](#data-flow)) — rather than depending on a separate storage contract. **Executor** Performs the arbitrage execution the Router selected. This is the only component that moves funds along the arbitrage path, and it does so atomically — the path either completes in full or the whole attempt reverts, with no partial state left behind. **Profit Distributor** Takes the Executor's output and settles it across the configured recipients — deployer, LPs, protocol, or caller, depending on how the pool is configured. Distribution happens in the same transaction, using standard token transfers, before control returns to the pool. The three contracts behave identically regardless of invocation source — a hook callback, a plugin, a proxy, and a direct call all reach the Router through the same interface. [Deployment Models](#deployment-models) covers each of those entry points in detail. ## Off-Chain Layer Four modules keep the on-chain core supplied with current data. None of them execute trades or touch funds — their output is either advisory (benchmarking) or a periodic write into the Router's Route Registry. **Pair / Token Monitor** Watches for new pools and tokens, tracks liquidity and volatility as they change, and runs eligibility checks before anything is considered for routing. **MEV Explorer** Measures MEV actually being extracted across the market as a whole — both Homelander-enabled pools and every other pool it can observe. This is what gives capture-ratio (below) a market-wide denominator instead of an isolated, self-reported one. **MEV Bot (benchmark)** A reference extractor that runs the same class of strategy an external searcher would run, against the same live pools Homelander operates on. It never executes anything — its only job is to establish what an unconstrained competitor would have captured, so Homelander's actual on-chain result can be measured against it: `capture_ratio = mev_captured_onchain ÷ mev_bot_would_have_captured`. **Routes Module** Builds and prioritizes candidate arbitrage routes and the parameters for them, then periodically writes the result into the Router's on-chain Route Registry. This is the only off-chain module with on-chain write access, and it's a narrow one: it updates route candidates, nothing else. ## Data Flow **On-chain, per swap.** The sequence below is what happens inside a single transaction, regardless of which entry point triggered it:
```mermaid sequenceDiagram participant U as User participant P as Pool participant Tr as Trigger participant R as Router participant E as Executor participant D as Profit Distributor U->>P: swap P->>Tr: post-swap event Tr->>R: evaluate(pool state) R->>R: check Route Registry for a candidate route alt profitable route found R->>E: execute(route, params) E->>E: run arbitrage path atomically E-->>R: profit, profitToken R->>D: distribute(profit) D-->>R: settled else no profitable route R-->>Tr: no-op end Tr-->>P: return control P-->>U: swap output, unaffected either way ```
The "no profitable route" branch is the common path, and the pipeline is designed around it. Some swaps don't create a large enough gap to be worth capturing, and the pipeline is built to exit that branch cheaply, without touching the user's swap. **Off-chain, continuously.** The Route Registry that the Router reads from doesn't populate itself — it's kept current by a separate, always-running pipeline:
```mermaid flowchart LR M["Pair / Token
Monitor"] --> X["MEV
Explorer"] X --> B["MEV Bot
(benchmark)"] B --> RM["Routes
Module"] RM -->|periodic write| RR[("Route Registry
(on-chain, inside Router)")] ```
The distinction that matters here: everything left of the arrow into `Route Registry` is off-chain, advisory, and continuous. The moment it crosses into the Router, it becomes the on-chain state the sequence diagram above reads from at swap time. ## Deployment Models The on-chain core stays fixed, while how it attaches to a pool varies by mechanism. Four mechanisms exist today, each named for how it attaches to a pool. **Permissionless self-serve factory** A factory contract that anyone can call to attach a dedicated, per-pool plugin instance at the moment a pool is created — no coordination with any team required. Pool Deployers use this path: a deployer creates a pool and it arrives with Homelander already attached. Currently implemented for Uniswap v4-style singleton architectures, where each pool gets its own upgradeable proxy instance and its recipient wallet can be reassigned later without redeploying. (The specific hook permissions this requires — `BEFORE_SWAP`, `AFTER_SWAP`, `AFTER_INITIALIZE` — are a Uniswap v4 implementation detail specific to this one mechanism.) **Framework-native plugin attachment** Where an AMM framework exposes its own plugin-attachment surface, a protocol operator attaches Homelander through that framework's own mechanism rather than a Homelander-specific deployment path — the exact steps and who's authorized to take them vary by framework. DEX & Protocol Teams running on frameworks with this kind of surface use this path; see Plugin-Based Integration for how attachment works per framework. **Native per-framework plugin** For AMM frameworks with a hook or plugin surface but no marketplace layer, Homelander ships a dedicated plugin implementation for that framework specifically, deployed and attached by the protocol operator. Also a DEX & Protocol Teams path — the difference from the marketplace model is installation mechanics, not the client it serves. **Proxy-wrapper / direct call** For AMMs or custom protocols with no native hook surface at all, Homelander attaches through a contract that wraps the existing router, or is invoked directly from the calling contract. This covers DEX & Protocol Teams whose architecture doesn't expose a hook — including aggregators and custom-routing protocols. None of the four is chain-specific. Homelander runs on any EVM chain that supports the relevant AMM framework, and deploys to a new chain on request. --- # Integrations Overview Source: https://mev-x-project.github.io/Homelander-docs/integration-overview/ Homelander connects to a pool through one of three relationships, depending on who's setting it up and what they're allowed to do. This page maps each one to how it works and where the value goes; the pages under each cover the technical detail. ## The Three Paths | | Pool Deployers | LP Providers | DEX & Protocol Teams | |---|---|---|---| | Action | Deploy a new pool with Homelander already attached | Add liquidity to a pool where Homelander is already attached | Attach Homelander to an existing protocol's pools | | Access | Permissionless | Nothing to configure | Depends on mechanism — permissionless to role-gated | | Start here | [For Pool Deployers](../for-pool-deployers) | [For LP Providers](../for-lp-providers) | [For DEXs & Protocols](../for-dexs-protocols) | ## How Profit Is Distributed Every path settles through the same on-chain Profit Distributor (see [Architecture](../architecture-overview)) — the mechanism doesn't change based on how a pool got its Homelander plugin. What changes is how the split itself is configured: - **Self-serve pool deployments** use a standard, protocol-wide distribution configuration set at the moment the pool is created. The recipient wallet can be reassigned later without redeploying anything. - **DEX and protocol integrations** register a distribution configuration at onboarding, negotiated per partner and tied to their own protocol rather than a single pool. In both cases, the swap itself settles atomically, inside the same transaction that created the profit, and is never delayed by the distribution process. Captured profit is never lost — if a distribution attempt fails, funds remain held by the Profit Distributor rather than reverting or disappearing, and go out on a later successful distribution. --- # For Pool Deployers Source: https://mev-x-project.github.io/Homelander-docs/for-pool-deployers/ Deploying a pool with Homelander attached is a self-serve, permissionless process on Uniswap v4 — no coordination with any team, no approval step. In practice, most deployers won't construct these calls by hand; a wizard interface handles the sequencing for them. This page describes what happens underneath it. ## The Flow
```mermaid sequenceDiagram participant D as Deployer participant F as Plugin Factory participant PM as PoolManager loop mine a valid salt (off-chain) D->>F: computePluginAddress(salt) F-->>D: predicted plugin address end D->>F: createPlugin(currencies, fee, tickSpacing, dynamicFee, vault, salt) F->>F: deploy a dedicated proxy at the mined address F->>F: configure the pool's distribution split F-->>D: plugin live — PluginCreated emitted D->>PM: initialize(poolKey with hooks = plugin) PM->>F: afterInitialize callback Note over D,PM: must happen after createPlugin —
calling an address with no contract deployed yet fails ```
Two details worth understanding, because they're easy to get wrong if you're constructing these transactions yourself: **The plugin's address isn't arbitrary.** Uniswap v4 encodes which lifecycle callbacks a hook uses directly into its own address. Homelander's plugin needs a specific bit pattern set, so finding a usable address means trying candidates off-chain — `computePluginAddress` lets you check one without spending gas — until one matches, then deploying at exactly that address via `createPlugin`. This is standard Uniswap v4 hook-deployment practice, not something Homelander-specific, but it does mean plugin creation is mine-then-deploy, not a single guessable call. **Plugin creation and pool initialization are two separate steps, in a fixed order.** `createPlugin` attaches Homelander to a pool identity and configures its distribution split — it doesn't create the Uniswap v4 pool itself. That's a separate call, to Uniswap's own `PoolManager.initialize`, using a pool key whose hook address points at the plugin. It has to come after `createPlugin`: pool initialization calls into the plugin as part of its own sequence, and there's nothing to call into until the plugin exists. ## After Deployment Once both steps complete, the pool is live, and Homelander evaluates every swap through it for a backrun opportunity automatically — no further setup, nothing to maintain. **The recipient wallet isn't permanent.** `updateVault` lets the same address that ran `createPlugin` for a given pool reassign where its share of captured value settles, at any point, without redeploying anything. It's scoped to whoever created that specific pool's plugin — nobody else can call it. **Fee configuration is a per-pool choice, not a fixed default.** `createPlugin` takes the pool's base fee and Homelander's dynamic-fee override as independent parameters, set at creation time — dynamic fees aren't automatic, they're opted into per pool. For how captured value is split once it's distributed, see [Integrations Overview](../integration-overview). --- # For LP Providers Source: https://mev-x-project.github.io/Homelander-docs/for-lp-providers/ There's no integration step here, because there's nothing for an LP to integrate. Liquidity providers interact with a Homelander-enabled pool exactly like they would any other pool — same deposit flow, same tooling, no approvals granted to any Homelander contract. ## What Changes For You Whether a pool's captured MEV reaches its LPs depends entirely on a choice its deployer made, not on anything you do. If the deployer directed part of their share back to LPs, it shows up as elevated yield on that pool, distributed the same way trading fees already are. If they didn't, the pool behaves exactly like a pool without Homelander at all, from an LP's perspective — nothing about the mechanics of providing liquidity is different either way. There's no separate claim button and no LP-facing contract to interact with. Whatever reaches LPs arrives through the pool's existing fee-accrual mechanics, because that's precisely where it's directed. See [Where the Value Goes](../#where-the-value-goes) in the Overview for the underlying mechanism and the flywheel diagram behind why a deployer might choose to share in the first place. --- # For DEXs & Protocols Source: https://mev-x-project.github.io/Homelander-docs/for-dexs-protocols/ Attaching Homelander to an existing protocol's pools takes one of three forms, depending on what your AMM architecture already exposes. All three settle through the same on-chain core (see [Architecture](../architecture-overview)) and provide the same execution guarantees — atomic, no mempool exposure, no effect on the user's swap output regardless of whether a profitable opportunity exists. What differs is the entry point, and who's allowed to use it. | Path | Requires | Access | Best fit | |---|---|---|---| | Plugin-Based | A native hook/plugin surface | Depends on mechanism | AMMs with lifecycle hooks already built in (Algebra Integral, PancakeSwap Infinity) | | Universal DEX | A router to wrap | Permissionless | DEXs without a native hook surface | | Direct Contract | A calling contract that constructs its own arbitrage route | Permissionless | Custom protocols, aggregators, advanced or conditional execution | → [Plugin-Based Integration](../plugin-based) → [Universal DEX Integration](../universal-dex) → [Direct Contract Integration](../direct-access) Uniswap v4 isn't listed above — a protocol team integrating on Uniswap v4 uses the same permissionless factory covered under For Pool Deployers. That path doesn't distinguish between an individual deployer and a protocol team; it's open to both the same way. ## Getting Started Partner-specific configuration — distribution setup, onboarding for a plugin marketplace listing where relevant — is handled directly with the MEV-X team. Reach out with which of the three paths fits your architecture, and to get your distribution configuration registered. Contact: [t.me/ex_seoeva](https://t.me/ex_seoeva) --- # Plugin-Based Integration Source: https://mev-x-project.github.io/Homelander-docs/plugin-based/ Plugin-based integration attaches Homelander through the AMM's own hook or plugin surface — no proxy, nothing wrapping the pool. Two frameworks support this today: Algebra Integral and PancakeSwap Infinity. ## Algebra Integral Algebra Integral supports two distinct, officially supported ways to attach a plugin to a pool. Both end at the same place — a live plugin evaluating every swap — but they differ in who can do it and when. **Manual attachment (`setPlugin`)** is the production path for existing pools, and how live partner integrations connect today.
```mermaid flowchart TD Start["Pool already exists"] Start --> S1["setPlugin(pluginAddress)
caller needs POOLS_ADMINISTRATOR_ROLE"] S1 --> S2["setPluginConfigToPool()
called by the plugin's owner"] S2 --> Live["Plugin live —
evaluating every swap"] ```
Two separate calls, from two authorities that don't have to be the same address: whoever holds the administrator role on the pool's Algebra factory attaches the plugin, then the plugin's own owner activates it. The pool enforces the order itself — activation fails until attachment has already happened. **Automatic attachment (Default Plugin Factory)** is the second mode Algebra Integral supports natively: a factory registered with an Algebra deployment can attach a plugin to every new pool at the moment it's created, without a separate `setPlugin` call. This is a real extension point in Algebra's own architecture, not a Homelander-specific workaround — where it's configured, attachment happens automatically alongside pool creation (activation is still a distinct step either way). This mode is part of Algebra's architecture; Homelander's own implementation of it is not yet part of the actively-maintained integration path documented on this site. Confirm production availability directly with the MEV-X team before relying on it. ## PancakeSwap Infinity PancakeSwap Infinity attaches differently, and more simply. There's no address-mining requirement the way Uniswap v4 has, and no separate activation call at all — the plugin address goes directly into the pool's key, and initialization validates and activates it in one step: ``` PoolKey { currency0, currency1, hooks: HOMELANDER_PLUGIN_ADDRESS, poolManager: CL_POOL_MANAGER, fee, parameters: encodeCLParameters(tickSpacing, hookPermissions) } ``` Calling `initialize` with this key deploys the pool and activates Homelander in the same transaction — there's nothing to do afterward. ## Monitoring Both paths settle through the on-chain Profit Distributor. Whether a given settlement emits a distribution event, and its exact schema, depends on which distributor configuration your integration is registered against — get current specifics from the MEV-X team when you register your configuration, so your monitoring matches what your integration actually emits. --- # Universal DEX Integration Source: https://mev-x-project.github.io/Homelander-docs/universal-dex/ The Universal integration path enables MEV capture for DEX protocols that don't expose a native hook or plugin interface. A proxy contract wraps the existing router: the proxy executes the swap through the underlying DEX and triggers the Homelander backrun within the same transaction. No modifications to the underlying pool contracts are required. ## How It Works
```mermaid sequenceDiagram participant U as User participant P as HomelanderSwapProxy participant R as Underlying router participant H as Homelander U->>P: swap call P->>R: execute swap via underlying router P->>H: triggerBackrun(poolId, amountIn, direction, recipient, configId) alt profitable opportunity exists H->>H: execute backrun atomically else no opportunity H-->>P: no-op end P-->>U: swap output, unaffected either way ```
If no profitable opportunity is found, the backrun step is skipped and the swap completes normally — the user's output is unaffected in either case. ## Integration Steps Deploy `HomelanderSwapProxy` with the target router address — one proxy per router. Route swaps through the proxy instead of calling the router directly, passing `poolId` and `configId` alongside the standard swap parameters. The proxy doesn't retain token balances between transactions; any leftover amounts are returned to the caller. ## Monitoring ``` event BackrunExecuted: poolId (indexed) recipient (indexed) profit profitToken configId (indexed) ``` Filter by pool ID or config ID to track revenue from specific pools. --- # Direct Contract Integration Source: https://mev-x-project.github.io/Homelander-docs/direct-access/ Direct integration lets any smart contract invoke the Homelander backrun trigger explicitly, after completing its own swap logic. This path suits protocols with custom architectures, aggregators, or any scenario that needs conditional or parameterized MEV capture. ## How It Works
```mermaid flowchart TD A["Protocol's swap completes"] --> B["Protocol contract calls
homelander.triggerBackrun(...)"] B --> C{Homelander evaluates
updated pool state} C -->|profitable| D["Executes backrun,
distributes profit"] C -->|not profitable| E["Returns without side effects"] ```
The call must be wrapped in error handling so that a failed or unprofitable backrun doesn't revert the outer transaction: ``` after swap completes: try: homelander.triggerBackrun(poolId, amountIn, direction, recipient, configId) catch: continue // swap is unaffected ``` Omitting the try/catch means a failed backrun propagates and reverts the caller's own transaction — this is the one integration requirement that's non-negotiable. ## triggerBackrun Parameters ``` poolId — identifier of the pool that completed the swap amountIn — swap input amount, used to size the backrun direction — swap direction (token0 → token1, or token1 → token0) recipient — address that receives the protocol's share of backrun profit configId — distribution configuration registered for your protocol ``` ## Configuration `configId` identifies the revenue distribution settings registered for your protocol at integration time — it determines how backrun profit is allocated between the exchange, its users, and MEV-X. A single config can apply across all your pools, or separate configs can be registered per pool if different ratios are needed. Contact the MEV-X team to register a configuration before deployment. --- # Security Overview Source: https://mev-x-project.github.io/Homelander-docs/security-overview/ ## Guarantees Homelander operates strictly as a consumer of post-swap state — whichever entry point it's attached through (hook, plugin, proxy, or direct call — see [Deployment Models](../architecture-overview#deployment-models)), it never performs privileged actions against the pool itself. Its safety profile is bounded by that entry point's own guarantees: if the underlying AMM framework's hook or callback system is secure, Homelander's integration doesn't introduce a new attack surface on top of it. - **Isolated from the user's swap.** If no profitable opportunity exists, execution reverts or no-ops without touching the user's swap logic. The user receives the expected swap output regardless of whether Homelander captured anything. - **No mempool exposure.** Profitability checks, execution, and settlement all happen on-chain, inside the same transaction boundary. Nothing in the process is broadcast or observable before it executes. - **Scoped access.** Homelander's contracts accept callbacks only from authorized pools and enforce token and route constraints at execution time — they don't accept arbitrary instructions from arbitrary callers. - **No new trust assumptions.** Homelander doesn't modify the AMM's own trust model or introduce entry points beyond the ones documented under [Deployment Models](../architecture-overview#deployment-models). One caveat, for completeness: some plugin implementations enforce a minimum gas-remaining check before running their post-swap logic, configurable by the plugin's owner. By default this check always passes — but if an owner raises it, a swap without enough gas headroom left could fail because of that check specifically. This is an owner-configured parameter, not a fixed property of the system, and worth knowing about rather than discovering by surprise. ## Audits Homelander has undergone three independent security audits, across two firms, covering both its Uniswap v4 and Algebra Integral implementations. No critical or high severity findings survived any of the three; every medium finding was resolved before deployment. | Auditor | Scope | Result | |---|---|---| | MixBytes | Uniswap v4 hook | 0 critical/high, 3 medium (resolved) | | Bailsec | Algebra plugin | 0 vulnerabilities found | | Bailsec (differential) | Algebra plugin, post-update changes | 0 critical/high, 2 medium (resolved) | → [MixBytes Audit](../mixbytes) → [Bailsec Audit](../bailsec) → [Bailsec Differential Audit](../bailsec-differential) --- # Bailsec Audit Source: https://mev-x-project.github.io/Homelander-docs/bailsec/ MEV-X Homelander has undergone an independent security audit conducted by Bailsec, focused on the correctness and safety of its on-chain execution logic. The audit reviewed the Homelander smart contract implemented in Solidity and designed to operate as a post-swap component within AMM architectures that support lifecycle hooks. The assessment was performed through manual code review and evaluated the contract's behavior in the context of post-swap execution. ## Audit Scope The audit focused on: - Post-swap execution flow and hook invocation logic - Internal MEV-related execution paths and control flow - Access control assumptions and privilege boundaries - Failure handling and revert behavior - Interaction with AMM state after swap completion ## Results No security vulnerabilities were identified in the reviewed contract. All reported observations were non-exploitable and related to general design assumptions or operational considerations rather than to flaws in execution logic. The audit confirms that: - The contract does not introduce execution paths that allow unauthorized access to or extraction of pool funds - Internal MEV execution remains isolated from the user swap flow and does not affect swap correctness - Scenarios with no valid internal backrun are handled without reverting the user transaction - Administrative controls allow the component to be disabled or removed by protocol governance without impacting trading functionality ## Reports - **Full audit report:** [Bailsec – MEV-X – Plugin – Final Report](https://github.com/bailsec/BailSec/blob/main/Bailsec%20-%20MEV-X%20-%20Plugin%20-%20Final%20Report.pdf) - **Technical audit summary:** [Medium](https://medium.com/@MEV-X/homelander-security-audit-summary-and-outcomes-a1847828f730) --- # Bailsec Differential Audit Source: https://mev-x-project.github.io/Homelander-docs/bailsec-differential/ MEV-X Homelander has undergone a second independent security audit conducted by Bailsec, focused on the correctness and safety of its on-chain execution logic. The audit was structured as a differential review, covering the changes introduced in the updated Homelander Algebra plugin relative to the previously audited version. The assessment was performed through manual code review and evaluated the updated contract's behavior in the context of pre-swap fee control, post-swap execution, and plugin fee settlement. ## Audit Scope The audit focused on: - `beforeSwap` hook logic for dynamic fee override and plugin fee handling - `afterSwap` execution flow and arbitrage trigger control - Plugin fee settlement via `handlePluginFee` - Access control assumptions and privilege boundaries - Failure handling and revert behavior - Interaction with Algebra pool state across all three hook entry points ## Results No critical or high severity vulnerabilities were identified in the reviewed contract. Two medium severity findings were identified and fully resolved prior to deployment. All low severity and informational observations were either fixed or acknowledged, and none affect the correctness of swap execution or the safety of pool funds. The audit confirms that: - The contract does not introduce execution paths that allow unauthorized access to or extraction of pool funds - Internal MEV execution remains isolated from the user swap flow and does not affect swap correctness - Scenarios with no valid internal backrun are handled without reverting the user transaction - Administrative controls allow the component to be disabled or reconfigured by protocol governance without impacting trading functionality ## Reports - **Full audit report:** [Bailsec – MEV-X – Differential – Final Report](https://github.com/bailsec/BailSec/blob/main/Bailsec%20-%20MEV-X%20-%20Differential%20-%20Final%20Report.pdf) - **Technical audit summary:** [Medium](https://medium.com/@MEV-X/homelander-security-audit-by-bailsec-summary-and-outcomes-04523eb5096b) --- # MixBytes Audit Source: https://mev-x-project.github.io/Homelander-docs/mixbytes/ MEV-X Homelander has undergone an independent security audit conducted by MixBytes, focused on the correctness and safety of its on-chain execution logic. The audit reviewed the Homelander smart contract implemented in Solidity and designed to operate as a post-swap component within AMM architectures that support lifecycle hooks. The assessment combined manual code review, pair auditing of complex execution paths, proof-of-concept development and fuzzing tests using Foundry, and static analysis via Slither and Mythril, evaluating the contract's behavior in the context of post-swap execution. ## Audit Scope The audit focused on: - Post-swap hook invocation logic and callback correctness - Failure propagation across external dependencies - Configuration-induced denial of service scenarios - User-driven disruption of arbitrage execution - Access control assumptions and privilege boundaries - Interaction with Uniswap v4 pool state after swap completion ## Results No critical or high severity vulnerabilities were identified in the reviewed contract. Three medium severity findings were identified and fully resolved prior to deployment. All reported low severity observations were either fixed or acknowledged, and none affect the correctness of swap execution or the safety of pool funds. The audit confirms that: - The contract does not introduce execution paths that allow unauthorized access to or extraction of pool funds - Internal MEV execution remains isolated from the user swap flow and does not affect swap correctness - Scenarios with no valid internal backrun are handled without reverting the user transaction - Administrative controls allow the component to be disabled or removed by protocol governance without impacting trading functionality ## Reports - **Full audit report:** [MixBytes public audits – MEV-X / Homelander](https://github.com/mixbytes/audits_public/tree/master/MEV-X/Homelander) - **Technical audit summary:** [Medium](https://medium.com/@MEV-X/homelander-security-audit-uniswap-v4-summary-and-outcomes-9352b029dce5) --- # Links and Contacts Source: https://mev-x-project.github.io/Homelander-docs/links-and-contacts/ ## Partnerships & Protocol Integrations Self-serve pool deployment and LP participation need no contact with anyone — see [For Pool Deployers](../for-pool-deployers) and [For LP Providers](../for-lp-providers). Attaching Homelander to an existing DEX or protocol is partner-managed; reach out to get your integration path and distribution configuration set up. Contact: [t.me/ex_seoeva](https://t.me/ex_seoeva) ## Official Channels - **Website:** [mev-x.com](https://www.mev-x.com/) - **X (Twitter):** [x.com/MEV_X_project](https://x.com/MEV_X_project) - **Telegram:** [t.me/MEV_X_ann](https://t.me/MEV_X_ann) - **Medium:** [medium.com/@MEV-X](https://medium.com/@MEV-X) - **Email:** info@mev-x.com ## For LLMs This site's diagrams render client-side, so a raw fetch of any page returns text without them. The files below carry the full documentation as plain text instead, diagrams included as readable source — for LLMs and other tools reading the site programmatically. - **Full text (all pages):** [llms-full.txt](pathname://../llms-full.txt) - **Index with page summaries:** [llms.txt](pathname://../llms.txt)