Verify signer, expiry, route identity and custom policy input.
PRODUCT / INTENT COMPOSER
Intent Composer
Turn a router quote into a transaction-bound contract: who may execute, which program may run, what may leave, what must arrive and when the permission expires.
INTENT WORKBENCH
Specify the result before signing the route.
In a normal swap interface, the user sees a quote and signs a transaction assembled by the application. The quote explains what should happen, but it is not itself an on-chain rule. A Joltwork intent converts the important part of that quote into instruction data: the route that may run, the most the user will spend, the least they must receive and the slot after which permission expires.
The numbers below use token base units because that is what the Solana program verifies without rounding ambiguity. A production wallet should also display the human-readable amount beside them. Joltwork’s job is to make sure the friendly display and the integer enforced by the program refer to the same signed intent.
SIGNING AUTHORITY
not connected
The wallet authority is included in the canonical JOLT V1 intent.
INTENT ID / SHA-256
The canonical manifest and Jolt Guard constraints will appear here.
QUOTEJUPITER SWAP API V2
MAINNET PROGRAM6HfEuWvE…S3ENTY
DEPLOYED SBFSHA-256 VERIFIED
VERIFIED MAINNET DEPLOYMENT
Jolt Guard is executable on Solana mainnet at 6HfEuWvEmargNraXeqCiqCZRJ223kGjxsCB7H9S3ENTY ↗. Its ProgramData bytecode matches the published SBF SHA-256 469ab222…124ebdd.
ATOMICITY
If the route spends above the ceiling, receives below the floor, expires, or fails a selected hook, the entire Solana transaction returns an error and does not settle partially.
ATOMIC PATH
Precondition → route → postcondition → receipt.
Invoke the selected market or router through ordered CPI accounts.
Reload balances, enforce deltas and return a JRC1 receipt—or revert.
“Pre” means the route has not executed yet. Jolt Guard first checks the signer, expiry, route identity and optional policy. It then calls the selected route inside the same Solana transaction. After the route returns, “post” means the program reloads the real token accounts and measures what left and what arrived.
If the result stays inside the user’s limits, the transaction may commit and JRC1 reports the realized deltas. If it falls outside those limits, Jolt Guard returns an error. Solana’s atomic execution then discards the route’s state changes rather than leaving the user with a partially accepted trade.
SIGNED FIELDS
What an intent actually commits to.
The deterministic intent ID changes whenever any protected field changes.
These fields answer six plain questions: who approved the trade, where it may execute, how much may leave, how much must arrive, how long the approval is valid and whether any extra rule must pass. The intent ID is a fingerprint of those answers. Changing even one protected answer creates a different fingerprint and requires a fresh signature.
The wallet identity whose approval authorizes the protected route.
The selected program address prevents silent substitution of the execution venue.
Measured from the source account balance delta after route execution.
Measured from the destination account balance delta after execution.
Prevents a stale quote or route from being executed later.
Extends the base constraints through the open JHK1 interface.
FAILURE SEMANTICS
Every rejection is explicit.
Failures before execution are the cheapest and easiest to understand: a wrong signer, expired intent or substituted route means the liquidity route never runs. Failures after execution are equally important. They mean the route ran inside the transaction, but the measured result did not satisfy the signed promise.
This distinction is why the table names the checking phase. It gives wallets and support teams a precise reason to show the user instead of a generic “transaction failed” message. A production adapter should map each program error to clear interface language while preserving the underlying error code for developers.
| condition | checked at | result |
|---|---|---|
| authority mismatch | PRE | route not invoked |
| expired slot | PRE | route not invoked |
| route CPI error | EXECUTE | error propagated |
| input exceeds ceiling | POST | full rollback |
| output below floor | POST | full rollback |
| custom policy rejection | PRE / POST | full rollback |
FAQ / INTENTS
Execution questions.
Does Joltwork provide the swap quote?
No. A router or market supplies the executable accounts, data and quote. Joltwork canonicalizes the user’s accepted limits around that route. The SDK now validates and wraps official Jupiter v6 swap-instruction payloads into the ordered CPI account set; the current browser tool still compiles the intent rather than fetching and submitting the final transaction.
Can one intent cross multiple programs?
Yes, when those instructions are represented by the ordered route-account set passed to the wrapper and each invoked program is permitted by the selected policy.
What is the JRC1 receipt?
A compact return payload containing the intent identity and realized balance deltas, designed for wallets and interfaces to consume after successful execution.
Inspect the on-chain enforcement path.
See exactly where preconditions, CPI execution and postconditions run.