Pool-bound hooks
- Live inside one liquidity venue.
- Are usually selected by the pool or asset creator.
- See only the activity that enters that venue.
- Cannot describe the user’s complete multi-program route.
JOLTWORK / INTENT HOOKS ON SOLANA
A hook is not bound to one pool. It is bound to this transaction.
Joltwork attaches settlement rules to the user’s individual trade intent. The route can cross routers, pools and token programs; the signed conditions remain with the transaction from execution to final settlement.
OFFICIAL CONTRACT ADDRESS
TBA
The official Joltwork contract address has not been published. Do not trust unofficial addresses.
A NOTE FROM THE DEVELOPER
Why I am building Joltwork.
I started Joltwork with a simple frustration: a trader can carefully choose a route, set slippage and sign a transaction, yet the promise they saw in the interface is still separate from the result that finally settles on-chain. Most tools explain the trade before it happens or analyse it after it happens. I want the promise itself to become executable.
That is why the hook in Joltwork does not belong to one pool. It belongs to one transaction. The user signs the outcome they are willing to accept—how much may leave, how much must arrive, which route may execute, when the intent expires, and which extra policy must pass. Jolt Guard surrounds the route, measures what actually changed, and lets Solana commit the transaction only when those conditions hold.
I do not want Joltwork to be another dashboard wearing protocol language. I am building the program, SDK, manifest formats and product surfaces together so the idea can be used by token creators, wallets, routers and ordinary traders. I am publishing the work as it develops because the mechanism should be inspectable, testable and improved in public.
— The Joltwork developer
Building intent-bound settlement on Solana.
IN PLAIN LANGUAGE
Joltwork turns “I expect this trade” into “only settle if this is true.”
Today, a trading interface usually shows an estimate, slippage setting and route before the wallet opens. The user signs the assembled transaction, but the promise they understood still lives mainly in interface text. If several programs, pools or token extensions affect the route, explaining the quote and enforcing the final result become two different jobs.
Joltwork joins those jobs. The wallet encodes the user’s maximum spend, minimum receive amount, permitted route and expiry into one intent. Jolt Guard runs the route and measures the real balance changes before Solana commits the transaction. The user is not asking Joltwork to find liquidity; they are asking it to reject any result outside the boundary they signed.
A SIMPLE EXAMPLE
A user authorizes spending no more than 1 SOL and receiving no fewer than 950,000 token units. Receiving 970,000 after spending 0.98 SOL passes. Receiving 940,000—or spending 1.01 SOL—fails the signed condition and the transaction reverts.
WHY THIS WORKS ON SOLANA / OFFICIAL CAPABILITIES
The runtime already provides the execution model Joltwork needs.
A Solana program can call another program through Cross-Program Invocation. The invoked route shares the same transaction’s remaining compute budget and receives only the signer and writable account privileges that the caller explicitly passes. Joltwork can therefore place Jolt Guard around a router or market instruction, run that route through CPI, reload the affected token accounts, and reject settlement when a signed postcondition is false. Because the instructions belong to one atomic transaction, a failed postcondition causes the transaction path to fail rather than leaving a partially accepted result.
Token-2022’s Transfer Hook solves a different problem. It attaches custom logic to a particular Mint and runs that logic on every transfer involving that token. Joltwork moves the hook boundary up to the complete transaction intent: one user-selected trade can cross a router, several pools and either token program, while Jolt Guard checks the final realized input and output of the route as a whole.
THE IDEA / IN PLAIN LANGUAGE
One trade. One signed promise. One atomic result.
A pool hook controls a pool. An intent hook protects the user’s selected transaction, even when the route moves through several programs.
Think of a pool hook as a rule attached to a place: whenever activity enters that pool, the pool’s rule runs. An intent hook is a rule attached to a decision: whenever this user’s specific transaction executes, the user’s rule travels with it. This is why Joltwork can protect the complete economic outcome instead of only one stop along the route.
Jolt intent hooks
- Travel with one user-authorized transaction.
- Protect maximum input and minimum output.
- Restrict route, expiry and custom policy conditions.
- Commit with a receipt or revert the whole route.
HOW IT WORKS
Declare first. Execute second. Settle only if true.
Joltwork does not invent liquidity. It wraps the route selected by the user or interface and enforces the signed economic boundary around it.
Set the outcome
The wallet defines max input, min output, expiry, route and optional policy data.
Sign the intent
A canonical manifest binds those constraints to the user and derives an intent identity.
Run the route
Jolt Guard snapshots balances and invokes the selected programs through CPI.
Commit or revert
Real balances are reloaded. Valid outcomes return a JRC1 receipt; invalid ones roll back.
For a trader, this means the interface is no longer asking them to trust a descriptive quote alone. The maximum spend and minimum receive values become part of the instruction data. For an integrator, it means an existing route can remain responsible for finding liquidity while Jolt Guard remains responsible for deciding whether the realized result is acceptable.
The receipt is important for the same reason. A successful JRC1 result records the intent identity and measured balance changes, giving wallets and indexers a direct settlement artifact instead of forcing them to reconstruct the user’s original guarantee from interface text.
Launch Coin
Create a Token-2022 asset and compile the default intent policy traders will see.
OPEN LAUNCHER →Trade with Intent
Turn route, cost, output and expiry limits into a deterministic transaction manifest.
OPEN COMPOSER →Jolt Guard
Inspect the pre-hook, CPI execution, postcondition checks and receipt format.
READ PROTOCOL →WHAT EXISTS / WHAT COMES NEXT
Building the protocol as a complete stack.
The lists below are not a decorative roadmap. They separate the mechanism already represented in source and tests from the work required to make it a production network service. I want users to be able to see that boundary clearly and watch it move as each release is shipped.
Built now
- Rust Jolt Guard program with pre, execute and post phases.
- TypeScript instruction builder and account indexing SDK.
- JLM1 launch and JOLT V1 intent compilers.
- JHK1 policy and JRC1 receipt specifications.
- Protocol CI, SDK tests and inspectable source.
- Verified Jolt Guard mainnet and devnet deployments with public Program IDs.
Shipping next
- Independent audit of the published mainnet binary and adapters.
- Wallet-side transaction assembly and signing flow.
- Production adapters for launchpads and routers.
- Independent security review and adversarial test coverage.
- On-chain policy registry and settlement explorer.
WHO JOLTWORK IS FOR
A shared settlement layer for the transaction stack.
The same intent has different value at each layer. A trader gets a real limit; a wallet gets something precise to explain; a router keeps freedom to search for liquidity; a token creator can publish a baseline policy; and an indexer receives a compact record of what actually settled.
Protect a route with explicit spend, receive, expiry and policy conditions.
Launch an asset with a default policy that interfaces can explain and strengthen.
Present the signed intent and successful receipt in language users can verify.
Continue optimizing liquidity while executing inside a user-defined boundary.
Build JHK1 programs for fees, counterparties, treasuries or application logic.
Consume JRC1 return data instead of inferring every guarantee from UI text.
COMMON QUESTIONS
The boundaries are part of the product.
Is Joltwork another AMM or a Solana explorer?
No. Joltwork is a settlement wrapper and policy interface. Existing launchpads, AMMs and routers provide liquidity; Jolt Guard enforces the user’s signed conditions around their route.
Why not attach the hook directly to every pool?
Because a user’s route may cross several programs and pools. Binding the hook to the intent gives the transaction one economic boundary from start to finish.
What happens when a condition fails?
The guard returns an error. Solana’s atomic transaction model rolls back the route, so the protected transaction does not settle partially.
Where is the official token address published?
In the official contract-address box at the top of this page, in the Markets directory and through the linked Joltwork X account. Always verify the complete Mint before interacting.
Read the mechanism, inspect the code, then try the product.
Joltwork is being built in public so every settlement rule can be traced from interface to program.