Curve Management

set_curve rewrites an entire curve slot and validates every segment of it in the same transaction. For smooth curves this can cost tens of thousands of compute units, all in your update transaction. Queued curve updates split that work in two:

Your transaction only writes the edits into a small buffer. submit_curve_updates costs 58 CU regardless of batch size.
The validation work runs when the batch is applied, which by default is the next swap on the pool.

A smaller compute-unit limit means a cheaper priority fee for the same price per CU, and a transaction that lands more reliably when blocks are busy. That makes queued updates a good fit for operators who update the curve alongside every oracle tick. Three instructions make up this flow:

Instruction	What it does	Accounts
`submit_curve_updates`	Writes a batch of up to 28 point edits into the pool’s `CurveUpdates` buffer. Nothing on the curve changes yet.	authority, curve_updates
`validate_curve_updates`	Dry-runs the queued batch against the live curve, then always reverts. Use it only in simulation.	authority, curve_meta, curve_prefabs, curve_updates
`apply_curve_updates`	Applies the queued batch to the curve and clears the buffer.	authority, curve_meta, curve_prefabs, curve_updates

Because the next swap applies the queued batch, an invalid batch makes every swap on the pool fail with that batch’s error until you replace it. Always validate a batch with validate_curve_updates before you send it.

The recommended flow

Build the submit_curve_updates instruction.
Simulate a transaction containing submit_curve_updates followed by validate_curve_updates.
- Error 73 (ValidationSimulationSuccess) on the validate instruction means the batch is valid.
- Any other error is the exact error the real apply would return.
Remove validate_curve_updates and send submit_curve_updates, typically in the same transaction as your update_midprice. The next swap applies the batch.

validate_curve_updates never commits state, so a transaction that contains it always fails. Include it only when simulating.

submit_curve_updates

Requires the SDK’s rpc feature (for Hadron::load) plus solana-sdk, solana-rpc-client, solana-rpc-client-api and solana-compute-budget-interface.

use hadron_sdk_v2::accounts::decode_curve_updates;
use hadron_sdk_v2::hadron::Hadron;
use hadron_sdk_v2::helpers::math::to_q32;
use hadron_sdk_v2::types::{CurveType, CurveUpdateOp, CurveUpdateOpKind, Interpolation};

let pool = Hadron::load(&rpc, &pool_address)?;

// Read the live curve so each op can pin the point it expects to edit.
let bid = pool.get_active_curves()?.price_bid;
let slot = pool.get_active_curve_slots().price_bid;

// `sequence` must be >= the buffer's current sequence.
let sequence = decode_curve_updates(&rpc.get_account_data(&pool.addresses.curve_updates)?)?.sequence;

let submit_ix = pool.submit_curve_updates(&authority.pubkey(), sequence + 1, &[
    CurveUpdateOp {
        curve_type: CurveType::PriceBid,
        op_kind: CurveUpdateOpKind::Edit,
        point_index: 3,
        interpolation: Interpolation::Linear,
        amount_in: bid.points[3].amount_in,     // keep the same x, move the price
        price_factor_q32: to_q32(0.9975),
        params: [0; 4],
        target_slot: slot,                      // the active PriceBid slot
        expected_x_in: bid.points[3].amount_in, // current x_in at point_index
    },
]);

Field	Type	Description
`sequence`	`u64`	Must be ≥ the buffer’s current sequence. Protects against out-of-order submissions.
`curve_type`	`CurveType`	`PriceBid`, `PriceAsk`, `RiskBid` or `RiskAsk`
`op_kind`	`CurveUpdateOpKind`	`Edit` overwrites the point at `point_index`. `Add` inserts before it. `Remove` deletes it.
`point_index`	`u8`	Index of the point to edit, insert before, or remove
`interpolation`	`Interpolation`	Interpolation for the edited or added point
`amount_in`	`u64`	The point’s x value, in the same units as the curve’s x mode
`price_factor_q32`	`u64`	New price (or risk) factor in Q32. Use `to_q32(n)`.
`params`	`[u8; 4]`	Interpolation parameters, for example the Hyperbolic `k`
`target_slot`	`u8`	The slot that was active when you built the op. The op fails with `CurveUpdateSlotMismatch` (67) if the active slot has changed.
`expected_x_in`	`u64`	The x value currently at `point_index`. The op fails with `CurveUpdateExpectedXMismatch` (72) if the curve has moved. Ignored for `Add`.

Each submit replaces the buffer; it does not append. If you submit twice before the buffer is applied, only the second batch remains.

validate_curve_updates

Simulate submit_curve_updates and validate_curve_updates together, so the dry-run checks the batch you are about to send:

use hadron_sdk_v2::errors::HadronError;
use solana_sdk::instruction::InstructionError;
use solana_sdk::message::{v0, VersionedMessage};
use solana_sdk::transaction::{TransactionError, VersionedTransaction};
use solana_rpc_client_api::config::RpcSimulateTransactionConfig;

let validate_ix = pool.validate_curve_updates(&authority.pubkey());

let message = v0::Message::try_compile(
    &authority.pubkey(),
    &[submit_ix.clone(), validate_ix],
    &[],
    rpc.get_latest_blockhash()?,
)?;
let sim_tx = VersionedTransaction {
    signatures: vec![Default::default()],
    message: VersionedMessage::V0(message),
};

let sim = rpc.simulate_transaction_with_config(&sim_tx, RpcSimulateTransactionConfig {
    sig_verify: false,
    ..Default::default()
})?;

