Accounts

The six account types

Every account the curta program owns opens with an 8-byte ASCII tag that names its type. The tag identifies an account, and its size does not. Integers are little-endian and addresses are 32 raw bytes.

The program also derives one address that holds no account data: the event authority, seeds "__event_authority", which signs the program’s events. Program reference lists the helper that derives each address.

Config

One per program, at the address with seeds "config", 128 bytes. init_config creates it and set_config changes the turn reward and the protocol share rate. open_run copies both into the run, so a run keeps the values it opened with.

FeeVault

One per program, at the address with seeds "fee", 8 bytes: the tag CURTAFEE and nothing else. Its balance is the account’s lamports. settle moves each run’s accrued protocol share into it, and the amount above its rent is the protocol share collected. CURTA says where it goes.

Model

One per model, at a keypair address, 4,096 bytes. create_model writes it, write_weights and seal_model advance its upload and sealing fields, open_run counts runs and settle adds tokens and royalties.

Bytes not listed are zero. The seven values from offset 72 to 100 are the model’s configuration, in the order create_model takes them.

Section descriptors

Descriptor i starts at offset 512 + 48 × i. Section zero holds the tokenizer and the lookup tables, and the sections after it hold the matrices, as Weight format describes.

A section is fully uploaded when its bytes written equal its length, and sealing begins once that holds for every section.

ModelVault

One per model, at the address with seeds "model-vault" and the model’s address, 8 bytes: the tag CURTAVLT. Its balance is the account’s lamports. settle moves each run’s accrued royalty into it, and claim_royalties pays the publisher out of it, leaving the rent of its 8 bytes.

Weight accounts

A model’s weights live in 2 to 64 accounts at keypair addresses, one section each. An account is created at 2,048 bytes plus its section’s length, and a section is from 1 to 10,483,712 bytes, so the account fits Solana’s limit of 10,485,760 bytes. The first write_weights to an account writes its header.

A set bit in the bitmap means that chunk is written. An interrupted upload resumes from the bitmap: read the header, send the chunks whose bits are clear. decodeWeights(data, model?, section?) checks the tag, and the model and section when given, and returns the section’s bytes. turn reads weight accounts and never writes them.

Run

One per run, at a keypair address: a 256-byte header, then the working state. open_run writes it, turn advances it, fund and cancel change its budget and state, settle sets its settled flag, and close_run removes it. Runs and turns follows those steps.

The lamports of a run account are its rent, plus the budget remaining, plus the royalty and the protocol share accrued, until settle moves them out. A turn pays its reward straight out of the account, so rewards paid have already left it.

The working state’s header

The working state opens with its own 128-byte header. These are the fields a reader of the output needs, with offsets counted from byte 256 of the run account. Inference core covers the position cursors that sit between them.

decodeRun reads the header and the output for you: it returns prompt, tokens (the output token ids) and text beside the header fields.

The size of a run account

A run account is created at its exact size, before open_run, and open_run checks it to the byte. The size is 256 plus the working state, and the working state’s size follows from the model’s configuration, the prompt’s byte length and maxTokens. Its regions sit in this order:

The prompt token ids, the output token ids, the output text and the first activation vector each start on a multiple of 8. Two derived values complete the formula:

positions   = min(contextLength, promptBytes + maxTokens + 1)
kvDimension = dimension × kvHeads / heads
align8(n)   = n rounded up to a multiple of 8

tokens  = align8(128 + promptBytes)
output  = align8(tokens + (promptBytes + 2) × 4)
text    = align8(output + maxTokens × 4)
vectors = align8(text + maxTokens × 128)

state = vectors
      + 4 × dimension × 8
      + 2 × hiddenDimension × 8
      + vocabularySize × 8
      + positions × 8
      + 2 × layers × positions × kvDimension × 4

runAccountSize = 256 + state

The prompt is at most 1,024 bytes and maxTokens runs from 1 to the context length. A token’s text is at most 128 bytes, which sizes the output text. Activations are 64-bit words and cached keys and values 32-bit words.

The reference runs on the prompt “Once upon a time”, 16 bytes, come to these sizes:

The SDK computes the size with the same core the program runs. client.quote returns it as runAccountSize with the rent as runAccountRentLamports, and client.openRun creates the account at that size holding the rent plus the budget.

const quote = await curta.quote({ model, prompt: 'Once upon a time', maxTokens: 12 })

quote.runAccountSize          // bytes
quote.runAccountRentLamports  // bigint
quote.totalBudget             // bigint, lamports for the whole run

Reading accounts

A Curta client fetches and decodes in one call, and checks that the account is owned by the program:

import { Connection } from '@solana/web3.js'
import { Curta } from '@curta/sdk'

const connection = new Connection(process.env.CURTA_RPC_URL!, 'confirmed')
const curta = new Curta({ connection })

const config = await curta.getConfig()   // ConfigAccount
const model = await curta.getModel(modelAddress)   // ModelAccount
const run = await curta.getRun(runAddress)   // RunAccount

run.status            // 'running' | 'starved' | 'complete' | 'cancelled'
run.turns             // bigint
run.budgetRemaining   // bigint, lamports
run.text              // the output so far

Amounts and counters that are u64 on chain are bigint in the decoded objects. The decoders also work on raw bytes: decodeConfig(data, address?), decodeModel(data, address?), decodeRun(data, address?), decodeWeights(data, model?, section?), decodeFeeVault(data) and decodeModelVault(data). Each throws when the tag or the length is wrong.

client.getRunHead(address) reads the first 384 bytes of a run, the header and the working state’s header, and returns the model, status, settled flag, turn count, turn reward, rewards paid, budget remaining and next turn cost. It is the cheap read between turns.

To list accounts of one type, filter the program’s accounts on the tag at offset 0:

import bs58 from 'bs58'

const runs = await connection.getProgramAccounts(curta.programId, {
  filters: [{ memcmp: { offset: 0, bytes: bs58.encode(Buffer.from('CURTARUN')) } }],
  dataSlice: { offset: 0, length: 256 },   // headers only
})

In Rust, curta_core::protocol holds the same layouts as zero-copy readers: ConfigView, ModelView, RunView, WeightView and VaultView, each with a read(data) that validates the bytes and accessors for the fields. The caller checks that the account is owned by the program. Call from a program reads a finished run this way.