ethereum-reports
← Index DeFi

Propeller Heads: Tycho, Fynd, Turbine, and the Commoditization of the DeFi Trade Supply Chain

An honest look at the picks-and-shovels bet under DeFi trading: a company trying to make DEX integration a public good, push the competitive edge somewhere else, and figure out — still — where the business actually lives.

tl;dr

Table of Contents

  1. What Propeller Heads Is
  2. The Unbundling Thesis
  3. Tycho: The Stack
  4. Fynd: Open-Sourcing Your Own Edge
  5. Turbine: The Confidential Batch Bet
  6. Adoption and Traction
  7. The Business Model Question
  8. Security and Centralization Risks
  9. The Commoditization Parallel to BuilderNet
  10. Closing

What Propeller Heads Is

Propeller Heads is a research-and-infrastructure company, and the order of those two words matters. It came out of the instinct that draws quants to on-chain markets: the feedback loop is brutally fast. You can form a hypothesis about the microstructure of how token prices move on a chain in the morning, backtest it in the afternoon, and validate it by evening — a cycle that in domains like biotech can take months. That research-first posture, applied to the plumbing of DeFi trading rather than to a trading strategy, is what produced Tycho.

The product lineage is concrete. Propeller Heads started as a CoW solver — PropellerSwap — and won first place in the CoW–Balancer integration bounty. Solving on CoW is where the central observation came from: integrating DEX liquidity is repetitive, non-differentiating, and done hundreds of times across teams that all need the same thing and all hide it from each other. That observation became the thesis. The DeFi trade supply chain — every step from your wallet through the RPC, the solver, the orderbook, and the block builder — is “almost certainly” routed through multiple centralized, trusted service providers, and “exactly what we aimed to avoid” when crypto set out to be permissionless. Tycho is the answer to that, and the answer is open source.

It is worth being clear about what kind of claim that is. The framing — laid out on Deeply Intents — is careful to treat extraction not as a moral failing of the teams running those centralized intermediaries but as a structural inevitability: “The escape is not to shame teams and say you shouldn’t do this. The incentive is always there to do so if you are in the position to do so, which you are only to the extent that you are centralizing that particular part of the trade supply chain.” Extraction is an incentive problem, not a people problem. That framing is the through-line of everything Propeller builds: you do not fix the supply chain by asking nicely; you fix it by removing the positions from which extraction is possible. Open source removes the position by making the function a public good.

The Unbundling Thesis

Before Tycho makes sense, the word “solver” has to be taken apart. The most useful move — and the one Propeller leans on — is to decompose the capital-S Solver into three distinct roles, because conflating them produces wrong intuitions about both centralization and competition.

The decomposition is not academic. It changes who can enter. If solving requires no inventory, then a new solver team can enter with zero capital, leaning on market-maker quotes through composability — and a smaller market maker with a more competitive quote can win 50% of a split trade it could never have won as a monolith. The barrier to becoming a solver, then, is not capital and not risk appetite. It is the engineering grind of integrating every DEX. Remove that, and you have lowered the single largest barrier to entry in the part of the stack that is supposed to be the competitive, decentralizing layer.

Before going further it is worth pulling apart a word that does a lot of quiet bundling in this whole conversation: “open.” When Propeller says open source, three different properties get folded into one, and they come apart under pressure.

The first is open source in the literal sense — you can read it, fork it, run your own. For the Tycho indexer, simulation, and protocol SDK, this is straightforwardly true; the repos are MIT and the code is there. The second is credible neutrality — the rules privilege no participant over another and everyone can verify cheaply that this is so. This is a higher bar, because cheap verifiability is part of the definition; a thing you could in principle audit but realistically never will is not credibly neutral in practice. Self-hosting the indexer is, in Propeller’s own framing, “supported but heavy,” which means for the marginal solver — the one the unbundling thesis is supposed to empower — it is in practice a no. The third is actual decentralization — no single party’s failure or capture takes the system down. A hosted indexer sitting under ~20% of CoW flow does not clear this bar either; one operator’s outage or coercion is a slice of CoW settlement.

So the relevant question is not “can you fork it?” but “what does the marginal participant actually run, and who controls that?” A public good that everyone could self-host but nobody does has the legitimacy of open source and the power-distribution of hosted SaaS. Those are not the same thing, and the gap between them is exactly where the centralization story I return to later lives. Open source is necessary for the other two properties and sufficient for neither.