match sim.value.err.map(TransactionError::from) {
    Some(TransactionError::InstructionError(1, InstructionError::Custom(73))) => {
        // Valid: ValidationSimulationSuccess
    }
    Some(TransactionError::InstructionError(_, InstructionError::Custom(code))) => {
        return Err(format!("curve update rejected: {:?}", HadronError::from_code(code)).into());
    }
    other => return Err(format!("simulation failed: {other:?}").into()),
}

On failure the simulation logs name the op that failed, for example L-06 apply[2] ct=0 kind=Edit idx=4 fail=point-op-validation.

You can also call validate_curve_updates on its own to check a batch that is already queued on-chain.

Send the update

Deferred validation can halt swaps on your pool. submit_curve_updates does not check your ops. They are only checked when the batch is applied, which is usually inside the next swap. If the batch is invalid, every swap on the pool fails until you submit a valid batch to replace it.This is the tradeoff for keeping validation out of your update transaction. Never send a batch without first simulating it with validate_curve_updates. If you cannot simulate first, use set_curve, which rejects a bad curve in your own transaction.

After the simulation passes, remove validate_curve_updates and send submit_curve_updates with your oracle update under a tight compute-unit limit:

use hadron_sdk_v2::types::UpdateMidpriceParams;
use solana_compute_budget_interface::ComputeBudgetInstruction;

let mid_ix = pool.update_midprice(&authority.pubkey(), &UpdateMidpriceParams {
    midprice_q32: to_q32(142.35),
    sequence: None,
});

let message = v0::Message::try_compile(
    &authority.pubkey(),
    &[
        ComputeBudgetInstruction::set_compute_unit_limit(1_000),
        ComputeBudgetInstruction::set_compute_unit_price(50_000),
        mid_ix,
        submit_ix, // validate_ix removed
    ],
    &[],
    rpc.get_latest_blockhash()?,
)?;
let tx = VersionedTransaction::try_new(VersionedMessage::V0(message), &[&authority])?;
rpc.send_and_confirm_transaction(&tx)?;

The Hadron instructions in this transaction use under 100 CU (update_midprice about 37, submit_curve_updates 58). Each compute-budget instruction adds about 150 CU, so a limit of 1,000 leaves plenty of headroom.

Until the next swap applies the batch, the curve account still holds the old points, and off-chain quoters (including aggregators) quote from it. The swap that applies the batch executes against the new points. Send apply_curve_updates yourself if you need the new points live and quoted before the next trade.

apply_curve_updates

let ix = pool.apply_curve_updates(&authority.pubkey());

Applies every queued op in order and clears the buffer, exactly as the next swap would. If any op fails, the whole instruction fails and nothing changes. Applying an empty buffer is a no-op. Use it when you want the edits live immediately and are willing to pay the validation CU yourself.

Batch rules

Ops apply in order. Each op is checked against the curve as the earlier ops in the same batch left it, not against the final curve. A set of edits that is valid in the end can still fail midway. For example, to move two neighbouring points to the right, edit the right-hand point first. If you edit the left-hand point first, it lands past its old neighbour and the op fails with CurvePointsNotSorted (error 9). Validate catches this, so reorder the ops and simulate again.
Indexes follow earlier ops. point_index and expected_x_in refer to the curve after the earlier ops in the batch. After an Add or Remove, the points to its right shift by one.
One failure fails the batch. No partial apply.
Max 28 ops per submit.

Where the compute units go

Validation cost depends on the curve’s interpolation and on how many segments are checked. set_curve checks every segment. A queued op checks only the segments next to the point it touches (at most two). Measured on the deployed program:

Curve	`set_curve`, paid by you	1 queued op, paid at apply
Flat Step, 2 points	667	678
MarginalStep, 5 points	1,535	1,003
MarginalStep, 21 points	5,407	1,003
Linear, 2 points	3,151	3,167
Linear, 5 points	10,903	5,687
Linear, 21 points	52,247	5,687

With the queue, your transaction pays only the 58 CU for submit_curve_updates. The right-hand column is paid by whoever applies the batch: the next swap, or you if you send apply_curve_updates. validate_curve_updates costs the same as an apply, but only in simulation.

Updating the curve with every oracle tick: use the queue. Your update transaction stays under 100 CU of Hadron work however long or smooth the curve is.
Short or cheap curves: set_curve on a 2-point flat curve already costs under 700 CU, so the queue saves little.
Keep batches small. The swap that applies the batch pays about 1,000–5,700 CU per op on top of its own cost. A large batch can push an aggregator’s swap over the compute budget it simulated. For large reshapes, use set_curve or send apply_curve_updates yourself.

Errors

Code	Name	Meaning
9	`CurvePointsNotSorted`	The op would leave x values out of order
61	`ConcavityViolation`	The op would make the curve non-concave
62	`PriceFactorTooLarge`	Price factor above 1.0 (`Q32_ONE`)
67	`CurveUpdateSlotMismatch`	`target_slot` is not the active slot for that curve type
72	`CurveUpdateExpectedXMismatch`	`expected_x_in` does not match the point at `point_index`
73	`ValidationSimulationSuccess`	`validate_curve_updates` dry-run passed (intentional revert)

See Error Reference for the full list.

TypeScript

Rust

The recommended flow

submit_curve_updates

validate_curve_updates

Send the update

apply_curve_updates

Batch rules

Where the compute units go

Errors

​The recommended flow

​submit_curve_updates

​validate_curve_updates

​Send the update

​apply_curve_updates

​Batch rules

​Where the compute units go

​Errors

The recommended flow

submit_curve_updates

validate_curve_updates

Send the update

apply_curve_updates

Batch rules

Where the compute units go

Errors