Skip to main content
Every asset movement in Scrip is recorded as a double-entry journal entry. Credits and debits always balance.

​
Double-Entry Accounting

Every transaction creates a journal entry with two or more postings that sum to zero: 
Journal Entry: "Purchase reward - 10 points"
├── Posting 1: SYSTEM_ISSUANCE   -10  (debit: source)
└── Posting 2: participant/alice +10  (credit: destination)
For PREFUNDED assets, the source is the program wallet instead of SYSTEM_ISSUANCE: 
Journal Entry: "Purchase reward - 10 points"
├── Posting 1: program/loyalty   -10  (debit: program wallet)
└── Posting 2: participant/alice +10  (credit: participant)

​
Accounts and Buckets

An account is a balance container in the ledger. Participants, groups, programs, and system entities all have accounts. The ledger tracks funds by writing postings against these accounts. Each account holds a balance for a single asset in a single bucket. A participant with one asset has up to three accounts: one for AVAILABLE funds, one for HELD funds, and one for DEFERRED funds. Accounts are created lazily, when the first posting touches that bucket. A participant with three assets has up to nine accounts. A bucket segments the balance into separate pools:
BucketDescription
AVAILABLEThe spendable balance. Credits land here by default. Debits, holds, forfeits, and redemptions draw from this bucket.
HELDReserved and not spendable. A HOLD action moves funds from AVAILABLE to HELD, locking them until the hold is resolved. A RELEASE moves them back to AVAILABLE. Forfeits can also draw from HELD.
DEFERREDNot yet matured. When a credit specifies a future matures_at timestamp, funds land here instead of AVAILABLE. Deferred funds cannot be spent, held, or debited. When the maturity date passes, a background job automatically moves the funds to AVAILABLE and records a MATURITY journal entry.
When you query a participant’s balances, the response breaks out each bucket: 
{
  "balances": [
    {"asset_id": "...", "symbol": "PTS", "available": "850", "held": "150", "deferred": "500"}
  ]
}

​
Journal Entries

A journal entry is a record of a single ledger operation. The system creates one every time funds move: credits, debits, holds, releases, forfeits, and redemptions. Each journal entry contains two or more postings. A posting is a single line item that records a change to one account: which account, the signed amount (positive for credits, negative for debits), and which bucket. The postings within an entry always sum to zero. You can list journal entries through the API: 
GET /v1/journal-entries?program_id=...&from=2025-01-01T00:00:00Z
Each journal entry includes:
FieldDescription
descriptionHuman-readable summary of the operation
postingsThe individual debit and credit lines, each with an account, amount, and bucket
event_idThe event that triggered this entry, if it came from a rule. Null for direct API operations.
rule_idThe rule that triggered this entry, if it was created during rule execution. Null for direct API operations and non-rule worker activity.
action_typeThe ledger operation that created this entry (CREDIT, HOLD, REDEMPTION, …)
reference_idCorrelation ID linking related entries, such as a hold to its release or settlement
entry_hashSHA-256 hash sealing this entry into the organization’s hash chain

​
Filtering

The journal entries list endpoint accepts query parameters to narrow results.
FilterDescription
program_idEntries for a specific program
participant_idEntries involving a participant
external_idEntries by external ID
group_idEntries involving a group
asset_idFilter by asset
bucketFilter by bucket (AVAILABLE, HELD, DEFERRED)
event_idEntries from a specific event
rule_idEntries created by a specific rule
action_typeFilter by ledger action type: CREDIT, DEBIT, TRANSFER, HOLD, RELEASE, FORFEIT, EXPIRATION, REDEMPTION, REVERSAL, BURN, FUND, ADJUSTMENT, MATURITY, or VOID_HOLD
reference_idFilter by hold, release, or settle correlation ID
from / toTime range
min_amount / max_amountPosting amount range
Amount filters apply to raw signed posting values. Credits are positive, debits are negative. Entity filters (participant_id, external_id, group_id) are mutually exclusive.

​
Entry Detail

Fetch a single journal entry to see the full record: 
GET /v1/journal-entries/{id}
The response includes every posting in the entry, with the full account, amount, and bucket detail for each.

​
System Accounts

Every fund movement has an origin and a destination. For transfers between participants, both sides are participant accounts. When funds are minted, forfeited, or redeemed, the other side of the transaction is a system account.
AccountRole
SYSTEM_ISSUANCEWhere new points come from. When the system mints funds for an UNLIMITED asset, the journal entry debits SYSTEM_ISSUANCE and credits the participant.
SYSTEM_BREAKAGEWhere lost points go. Forfeited, expired, or otherwise removed funds are credited here.
SYSTEM_REDEMPTIONWhere spent points go. When a participant redeems funds for a reward, the entry debits the participant and credits SYSTEM_REDEMPTION.
These accounts make it possible to reconcile total points issued against points in circulation, points spent, and points lost.

​
Integrity

The ledger is append-only. Journal entries cannot be modified or deleted after creation. Every journal entry is sealed with a SHA-256 hash that covers its metadata, all postings, and the previous entry’s hash. This forms a chain within each organization: if any entry were altered, the hash would no longer match, and every subsequent entry’s hash would also break. The entry_hash field on each journal entry is this cryptographic seal. You can verify the chain, along with postings balance and value conservation, at any time with the ledger integrity report. Pin its chain_head hash externally to make any later alteration of history detectable. To reverse a transaction, create a new journal entry with opposite postings. A redemption reversal, for example, credits the participant and debits the redemption account. The original entry and its hash remain intact.