← Back to blog

Published on Fri Aug 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

The Contract

The contract went live on December 17, 2025. Block 39592189. Base mainnet.

It is a UUPS proxy. The implementation can be upgraded by the owner. The proxy address is immutable. The fee structure is fixed at the proxy level. The current implementation is version 2.1.0.

The source code is MIT-licensed. The source code is verified on Basescan. You can read every function. You can check every event. You can verify every transaction. You can trace every fee. This is intentional. For an infrastructure layer that handles institutional capital, the contract should be fully transparent. The contract should be independently verifiable. The source code on Basescan is the source of truth. If anything in this post contradicts the verified source, the source is correct.

What It Does

The flow is five steps. Each step is documented in the NatSpec comments. Each step is visible on-chain.

One. The user signs a Permit2 approval. The approval authorizes TVMExecutor to pull input tokens for this specific transaction. Single-use. Per-transaction. Not persistent. The authorization expires. The authorization is scoped to the exact swap amount. The authorization is time-limited.

Two. TVMExecutor pulls the input tokens via Permit2.

Three. TVMExecutor calls TychoRouter. TychoRouter handles the private mempool submission. TychoRouter handles the route execution. The transaction never appears in the public mempool. MEV bots cannot see it. MEV bots cannot front-run it. MEV bots cannot sandwich it. The first time anyone sees the transaction is when it is already in a finalized block.

Four. TychoRouter returns the output tokens to TVMExecutor.

Five. TVMExecutor takes exactly 9 bps of the output as protocol fee. The fee accrues to the contract. The fee can be swept to the fee recipient. TVMExecutor forwards the remaining output tokens to the user.

The user never gives TVMExecutor a persistent allowance. The Permit2 authorization is scoped to a single transaction. Capped at the exact swap amount. Time-limited. If the transaction fails, the authorization is void. If the transaction expires, the authorization is void. This is a fiduciary design. The contract cannot hold user funds between transactions. The contract cannot drain user funds between transactions.

The Fee Model

Three constants govern the fee.

uint256 public constant BPS_DENOMINATOR = 10_000;
uint256 public constant FIXED_FEE_BPS = 9; // 0.09% protocol fee (fixed, no exceptions)
uint256 public constant MAX_FEE_BPS = 50; // 0.5% absolute maximum (safety limit)

The fee is 9 bps. Not 9 bps for small swaps and 5 bps for large swaps. Not 9 bps for retail and 3 bps for institutional. Not 9 bps with a volume discount. Not 9 bps with a negotiated rate. Not 9 bps with a waiver for preferred partners. 9 bps on every swap. For every user. At every size. No exceptions.

The MAX_FEE_BPS of 50 is a safety limit. Even if the owner tried to change the fee, it could never exceed 50 bps without a contract upgrade. The safety limit is the guardrail. The guardrail is on-chain. The guardrail is verifiable.

We chose no exceptions for a specific reason. Predictable costs. Institutional treasury teams need to model their settlement costs for procurement. Government contractors need to model their settlement costs for FAR compliance. A fee structure that changes based on volume, token pair, or internal profitability calculations makes cost modeling impossible. 9 bps flat means a $100 swap costs $0.09. A $100,000 swap costs $9.00. A $1,000,000 swap costs $90. You can calculate it in your head. You can put it in a spreadsheet. You can put it in a procurement document. The number does not change.

The comparison is stark. MetaMask Swap charges 87.5 bps. Nearly 10× more. For routing through the same underlying liquidity pools. 1inch charges a dynamic fee that ranges from 0% to 1% depending on internal logic that is not transparent to the user. Paraswap is similar. The only aggregator with a lower advertised fee is Uniswap’s Auto Router, which charges 0% but only routes within Uniswap’s own liquidity and offers no MEV protection.

The construct says free. The territory says 9 bps. The construct hides the cost in dynamic fees and surplus retention. The territory puts the cost on-chain, in the source code, in the constant. The construct says trust us. The territory says verify it.

The Security Model

The contract inherits five OpenZeppelin upgradeable contracts. Each serves a specific purpose. Each is standard. Each is auditable.

UUPS proxy. The implementation logic is in a separate contract. The implementation can be upgraded by the owner. The upgrade authorization is gated by the owner’s multi-sig. No single person can upgrade the contract. No single person can change the logic.

PausableUpgradeable. Emergency shutdown. If we discover a vulnerability, we can pause the contract immediately. No further swaps execute while paused. This is a safety valve. We hope to never use it. We cannot operate without it.

ReentrancyGuardUpgradeable. Reentrancy protection on all state-changing functions. A reentrancy attack is where an external contract calls back into TVMExecutor during execution. The guard blocks reentrant calls. The guard is standard. The guard is necessary.

OwnableUpgradeable. Administrative functions restricted to the owner. Fee changes. Pauses. Upgrades. Fee sweeps. The owner is a multi-sig wallet. Not a single key. No single person can change the fee. No single person can pause the contract. No single person can sweep accumulated fees.