This is where the unbundling thesis becomes a decentralization argument rather than a developer-convenience argument. There is a real reason to care about the AMM layer specifically. The dependency chain runs deep: permissionless on-chain liquidity is not just about trading — it underwrites lending, leverage, and censorship resistance. “You can trace a lot of the building blocks of DeFi back down to the availability of permissionless liquidity on AMMs.” An AMM can guarantee a trade executes as long as the chain itself is uncensored; a market maker can never make that guarantee. Lending protocols build risk models on the assumption of atomically accessible on-chain depth. Replace AMMs with market-maker quotes and the whole stack gets fragile. So the thing Propeller wants to make universally, trustlessly accessible — AMM liquidity — is not an arbitrary choice. It is the load-bearing primitive.

Two microstructure claims here are worth sharpening, because both are directionally right and both are usually stated a little too cleanly.

The first is that faster block times do not meaningfully reduce loss-versus-rebalancing — “even if you have one millisecond block times, if there’s a large jump on Binance, you will still incur the LVR of that entire jump completely.” The precise version splits LVR into two pieces. There is a diffusion component — the steady, continuous drift of price between blocks — and faster blocks genuinely do cut this; the Milionis–Moallemi–Roughgarden result has the per-block diffusion loss scaling with σ²·blocktime, so halving block time roughly halves that term. And there is a jump component — the discrete gap when price moves on Binance and the AMM is stale until the next arbitrage — and faster blocks do nothing for this; you eat the gap regardless of how fast the chain ticks. The real claim, stated correctly, is that the jump component dominates for the assets that matter. That is probably true, but it is an empirical claim about the volatility structure of real tokens, not a clean law — and worth flagging as empirical rather than presenting “the entire jump” as the whole of LVR.

The second is that passive LPs have a structural cost-of-capital advantage: an ETH holder providing liquidity sees no opportunity cost, a market-neutral firm does. This is right but asset-specific. The “no opportunity cost” only holds for inventory the LP would hold anyway — the natural long-term holder of the asset. So AMMs beat professional market makers on spread for blue-chip, naturally-held assets, where there is a deep base of holders happy to be long, and they lose to MMs on the long tail, where no one wants to passively warehouse the token and LVR would shred a passive LP. Read this way the claim explains observed market structure — why blue chips price well on-chain and exotic pairs do not — rather than predicting a single winner across the board.

There is a reframe underneath both points that is more important than either: spread is the wrong scoreboard. If you measure on-chain liquidity purely by whether its quoted spread beats a market maker’s, you will miss what it is actually for. On-chain liquidity “wins” when it is the liquidity that the rest of DeFi — lending protocols, leverage, liquidations — can depend on existing under adversarial conditions. A market maker’s quote can be pulled the instant conditions turn; an AMM invariant cannot be withdrawn. That non-withdrawability is the whole reason permissionless liquidity underwrites the stack, and it is precisely the property a spread comparison cannot see. I flag all of this not because it is central to Tycho but because it tells you how the team reasons: from microstructure first, marketing second.

Tycho: The Stack

Tycho is four functionally separable pieces plus a client and a community-extension surface. The marketing calls it a framework; the more precise description is a set of components you can adopt à la carte.

The indexer. A reorg-aware streaming indexer built on Substreams — the StreamingFast / The Graph technology — that runs in two modes: native (where Tycho re-implements the protocol’s state model directly) and VM (where it tracks the contract state and lets simulation run the bytecode). It maintains protocol state as a live, reorg-aware stream rather than forcing solvers to poll RPC. The hosted version covers Ethereum, Base, and Unichain (endpoints tycho-beta, tycho-base-beta, tycho-unichain-beta), and the stated design goal is to be chain-agnostic across EVM and non-EVM. The hosted indexer requires an API key, onboarded over Telegram (@fynd_portal_bot for a base tier, DM @tanay_j to upgrade), with published rate limits of 50 req/s sustained, 300 burst, two WebSocket connections on the basic plan. Self-hosting is supported and is the right call once volume justifies it — but it is heavy, and that asymmetry matters for the centralization discussion later.

