Reference

Close completed storage

Instruction 17 uses [booking_or_unbond(w), recorded_rent_payer(w)], empty payload. It accepts released/expired or finalized booking records, executed unbond requests, and available reusable bookings. Closing available reusable storage additionally requires the recorded rent payer's signature. Receipt cases must also be past their stored dispute deadline.

The recipient must equal the rent payer recorded in the account. Closing returns its lamports and removes the storage; active reservations, claimed obligations, and unresolved disputes cannot be closed. Receipt buckets have their own close instruction, 27.

Close a receipt bucket

Send instruction 27 with [receipt_bucket(w), recorded_rent_payer(w), authority(s)] and an empty payload. The signer must be the bucket's recorded rent payer or provider. The recipient must be the recorded rent payer, regardless of which authority signs, and cannot be the bucket itself.

The bucket must be program-owned, exactly 736 bytes, and have discriminator RECEIPT1. Its finalized flag must be 1, aggregate outstanding charge and obligation count must both be zero, the clock must reach its epoch end, and the latest dispute deadline must be strictly past. Instruction 24 finalizes the bucket before closure.

Closure transfers all bucket lamports to its recorded rent payer and removes the account. Opened disputes retain their separate case accounts, collateral exposure, and resolution rules. A bucket still needed for later epochs can instead be reused through instruction 23. Finalization, reuse, and closure require instruction execution; compatible instructions can share a transaction. For example, 24 followed by 23 can finalize an expired bucket and reuse it atomically when both instructions' conditions hold. Elapsed time alone does not change storage.

let now = Clock::get()?.unix_timestamp;
require(
    d[173] == 1 && rd64(&d, 208) == 0 && rd64(&d, 216) == 0
        && now >= ri64(&d, 184) && now > ri64(&d, 192),
    7,
)?;
drop(d);
recipient.set_lamports(add(recipient.lamports(), bucket.lamports())?);
bucket.close()

Transaction costs and storage reuse

Reusable booking accounts avoid a new rent deposit for every order. Finalized receipt buckets can be reused for later epochs, or closed to return lamports to their recorded payer. Rent deposits remain locked while accounts exist; transaction fees are separate. Quote account funding with getMinimumBalanceForRentExemption and transaction fees with getFeeForMessage for the target cluster.

Compatible instructions can share a transaction and its required signatures: initialize several booking accounts, settle several ready claims, finalize and reuse a bucket, or clean up several completed records. Packet size, compute limits, and required signatures determine the saving; there is no fixed claims-per-batch guarantee. Reusable claims remain separate top-level instructions even when batched. If any instruction fails, program state changes roll back; transaction fees still apply.

For claims sharing a bucket, assign consecutive indices only to positive charges. Reconcile an uncertain transaction's signature before constructing a replacement; otherwise its original receipt indices may still be in flight. A confirmed failed batch leaves its bookings unsettled and can be rebuilt from current state.

The contract requires no particular spare-booking count or idle timeout. Those are client policies. Closing available reusable storage requires the recorded payer's signature and refunds that payer; a reservation already active cannot be closed. User-account generation counters remain separate from booking storage. The program provides no close instruction for user accounts or canonical model books.

Market initialization and errors

Instruction 0 initializes a fresh, program-owned 72-byte market with [market(ws), admin(s), mint], empty payload. The mint must be initialized with six decimals. The FOSSAV20 account fixes administrator at bytes 8..40 and payment mint at 40..72; neither has an update instruction. Provider approval, model creation, additional offers by the same provider in a model, offer approval, and dispute resolution check this administrator key.

Custom error codes are 1 for arithmetic, 2 for account identity or layout, 3 for payload validation, 4 for authorization, 6 for no eligible offer or a full book, 7 for lifecycle or deadline checks, and 8 for usage or collateral constraints. Instruction layouts and account sizes are defined in program/src/abi.rs; reusable booking, bucket, and receipt-proof rules are implemented in program/src/receipt_prototype.rs.