Skip to main content
An asset defines the unit of value participants earn and spend. Points, cashback dollars, hotel nights, referral credits. Each asset has its own ledger, and every credit has a corresponding debit somewhere in the system. Three settings define how an asset behaves: inventory mode, issuance policy, and scale. All three are set at creation and cannot be changed afterward.

Creating an asset

Assets are created at the organization level and automatically linked to the specified program. They can be shared across programs.

Inventory mode

Choose SIMPLE only when the balance can be treated as one pool. It cannot later answer which program, campaign, partner, or credit issued the value that was redeemed. Choose LOT when individual units of value carry meaning. For example, an airline program where points expire 18 months after they’re earned should use LOT; each credit creates a lot with its own expires_at, and expired lots are automatically excluded when the participant spends. A fixed budget alone does not require LOT: either mode works with PREFUNDED issuance. See Lots & Expiration for more on how lots work.

Issuance policy

Most programs start with UNLIMITED. Use PREFUNDED when you have a hard cap, like a “$50,000 Summer Promo” where the program wallet is funded once and credits stop when it’s empty. See Programs for how to fund and burn.

Scale

The number of decimal places for all amounts on this asset. Any value from 0 to 18. How extra decimal places are handled depends on where the amount comes from. Amounts computed by rule actions (CREDIT, DEBIT, and the others) are rounded half-up to fit the scale: crediting "1.009" on an asset with scale: 2 records "1.01". Amounts you pass to the balance endpoints (adjust, hold, release, forfeit) and to redemptions are not rounded: a value with more decimal places than the scale is rejected with a 400. Money amounts end to end walks through both paths.

Money amounts end to end

Track money in integer minor units by default: the smallest unit of the currency, such as cents for USD, so a $42.30 purchase is 4230. Rules evaluate event numbers as binary floating point, which represents whole numbers exactly but not most decimal fractions. A dollar amount such as 42.30 can therefore put a half-cent result on the wrong side of a rounding boundary, while the same amount in cents starts exact.

Create the asset in cents

With scale: 0, every amount on the asset is a whole number of cents.

Send integer amounts on events

Put the amount in event_data as a JSON integer:
Rules read event.amount_cents as a 64-bit float, which holds every integer up to 2^53 exactly. Ingestion rejects larger JSON numbers with 400 amount_precision_exceeded; see Numeric magnitude limit. If your issuer processor already reports amounts in minor units, pass its value through unchanged.

Compute the reward in a rule

For the $42.30 purchase, the expression evaluates to 211.5. Scrip rounds a rule’s computed amount half-up to the asset’s scale, so the participant earns 212 cents. A positive result that rounds to zero, such as 0.4, credits nothing, and the event still completes. A result of zero or less fails the action, and with it the whole event; see Failure is all-or-nothing. The same purchase sent as dollars to a scale: 2 asset shows why cents are the default. 42.30 * 0.05 evaluates to 2.1149999999999998 in floating point, so the rule credits 2.11 instead of 2.12, with or without the CEL round() helper.

Send exact amounts to the API

Amounts you send to the API directly are decimal strings. The balance endpoints and redemptions never round them: an amount with more decimal places than the scale is rejected.
Send "250" to credit $2.50. Hold, release, and forfeit return the same error, and redemptions return 400 with code: invalid_scale. Transfers, program wallet funding, and burns round extra decimal places half-up instead of rejecting them, so convert to cents before every call. See Balance Operations.

Display balances

Every balance and amount Scrip returns for the asset is a whole number of cents. Divide by 100 to display dollars.

Examples

The table below shows common asset configurations.

Asset sharing

Assets can be linked to multiple programs. This lets participants earn the same asset across different campaigns.
When using PREFUNDED assets, each program maintains its own wallet balance independently. Funding one program doesn’t affect another. If a shared asset needs issuer attribution for cross-program settlement, create it as LOT. SIMPLE shared balances can still report total redemptions by channel, but they cannot reconstruct which program originally issued the redeemed value. For example, a member earns 100 points through Program A and 50 points through Program B, then redeems 120 points through Program B. With LOT, redemption attribution can report 100 points issued by Program A and 20 issued by Program B, all redeemed through Program B. With SIMPLE, the report can show 120 points redeemed through Program B, but the original issuer split is no longer available.

Updating assets

You can update name and max_transaction_amount, and set status to ARCHIVED to permanently retire the asset. symbol, inventory_mode, issuance_policy, and scale are locked after creation.
Set max_transaction_amount to null to remove the ceiling.