Simulation. This is the piece that earns the latency claims. Instead of reading state via RPC and asking a node “what would this swap return,” Tycho runs the protocol’s math against state it already holds — REVM for VM-mode protocols, hand-written native Rust for the ones it has ported. The cited number is ~900 nanoseconds to quote a Uniswap V2 pool, and pricing 100,000 tokens in under 30 milliseconds. The difference between “reading state via RPC” and “running the protocol’s math against state you already have” is the difference between a network round-trip per pool and a function call per pool, and at the scale of solving thousands of routes per quote, that gap is the whole game. Two capabilities here came out of Propeller’s collaboration with the Uniswap Foundation (the UF interview plus the partner listing): making Uniswap V4 hook pools tradable “in minutes” rather than after a manual integration, and Dynamic Contract Indexing (DCI), which lets the indexer pick up new contracts as they deploy rather than requiring a code change per venue. I want to be precise about the relationship: the source documents that UF presented and collaborated with Propeller on this work, but a discrete grant amount or scope is not publicly documented, so I do not assert one. The capabilities themselves are real, shipped product features regardless of how the work was funded. DCI is the structural answer to the v4 fragmentation problem — if every hook is a new venue, you cannot integrate them by hand.

Execution. This is the component to read carefully, because it is both the most consequential piece architecturally and the one carrying the BUSL license. The on-chain layer is a single, non-upgradeable TychoRouter — a plain constructor, no proxy, no diamond, no upgrade path; changing router logic means redeploy and migrate, which they have already done at least once. Per-protocol logic lives in roughly twenty thin “executor” contracts that are not standalone. The Dispatcher invokes them via DELEGATECALL, so each executor runs inside the Router’s storage, balances, and approvals; address(this) inside an executor is the Router. There is no “executor SDK” you can wire into your own contract — the only reuse path is forking source. Off-chain, a Rust encoder consumes a Solution and emits the calldata bytes the caller wraps into a transaction. New venues are added by deploying a new executor and registering it through a 3-day timelock; removal is instant (an asymmetry I return to under security). The cadence is striking: the repo was created in late 2025 and has shipped on the order of twenty tagged releases per month, including multiple breaking encoder changes and at least one critical fix. This is active post-launch development, not a frozen production artifact.

Protocol SDK. The flywheel piece. Rather than Propeller integrating every DEX, the protocol SDK lets a DEX integrate itself — ship a Substreams package for indexing, a simulation adapter (VM or native Rust), and a SwapEncoder plus executor — via pull request, and instantly become discoverable to every solver running Tycho. This breaks a genuine chicken-and-egg: a new pool used to need LPs before it could get router integrations, and integrations before it could attract LPs. Uniswap V4 hook pools are the canonical case — a custom pool self-integrates and immediately receives solver flow. There is one honest constraint baked into the design: protocols that require off-chain data such as signed prices are explicitly unsupported, which puts pure RFQ/PMM systems out of scope (even though the deployed executor list contains RFQ-suffixed entries, suggesting a hybrid pattern worth scrutiny).

Client / RPC and Tycho X. A client library and RPC surface sit on top, and Tycho X is the community-extension layer — Tycho Application Proposals (TAPs) including an Orderbook and a Price Quoter. The intent is the same as the protocol SDK: push the surface area out to the ecosystem rather than hoarding it.

The architecture, taken as a whole, is coherent and genuinely ambitious. The bet is that integration is a commodity and should be a public good, and the technical work to make that true — sub-microsecond simulation, reorg-aware streaming, self-service venue integration — is real engineering, well executed.

Fynd: Open-Sourcing Your Own Edge

Fynd is where the thesis gets interesting, because here Propeller open-sources something that looks a lot like its own competitive edge. Fynd is a route-finding engine — “run your own router” — built on top of Tycho: multi-algorithm, gas-aware, sub-100ms. It is, depending on how you squint, a solver SDK, an aggregator-API replacement, and a forkable reference implementation all at once. It is in alpha, and the contracts carry an explicit unaudited warning.

The thing that does not do honest routing in most aggregators is gas-aware path selection in real time — when the gas price is moving every block, the optimal route changes block to block, and a router that prices routes on notional output alone leaves execution quality on the table. Fynd does this properly, and the strategic point of open-sourcing it is to let third parties write the algorithms on top: MEV-aware routing, inventory-aware solvers, cross-chain pathfinding. The canonical Fynd user, in Propeller’s framing, is a team that wants production-grade routing without rebuilding it, and that may eventually layer proprietary logic on top.

