Decentralized exchanges now host a large share of crypto trading, but they are not interchangeable. A venue must choose how much of matching, custody, and settlement to leave on a public chain with open validators and permissionless listing, and how much to move off chain in order to cut fees, latency, and price impact. Uniswap sits at one pole: matching and settlement remain on chain, listing is open, and the resulting gas and slippage make many trades expensive. Hyperliquid sits at the other: a more centralized matching engine delivers much lower cost, at the price of weaker on-chain guarantees. That location on the frontier is not only a matter of price. It changes which financial transactions a venue can serve, because cheap high-frequency and derivatives flow toward the low-cost design, while permissionless spot swaps and composable on-chain strategies remain on the more decentralized design. Even for a transaction type that several venues can serve, users still split across routes. Protocol designers need to know how much cost users will bear to keep a venue decentralized, and how that willingness differs by transaction type, before they choose a design. Routers and aggregators need the same weights to send flow. Regulators need them to know whether cheaper and less decentralized venues absorb activity that was expected to remain on chain.

The project asks how users trade off the degree of decentralization of a decentralized exchange against the costs of trading there, and how that tradeoff differs across types of financial transactions and across users who face the same type. In the language of demand theory, each venue is a bundle of observed attributes, decentralization and cost among them, and a user's choice of venue and route reveals the weights on those attributes. The hypothesis is that decentralization is a valued attribute, that its weight is smaller for transaction types that the low-cost design can host more cheaply, and that residual heterogeneity in those weights still splits flow across venues that serve the same type.　The project is complete when it reports estimated preference weights on venue attributes, with the tradeoff between decentralization and cost stated as a willingness to pay in units of trading cost, separately by transaction type, together with the implied allocation of each type across venues and the residual split among venues that can serve the same type. Those objects are well defined once the choice set, the attribute measures, and the transaction-type partition are fixed, so the question has an answer regardless of the sign or size of the weights.