Displayed fees can be incomplete
Programmable hook effects can sit outside the fee categories a standard interface itemizes.
- evidence
- empirical DEX study
- risk
- quote / settlement gap
RESEARCH ORIGIN / ARXIV:2610.36682
Research Paper
The empirical research that exposed the settlement-disclosure problem Joltwork is being designed to answer on Solana.
HOW THIS PAPER RELATES TO JOLTWORK
The paper identifies the problem. Joltwork is an independent engineering response.
An Empirical Study of Undisclosed Charges in Hook-Based Decentralized Exchanges measures how programmable DEX hooks can create charges that are not itemized by standard fee displays. Its central lesson is broader than one EVM exchange: a quote shown before execution is not enough when programmable logic can change the final economic result.
Joltwork carries that insight to Solana by moving the protection boundary to the user’s complete transaction intent. Instead of trusting a pool-local label, the user commits to a maximum input, minimum output, route, expiry and optional policy. Jolt Guard then measures the balances that actually changed and permits settlement only if the signed result is true. The paper does not describe or endorse Joltwork; it is the research origin and motivation for this separate protocol design.
FROM EVIDENCE TO MECHANISM
What Joltwork takes forward.
The research motivates disclosure at execution time; Joltwork turns that requirement into a transaction-level acceptance condition.
The paper studies hook-based exchanges and asks a concrete measurement question: can programmable hooks change the economics of a swap in ways that standard fee displays do not itemize? Its contribution is evidence about that disclosure gap. Joltwork does not copy the paper’s exchange design; it takes the gap as a requirement for a different settlement interface on Solana.
The practical conclusion is simple: users should not have to infer their final cost from a list of known fee categories. They should be able to sign the maximum value that may leave and the minimum value that must arrive, then have those limits checked against the state that actually changed.
Measure the complete outcome
Wrap the selected route, reload the affected accounts and compare the realized deltas with signed limits.
- boundary
- one transaction intent
- result
- commit or revert
The comparison is not saying every hook is harmful. Programmability is useful precisely because it supports behavior that a fixed AMM cannot express. The risk appears when the interface describes only the standard fee path while other economic effects remain possible. Joltwork’s answer is to preserve programmability but make the user’s final acceptance boundary explicit and executable.
This is also why the project’s Hook is attached to one transaction intent instead of one pool. A user may cross several venues in one route. Measuring the complete source and destination balance change gives the settlement guard a route-level result rather than a pool-level estimate.
OFFICIAL ARXIV HTML / COMPLETE PAPER + ORIGINAL FIGURES
The official arXiv document below is embedded unchanged so readers can inspect the authors’ method, dataset, limitations and original figures in context. Start with the abstract and introduction for the research question, then read the methodology before treating any reported percentage as a general claim about all hook systems. The PDF and standalone HTML links remain available if the embedded reader is restricted by a browser.
See how the research becomes a Solana protocol.
The protocol page maps disclosure, constraints, execution and receipts into one complete architecture.