But the question Fynd raises is the one that matters for the whole company: what does Propeller capture by open-sourcing the solver? If the solver loop is the differentiated work, giving it away looks like unilateral disarmament. The honest read is that Propeller is betting routing itself is also a commodity — that the durable edge is not the routing algorithm but the things around it: the liquidity surface (Tycho), the relationships (market-maker connectivity), the settlement venue (Turbine), and the data. Open-sourcing Fynd is consistent with that bet only if you believe the edge has already moved off the routing algorithm. Whether that belief is correct is, again, unsettled — and an aggregator that has spent years tuning its router would tell you it is wrong. There is a real version of the world where “honestly, just call 0x” is the right answer for most teams, and Fynd is for the minority who need to own the loop.

Turbine: The Confidential Batch Bet

Turbine is the third act and the most speculative. It is “coming soon,” so everything here is stated/intended architecture, drawn from the Turbine page and the team’s own descriptions, not from a shipped product. Read it as a design, not a fact.

The intended shape is a private batch solver running on SUAVE / TEEs. Orders are pegged to mid-price rather than competing on price improvement; they are batched at discrete intervals rather than racing continuously; and they settle against a blend of on-chain liquidity, off-chain market-maker liquidity, and peer-to-peer coincidence-of-wants matching across multiple assets at once. There is a Turbine Institutional tier behind KYC/AML whitelisting. The TEE R&D is corroborated by the org’s repositories — it holds suave-geth, suave-std, and suave-viem alongside TEE tooling like dstack, phala-cloud, and rtmr3-calculator.

The mechanism-design logic is internally consistent. Batching at intervals instead of racing returns value to users because it removes the latency contest — if everyone in the batch clears at one price, there is no advantage to being first, which collapses the priority-gas-auction surface. Pegging to mid rather than competing on price improvement makes an assumption about where toxic flow comes from: it assumes the danger is informed counterparties picking off stale quotes, not the spread itself, so it neutralizes the picking-off by clearing everyone at the unbiased reference. Matching across N assets at once surfaces coincidences-of-wants that pairwise matching cannot reach — A wants B, B wants C, C wants A clears with zero external liquidity. And a v4 hook that routes a swap through Turbine’s batch matcher is the LP-defense story: instead of an arbitrageur capturing the rebalancing value, the batch internalizes it.

The honest objection — which the team’s own framing anticipates — is that you cannot eliminate LVR; you can only move where it lives. Pegging to mid does not make the AMM’s price less stale relative to Binance; it changes who captures the difference. That is a real limit, and the steelman of Turbine is not “LVR is gone” but “the rent moves from arbitrageurs to a mechanism that returns it to LPs and users.” Whether that redistribution survives contact with reality is exactly the kind of thing you cannot know until it ships.

The deeper objection is the one the BuilderNet report makes about TEEs, and it applies here unchanged: a TEE does not remove trust, it relocates it. Running the batch matcher in an enclave moves the trust assumption to four places — (a) Intel or AMD as the silicon manufacturer whose attestation you are believing; (b) the cloud host physically running the enclave, who controls the machine; (c) the attestation and measurement-registry governance that decides which code measurements count as “the real Turbine”; and (d) the assumption that nobody mounts a physical side-channel or fault-injection attack against a box whose entire job is to hold secret order flow. That last one is sharper for Turbine than for almost any other TEE deployment, because Turbine is a machine whose entire value is the secrecy of its order flow for a few hundred milliseconds, operated by parties with a direct financial incentive to peek. TEEs defend well against remote adversaries and weakly against the operator — and here the operator is the party with the most to gain from looking. So the plain question is: who runs the Turbine enclaves, and what stops them front-running their own batch? The honest answer today is “attestation and reputation,” and reputation is not a cryptographic guarantee.

It helps to lay out the paths to the property Turbine actually wants — “no participant has a front-running advantage” — and what each one trusts:

Path Trust root Latency to “no front-running” Maturity
TEE batch (Turbine) Intel + host + attestation registry ships now-ish hardware mature, governance immature
Threshold-encrypted mempool + frequent batch auction honest-majority committee needs protocol-layer support cryptographically maturing, not deployed

The asymmetry between those two rows is the whole story. Hardware trust is a receding bet: it gets worse precisely as the prize grows and as side-channel and fault-injection techniques improve, and the prize on a successful MEV-secrecy machine only grows. Cryptographic trust is an advancing bet: threshold encryption and batch auctions get more practical and more battle-tested over time. The charitable read of Turbine is identical to the charitable read of BuilderNet — a TEE as the best available approximation while the cryptographic path matures, shipping a useful thing today rather than waiting for the ideal. If that is the framing, then the question that matters is not “is the TEE perfect” (it is not) but does Turbine have a migration path off the TEE — a credible plan to swap hardware trust for cryptographic trust as the latter matures — or is the hardware trust load-bearing and permanent? That is the thing to ask the team, and it is not answerable from the outside yet.

