Describes token identity, launch route and the default policy interfaces should disclose.
PROTOCOL / COMPLETE ARCHITECTURE
Joltwork Protocol
Joltwork is an intent-bound settlement protocol for Solana. Jolt Guard is its on-chain enforcement program; JLM1, JOLT V1, JHK1 and JRC1 are the interfaces that connect issuers, wallets, routes, policies and receipts.
PROTOCOL AT A GLANCE
From an issuer’s baseline to a trader’s realized result.
The protocol does not replace a launchpad, wallet or liquidity router. It gives those systems one shared language for declaring and enforcing a transaction outcome.
Joltwork separates declaration from enforcement. A creator can publish a baseline when a token launches; a trader can turn a specific quote into stricter transaction terms; a wallet can explain those terms; and Jolt Guard can enforce the final result around the selected route. No single interface has to be trusted to remember what the user accepted.
The six components below are not six separate products. They are stages of the same lifecycle. JLM1 starts with an asset, JOLT V1 describes one trade, Jolt Guard executes it, JHK1 adds optional policy logic, JRC1 reports what settled, and the SDK lets applications assemble and read those formats consistently.
Binds authority, route, input ceiling, output floor, expiry and optional policy data.
Checks preconditions, invokes the route through CPI and verifies realized balance deltas.
Allows an external program to accept or reject before and after route execution.
Returns the intent identity and measured input/output for wallets and indexers.
Deduplicates accounts, encodes indexed routes and decodes successful receipts.
SPECIFICATION
PUBLISHED IN REPOSITORY
PROGRAM + SDK
IMPLEMENTED / 14 TESTS
DEVNET PROGRAM ID
3gAqr1U9…K2knfVG
MAINNET PROGRAM ID
6HfEuWvE…S3ENTY
VERIFIED MAINNET + DEVNET DEPLOYMENTS
Jolt Guard is executable on Solana mainnet at 6HfEu…S3ENTY ↗ and on devnet at 3gAqr…K2knfVG ↗. Both ProgramData accounts match SBF SHA-256 469ab222…124ebdd; the deployment manifests publish their exact identities and authorities.
A TRANSACTION IN PLAIN LANGUAGE
The router finds a path. Joltwork decides whether its result is acceptable.
Suppose a wallet finds a route that may spend up to 1 SOL to buy a token. The user accepts only if at least 950,000 token units reach the destination account before a chosen expiry slot. The wallet encodes those limits and the selected route program into JOLT V1, then asks the user to sign.
Jolt Guard records the source and destination balances, runs the router through CPI and reads the balances again. Spending 0.98 SOL and receiving 970,000 units passes. Spending 1.01 SOL or receiving 940,000 units fails. The program is not judging whether the quoted price was “good”; it is enforcing the exact boundary the user authorized.
CORE MECHANISM / JOLT GUARD
Mint policy and transaction intent are complementary.
A Token-2022 Transfer Hook follows a mint. It is chosen by the issuer and runs whenever that token is transferred, regardless of which user initiated the transfer or why. That makes it useful for token-level behavior, but it cannot express the complete economic promise of a route involving several programs and assets.
A Jolt Intent Hook follows one user-approved transaction. It can protect a route that touches a router, multiple pools and either token program, because the final check looks at the complete realized input and output. The two mechanisms can coexist: a route may encounter a mint hook, while Jolt Guard still enforces the trader’s overall limit.
Token-2022 Transfer Hook
Belongs to the mint and runs on each transfer. The issuer chooses it when the mint is created.
- scope
- one mint
- authority
- issuer
- trigger
- every transfer
Jolt Intent Hook
Belongs to one user transaction and protects a route across multiple programs, pools and token programs.
- scope
- one route intent
- authority
- trader
- trigger
- selected execution
The phase table below describes where a failure occurs. PRE rejects an invalid authorization before liquidity moves. EXECUTE propagates an error from the selected route. RELOAD reads the post-route token state. POST compares the realized result with the signed limits and runs any final policy. RETURN produces a compact receipt only after every condition succeeds.
| phase | on-chain action | failure effect |
|---|---|---|
| PRE | validate signer, expiry, route and optional policy program | route never executes |
| EXECUTE | invoke ordered route accounts through CPI | route error propagates |
| RELOAD | read classic SPL or Token-2022 account balances | invalid owner rejected |
| POST | enforce max input, min output and custom hook result | transaction rolls back |
| RETURN | emit JRC1 intent id, realized input and output | portable proof |
POLICY MODULES
Policies are composable programs.
The base protocol always protects authority, expiry, route identity, maximum input and minimum output. A policy module is for rules that are important to a particular application but should not be permanently hard-coded into Jolt Guard—for example an approved-route registry or a ceiling on additional token-level fees.
A policy does not receive unlimited authority to rewrite the trade. It receives the declared phase and its assigned accounts and data, then either accepts or returns an error. This keeps the core settlement invariant small while allowing applications to add rules that can be independently inspected and upgraded.
Reject when realized input exceeds the signed ceiling.
Reject when destination growth falls below the floor.
Accept only approved router or market identities.
Constrain Token-2022 economic effects.
Apply treasury or jurisdiction-specific rules.
Pass an opaque payload to any JHK1 program.
SECURITY MODEL
Small invariants at the settlement boundary.
The wrapper measures realized state rather than trusting quoted or simulated output.
Security starts by narrowing what Jolt Guard promises. It can prove that the authorized route stayed inside measurable token-account limits; it cannot make an illiquid market liquid, verify an issuer’s marketing claims or protect a compromised wallet key. Keeping those boundaries explicit prevents a settlement guard from being mistaken for a universal token-safety system.
Enforced by Jolt Guard
- Authority, expiry and route program validation.
- Classic SPL and Token-2022 account ownership checks.
- Integer balance deltas with checked arithmetic.
- Maximum input and minimum output postconditions.
- Policy hook rejection propagation.
Outside the wrapper
- Price discovery and route optimization.
- Liquidity availability and market volatility.
- Token metadata accuracy and issuer representations.
- Wallet security and user key management.
- Independent review of third-party hook programs.
INTEGRATION SURFACE
Designed for wallets, launchers and routers.
Each integrator sees a different part of the same transaction. The launcher publishes the asset baseline. The wallet turns a quote into terms the user can understand and sign. The router continues to search for liquidity. The policy program evaluates additional rules, and the indexer records the successful receipt.
The integration surface is intentionally format-driven. An application should be able to replace its router without changing how an intent is signed, or add a new policy without changing the receipt format. That separation is what allows the protocol to sit above individual pools instead of becoming another isolated exchange.
| consumer | input | output | integration |
|---|---|---|---|
| wallet | canonical intent constraints | signable instruction | JOLT V1 |
| launcher | mint + market configuration | default policy identity | JLM1 |
| router | ordered CPI accounts + data | atomic route result | execute_intent |
| policy program | phase + opaque payload | accept / reject | JHK1 |
| indexer | transaction return data | realized settlement record | JRC1 |
PROTOCOL FAQ
Boundary and compatibility.
Is Jolt Guard a new AMM?
No. It is a route wrapper and settlement guard. Existing launchpads, AMMs and routers continue to provide liquidity and execution logic.
Does the wrapper custody tokens?
The base model measures user-controlled token accounts before and after CPI execution. It does not require a protocol-owned custody balance for ordinary settlement validation.
Can policy programs change the route?
A policy hook evaluates context and may accept or reject. The signed route program and ordered accounts remain explicit inputs to the guarded execution.
Read the implementation beside the specification.
Browse the complete Rust program, TypeScript SDK, tests, specification and CI configuration.