Initializable. The contract is initialized once. The initialization sets the owner, the fee recipient, the fee bps, and the TychoRouter address. The initialization is immutable. The initialization is verified on-chain.

Why Permit2

Traditional DEX routing requires two on-chain transactions. An approve() transaction that grants the router permission to spend your tokens. A swap() transaction that executes the trade. Both cost gas. Both require the user to hold ETH. The approval is persistent. The approval stays in effect until you manually revoke it. A compromised router can drain your funds. A buggy router can drain your funds.

TVMExecutor uses Permit2. Permit2 is a Uniswap Labs contract. Permit2 enables gasless token approvals via EIP-712 typed signatures. The user signs an off-chain message. The message authorizes TVMExecutor to spend a specific amount of tokens for a specific time window. The authorization is verified on-chain when the swap executes. The user does not pay for the verification. The gas is part of the swap transaction.

No separate approve transaction. One signature instead of two transactions. No persistent allowance. The authorization is single-use and time-limited. No ETH required for approval. The signature is off-chain. Reduced attack surface. There is no standing approval that could be exploited.

The TychoRouter Integration

TVMExecutor wraps TychoRouter. TychoRouter is Propellerheads’ private routing infrastructure. The TychoRouter address on Base is public. The TychoRouter address is verifiable on Basescan. Every swap through TVMExecutor goes through Tycho’s private mempool submission. The transaction never appears in the public mempool. The transaction goes directly to the block builder. The first time anyone sees the transaction is when it is already in a finalized block.

This is the value proposition. 9 bps flat fee. MEV-protected execution. Gasless Permit2 approvals. Fully transparent on-chain verification. The contract is open source. The fee is fixed. The security model is standard OpenZeppelin. Anyone can audit it. Anyone can verify that their swap was executed correctly by checking the transaction on Basescan.

The Contract Is Public

We chose MIT licensing. We chose full source verification. The contract handles user funds. Users should be able to verify exactly how it works without trusting our documentation. The source code on Basescan is the source of truth. The contract is at a specific address on Base mainnet. You can read every function. You can check every event. You can verify every transaction. You can trace every fee.

That is the level of transparency that institutional infrastructure requires. That is the level of transparency that government contractors require. That is the level of transparency that the construct avoids. The construct hides behind dynamic fees and private logic. The territory puts the fee in a constant. The constant is public. The constant does not change.

The line builds its own. The line puts the source on Basescan. The line says: verify it.

Launch Orkid Swap →

Related: Performance Is The New Trust Layer · We Accidentally Found a Money Printer Hidden in Base’s Liquidity Graph

Written by Jacob Cavazos

← Back to blog

Research to next step

Turn this research into a usable next move

Reading the post is only step one. The stronger move is to route it into the asset or commercial lane that matches what your team needs next.

Try it now

Swap on Orkid

9 bps flat fee, gasless, MEV-protected. Live on Base, Ethereum, and Unichain. No ETH needed — the solver pays gas.

Open swap →

Launch overview

Read the launch brief

Start with the launch brief when the team needs the fastest summary of fit, trust, and the right next route through the site.

Read launch brief →

Technical packet

Review the Protocol Packet

If the post raised technical questions, move into the packet for the forwardable version of the core framework.

Review packet →

Shortlist and fit

Use comparisons or alternatives

When the question is no longer category education but shortlist fit, use the comparison surfaces to support an honest vendor evaluation.

See comparisons →
  • ZK Proving Systems Compared: Halo2, SP1, Plonky2, and STARKs

    ZK Proving Systems Compared: Halo2, SP1, Plonky2, and STARKs

    Eight zero-knowledge proving systems compared across proving time, proof size, verification, trusted setup, and ecosystem. A developer's guide to choosing a ZK system.

  • What Is Tokenized Credit Infrastructure?

    What Is Tokenized Credit Infrastructure?

    Tokenized credit is more than putting a loan on-chain. It is a full stack: SPV, token registry, compliance layer, and distribution. Here is how it works and why ERC-6909 matters.

  • What Is Surplus in DEX Aggregation?

    What Is Surplus in DEX Aggregation?

    When an aggregator routes your swap better than the quoted price, the difference is surplus. Some aggregators keep it. Some return it. Here is why that matters for your total cost.

  • What Is MEV and How to Protect Against It

    What Is MEV and How to Protect Against It

    Maximal extractable value costs DEX users millions. Here is what MEV is, how sandwich attacks work, and the four approaches to protection — private mempools, batch auctions, intent-based execution, and threshold encryption.

  • What Is ISO 20022 and Why It Matters for Blockchain

    What Is ISO 20022 and Why It Matters for Blockchain

    ISO 20022 is the global messaging standard for payments. Here is what it is, how it works, why banks are migrating to it, and what it means for blockchain settlement.

  • What Is Intent-Based Swap Execution?

    What Is Intent-Based Swap Execution?

    Intent-based execution lets users sign a message describing what they want, and solvers compete to fill it. Here is how the model works and why it's different from traditional DEX trading.

LLM Resource Index llms.txt