One naming caveat worth flagging: swap.propellerheads.xyz now redirects to app.turbine.exchange, which strongly suggests the product previously discussed as Open Swap has been folded into — or rebranded toward — Turbine. I would not assert Open Swap as a separate live product; the cleaner description is that the consumer-facing swap surface and the Turbine settlement vision now live under the same roof. Treat the product-naming as in flux.

Adoption and Traction

The headline traction figure is the Uniswap Foundation interview’s claim that “~20% of CoWSwap flow (about $1.5B monthly) is handled by solvers using Tycho.” This is the right number to cite, with the right attribution: it is interview-stated, vendor-attributed. The propellerheads.xyz/tycho page goes further — >$3B/month flow, 150ms latency, 99.8% uptime, 100% accuracy — and every one of those is vendor self-reported and not independently verified. I looked for Dune or DefiLlama corroboration and did not find it. None of this means the numbers are wrong; it means a careful reader should hold them at arm’s length until a third party measures them. The broader state-of-intents picture places Tycho squarely inside the solver economy that is the “real innovation” of the intents era — markets as computation, the Agoric vision realized — while noting that this is also the layer most vulnerable to concentration.

GitHub adoption is modest in absolute terms but consistent with infrastructure tooling, where the meaningful signal is forks-to-stars rather than raw stars: tycho-indexer at ~160 stars, tycho-simulation ~104, tycho-protocol-sdk ~37, fynd ~28. These are not viral numbers, and they should not be. Infra libraries get forked and embedded, not starred. The named integrations are the better signal: Jumper uses Propeller as a solver alongside Enso and Odos; the partner logos include 1inch, Anoma, the Uniswap Foundation, and Balancer; and the Substreams partnership with The Graph / StreamingFast underwrites the indexer. The funnel — “team tries it” to “team runs it in production” — is the standard infra adoption curve, and the honest read is that Tycho has crossed from experiment to dependency for a meaningful slice of CoW flow, on vendor-attributed evidence.

A note on funding, because it is easy to get wrong. Propeller raised a seed round around February 2023. The amount is undisclosed — the reporting is paywalled, and I will not invent a figure. Named investors are Alchemy Ventures, Delphi Ventures (Delphi Digital), Triton Capital, and WAGMI Ventures. Any “$1.25M” figure floating around belongs to a different entity and should not be attached to Propeller.

The Business Model Question

Here is the question the whole report circles. If you open-source the indexer (MIT), the simulation (MIT), the protocol SDK (MIT), and even your own solver (Fynd, alpha), where does Propeller make money?

The honest answer is that it is not resolved, and the company is open about iterating on it. There are four candidate revenue surfaces, and none is yet proven to be the answer:

  1. The BUSL router carve-out. This is the one piece that is not MIT. tycho-execution — the TychoRouter and its executors — is BUSL-1.1, converting to MIT on 2030-03-19, Licensor PropellerHeads AG. BUSL lets the source be readable and forkable for non-production use while reserving production rights for the licensor until the conversion date. In a stack marketed as open, this is the deliberate commercial moat: the contracts that sit in execution paths and could plausibly carry a fee are the ones held back. Naming this honestly matters, because the “always MIT” line elides the single component where Propeller has chosen to retain leverage.

    It is worth separating two things the BUSL discussion tends to merge: a neutrality story and an honesty story. On neutrality, the carve-out does not by itself compromise the commons — the indexer, simulation, and SDK are MIT and stay MIT, and a BUSL license on the router does nothing to the credible neutrality of those layers if the router is genuinely optional. The whole question collapses onto one empirical fact: is TychoRouter actually load-bearing for Tycho users, or is it swappable? If integrators route through it because it is the path of least resistance — the same dynamic that drives them to the hosted indexer rather than self-hosting — then BUSL is sitting on a chokepoint, and the “always MIT” framing is doing real concealment work, because the thing everyone actually depends on is the thing held back. If the router is one execution option among several and most serious solvers bring their own settlement path, then the carve-out is defensible honesty: Propeller open-sourced the commons and reserved a convenience component that nobody is forced to use. I cannot resolve this from the outside, and that is the point — “load-bearing for whom” is the open question that decides whether the BUSL line is a moat on a chokepoint or an honest reservation at the edge.

  2. Hosted-indexer tiers. The indexer is open-source, but running it well is heavy, and the hosted version is API-gated with rate limits and an undocumented upgrade path through Telegram. The implication is that higher tiers and SLAs exist and are paid, even if they are not published. Selling the convenience of not self-hosting is a legitimate model — it is the Substreams-provider model — but it is in tension with the decentralization pitch the moment ~20% of CoW flow depends on a single hosted endpoint.
  3. Turbine settlement. If Turbine ships and captures order flow, settlement is a place to earn — spread, fees, or order-flow value internalized by the batch. This is the bet that the business lives in settlement, not integration. It is also the least-proven surface, since Turbine has not shipped.
  4. Grants. Chains and DEX foundations have a direct interest in Tycho existing — the Uniswap Foundation collaboration is the clear example — and grant/foundation funding is plausible near-term runway. It is not, however, a business model; it is a subsidy for a public good, which is exactly what Tycho is.

