Who actually fills your BTC → ETH swap? Pools, market makers, or solvers. Give me 5 minutes, and you’ll understand all three. 1. Liquidity already sits in the pool @THORChain, @Maya_Protocol, and @symbiosis_fi all rely on pre-positioned liquidity. Take BTC-to-ETH as an example. BTC and ETH liquidity is already available inside the system, so the protocol uses that liquidity to complete the swap. Deeper pools support larger orders and better pricing. @StargateFinance and @Allbridge_io use similar pooled-liquidity designs for cross-chain assets and stablecoins. 2. Market makers quote when the order arrives @Chainflip takes a more active approach with JIT liquidity. When a BTC-to-ETH order appears, market makers compete around pricing and liquidity, and the best execution gets the flow. @hashflow uses a similar market-maker model through RFQ. @SynapseProtocol also sits around this active liquidity / RFQ design space. How this works - Order appears. - Market makers compete. - User gets the best available quote. Execution quality here depends heavily on market-maker competition. 3. The user gives the outcome; solvers handle the rest The user says: “I have BTC and want ETH at the best available outcome.” Solvers then handle execution. @NEARProtocol, @AcrossProtocol, @deBridge, @mayan, @gardenfi, @RelayProtocol and @eco are all building around this idea with different architectures. The user focuses on the best result. Solvers focus on finding the best way to achieve it. Then comes the aggregator layer @lifiprotocol @RangoExchange @SwapKitPowered @THORSwap @SOCKETProtocol Aggregators search across routes and decide which execution venue receives the order flow. Wallets own the user relationship. Aggregators choose the route. Pools, market makers, and solvers compete to execute the order. More competition underneath usually means better pricing and execution for the user. Users win.