The cleanest way to state it: Propeller has open-sourced the layers it believes are commodities and reserved the layer it believes can carry rent. Whether the reserved layer (router execution, hosted indexing, Turbine settlement) is actually where the durable value lives is the open bet. The team’s own framing on the podcast — “what does Propeller capture by open-sourcing the solver, and where in the stack do you actually intend to make the business work?” — is the question they are still answering in public.

I want to be clear that its being unresolved is not a gap in the report — it is the finding, and it is structural rather than a matter of Propeller not having figured something out yet. Whoever builds the commons faces the same condition: can they capture enough of the value they create to keep building, without compromising the neutrality that made the commons valuable in the first place? Those two goals are in direct tension, and the four revenue surfaces are just four different points on that tension. The one worth watching most carefully is the hosted indexer, because of all four it is the surface that distributes power least — it is the one where convenience quietly converts an open-source public good into a single operated dependency, and where capturing value and concentrating control are the same act rather than separable ones. The BUSL router, by contrast, can in principle leave the commons neutral if the router stays optional; Turbine settlement is a new venue rather than a chokepoint on the existing commons; grants are a subsidy, not a moat. The hosted indexer is the one where the revenue model and the centralization risk are the same fact seen from two sides. That is not a criticism of the team. It is the structural condition of any company that builds a public good and hopes to capture a fraction of the value it creates — and naming exactly which surface carries the tightest version of that tension is more useful than pretending the tension can be designed away.

Security and Centralization Risks

Three risks are worth surfacing plainly, in the spirit of an honest assessment rather than a takedown.

The audit posture is light for what the contract does. tycho-execution/docs/audits contains exactly two PDFs, both by the same independent auditor, Maximilian Krüger (snd.github.io), in early March and August 2025. There is no engagement with a top-tier firm — no Trail of Bits, OpenZeppelin, Spearbit, Sherlock, or Code4rena — and no public bug bounty was found. (Krüger’s profile at snd.github.io lists prior security work at Trail of Bits and Parity — but this is still one independent auditor, not a top-tier-firm engagement.) For a contract that holds user Permit2 allowances and sits in solver execution paths, single-auditor coverage is a real risk, not a formality. The pattern across both audits is that every cycle surfaced new bugs in the DELEGATECALL trust surface, the callback pipeline, and transient-storage hygiene — which is exactly the surface area you would want a second, independent firm to look at.

minAmountOut is a single point of trust. The only on-chain MEV guardrail on the default path is minAmountOut, and it is produced by the off-chain Rust crate, which was out of scope in both audits. The auditor’s own language on the partially-fixed HIGH finding is direct: the parameter “is still determined by the tycho-execution Rust crate, which continues to be a single point of failure, into which a lot of trust must be placed.” A supply-chain compromise of that crate — a malicious dependency update — could push minAmountOut toward zero and open users to sandwich extraction. The practical mitigation is straightforward: a serious solver should source minAmountOut from an independent oracle and not let the crate pick it. But the default is the trust, and defaults are what most integrators ship.

The hosted indexer is a shared dependency. If ~20% of CoW flow runs through solvers using Tycho, and a meaningful share of those lean on the hosted indexer rather than self-hosting, then a single Propeller-operated endpoint becomes a systemic dependency for a slice of CoW settlement. Self-hosting is supported and removes the dependency, but it is heavy enough that the path of least resistance is the hosted tier — and the path of least resistance is where concentration accumulates. This is the central irony of the whole project, and it is worth stating without flinching: a framework whose explicit purpose is to decentralize solver entry can, through the convenience of its hosted components, recentralize the dependency graph one layer down. The asymmetry in the executor registry (3-day add, instant remove) is a smaller version of the same theme — operational control concentrated in a multisig — but the indexer is the one that scales with adoption.

To be fair to Propeller: every one of these is fixable, several are explicitly the integrator’s responsibility to harden, and the team’s high release cadence shows they fix things fast. But a careful report names the trust assumptions the marketing smooths over, and these are the three.

The Commoditization Parallel to BuilderNet

Propeller’s bet has a sibling, and naming it clarifies both. The companion report BuilderNet: TEEs, Shared Flow, and the Endgame of Imperative MEV Coordination describes Flashbots’ wager that “the core boilerplate of block building will become a public utility.” Strip the domains away and the two bets are the same move: commoditize a layer of the stack, and relocate the competitive rent elsewhere.

BuilderNet commoditizes block building. The claim is that the mechanics of assembling a block — the part builders historically competed on — should be shared, open, TEE-attested infrastructure, so the edge migrates up to order-flow origination and PMM pricing and down to inventory and hedging pipes. Tycho commoditizes DEX integration. The claim is that the mechanics of accessing on-chain liquidity — the part solvers historically ground out independently — should be a public good, so the edge migrates somewhere else.

The interesting question for each is the same: where does the rent actually go once the commoditized layer can no longer hold it? For BuilderNet, the honest answer is up to whoever originates the flow and down to whoever has the best inventory, which is not obviously more decentralized than the builder duopoly it replaced — it just moves the concentration. For Tycho, the parallel answer is that solver edge migrates toward market-maker relationships, latency, proprietary algorithms layered on top of Fynd, and order flow. And none of those is obviously more distributable than the integration grind they replace. Latency favors the well-capitalized. Market-maker relationships favor incumbents. Order flow favors whoever owns the wallet. Commoditizing integration genuinely lowers the entry barrier — anyone can start solving — but it may simply relocate the winning condition to factors that concentrate just as hard.

The mechanism worth being precise about is increasing returns in the residual. Commoditizing integration removes exactly one fixed cost — the integration grind — and that cost happens to be the one with the most benign returns profile: it has increasing returns within a single firm (you integrate a venue once and amortize it across all your flow), which is precisely why it was such a moat, but it is a cost a small, smart team can pay down with engineering hours rather than capital. The honest question is whether the remaining edges have increasing returns. Run the list. Latency: increasing returns — the faster you are, the more you win, and winning funds more speed. Market-maker relationships and access to private flow: increasing returns — more volume earns better quotes, which wins more volume. Inventory and bonding capital: increasing returns — bigger balance sheets take bigger fills and survive bigger drawdowns. Routing-algorithm quality, once Fynd is open: roughly constant returns — a better algorithm is better, but it does not compound on itself the way capital and latency do. So the residual edges are dominated by increasing-returns factors, and the one constant-returns factor is the one Propeller just gave away.

Stated plainly, this is worse for the decentralization story than the simple pitch implies: commoditizing integration removes the most equalizing barrier — the engineering grind a small smart team can pay down — and leaves the least equalizing ones standing — capital, latency, and relationships. It lowers the floor for entry and does nothing to the ceiling on winning, and the ceiling is set by exactly the factors that concentrate hardest.

The good news is that this is not a vibe — it is falsifiable, and the number that settles it is computable today. Track the win-share concentration of solvers on CoW — an HHI over solver win-share — over time, before and after Tycho crossed ~20% of flow. If commoditization actually decentralizes outcomes, win-share HHI falls: more solvers win meaningful shares. If it merely relocates concentration, you will see the telltale divergence — the count of participating solvers rises (entry got easier) while win-share HHI stays flat or climbs (winning did not). CoW publishes solver-competition data, so this is a measurement, not a thought experiment. Here is the number that would prove the optimistic read right or wrong: if win-share HHI declines through the period Tycho adoption ramped, the unbundling thesis decentralized winning; if participation widened while HHI held, it relocated the rent exactly as the increasing-returns argument predicts.

That is the unresolved tension in both bets, and it maps onto a deeper axis: imperative versus declarative. Tycho and Fynd live entirely in the imperative solver world. They make the imperative loop — index, simulate, route, encode, execute as a sequence of state mutations — faster and cheaper and more open. They are, in the most precise sense, optimizations of the imperative trade loop. Turbine and the intents direction gesture at something different: declarative settlement, where a user expresses what they want and a private, verifiable mechanism produces it, rather than specifying how to get there step by step. The batch matcher pegging to mid is a declarative-flavored answer — you state your willingness to trade at the reference price, and the mechanism finds the clearing — in a way that the TychoRouter executing a specific path is not.

There is a sharp question lurking here, and it is worth ending the section with it. The intents and Anoma crowd reason in invariants — declarative guarantees about what a system will never let happen. EVM developers, by contrast, reason in transaction traces — concrete sequences of state changes they can step through. The gap between intents-as-marketed and intents-as-built is, on this read, partly cognitive: EVM-native builders do not naturally think in invariants, and asking them to is asking them to learn a foreign paradigm.

The tempting move is to call Turbine “the bridge” between these two worlds, but that framing is slightly wrong, and getting it right sharpens the whole picture. Imperative and declarative do not converge by Tycho gradually becoming declarative. They converge at a specific structural point: where ordering is removed from the application’s control. Once encrypted mempools, inclusion lists, and batch clearing exist at the protocol layer, the protocol itself guarantees the what — your trade clears at a reference price and cannot be reordered against you — and the solver’s imperative cleverness collapses down to an efficiency search inside a fixed envelope. The declarative guarantees do not migrate up into the application; they descend into the protocol. So the convergence happens not because the app layer learns to think in invariants, but because the protocol layer absorbs the guarantees that intents currently try to provide at the app layer.

That reframes where Tycho and Fynd sit, and it is a more flattering position than “imperative tools waiting to be made obsolete by declarative ones.” They are a bet that the imperative search problem stays valuable even after the protocol commoditizes ordering — and that bet is probably correct, because even in a world where the protocol guarantees fair clearing, someone still has to compute the best path across heterogeneous liquidity. That computation is irreducibly imperative: it is a search over venues and routes, not a guarantee about what cannot happen. The synthesis, then, is a clean division of labor rather than a bridge: declarative descends into the protocol (encrypted mempools, inclusion lists, frequent batch auctions), imperative search stays at the application layer (find the best route across the liquidity that exists), and Tycho is positioned for exactly that split. Turbine is Propeller’s hedge in case the protocol layer is slow to absorb those guarantees — a TEE-based way to provide batch-clearing fairness before the protocol does it natively — and Tycho/Fynd are the durable bet on the imperative half that survives regardless. Whether trust-by-hardware (a TEE you attest) can hold the line until trust-by-protocol arrives is the philosophical question underneath the whole product line, and it is unresolved by design.

Closing

The thing to credit first, because it is the most important thing, is that the core thesis is good and the team is serious. The DeFi trade supply chain is substantially centralized and trusted, the integration grind is a real and non-differentiating barrier to solver entry, and open-sourcing it is a coherent decentralization strategy rather than a marketing pose. The engineering — sub-microsecond simulation, reorg-aware streaming, self-service venue integration, an immutable router — is real and well-executed. Propeller’s reasoning, from microstructure up, is the kind of first-principles thinking that produces durable infrastructure rather than cycle-chasing products. If you want a company building picks and shovels for the part of DeFi that most needs decentralizing, this is a credible one.

The tensions are equally real, and a useful report holds both at once. The “always MIT” framing is not accurate — the one component that touches money is BUSL, held back until 2030, and that carve-out is a deliberate commercial choice that the open-source messaging smooths over. The hosted indexer is a shared dependency that can recentralize the layer below the one Tycho decentralizes. The business model is unproven — open-source everything that is a commodity, reserve what might carry rent, and hope the reserved layer is where the value actually lives. The audit posture is single-auditor for a contract in execution paths, with minAmountOut resting on an out-of-scope crate.

And the deepest open question is the one the BuilderNet parallel sharpens: commoditizing integration unambiguously lowers the barrier to entering the solver market, but it is not at all clear that it decentralizes winning it. If the edge simply relocates to market-maker relationships and latency and order flow — the factors that concentrate hardest in every market that has ever existed — then Tycho will have made it easy to start solving and no easier to matter. That would not be a failure of the technology. It would be the structural fact, the same one the intents data keeps surfacing, that lowering entry barriers and preventing concentration are different problems, and solving the first does not solve the second. Propeller has built an excellent answer to the first. Turbine is its bet on the second. Whether that bet pays — whether declarative settlement and confidential batching can hold the rent that imperative routing cannot — is the question worth watching, and it is genuinely unresolved.

Source material verified by parallel supervisor audits 2026-05-20.