Tokenized equities (xStocks)

Skipo's tokenized equities (NVDASPV, TSLASPV, AMDSPV, GLDSPV…) are rebasing assets. The settled quantity never moves; corporate actions — dividend reinvestment, splits, reverse splits — are expressed by raising a multiplier:

underlying shares = settled quantity × multiplier
price per share   = rate / multiplier

Both representations describe the same money: quantity × rate yields the same quote-currency amount either way. The rebase applies to the base leg only — an xStock market is <STOCK>-CLP or <STOCK>-USDT, so the other leg is fiat or a stablecoin.

assetFormat

The order and fill endpoints accept an assetFormat parameter:

Value	What you get
rebased (default)	Amounts in terms of the underlying equity — what a holder thinks of as "their shares".
base	Amounts in terms of the settled SPV tokens — what moved on chain and in the ledger.

GET /v2/fills?market=NVDASPV-CLP                    # rebased (default)
GET /v2/fills?market=NVDASPV-CLP&assetFormat=base   # settled figures

The default is rebased

This is a deliberate change from the previous behaviour, which returned base. A holder thinks in shares, not SPV tokens, and it is what comparable venues do (Kraken's rebase_multiplier defaults the same way). If your integration depends on the settled figures, ask for assetFormat=base explicitly.

For every other asset nothing changes: the multiplier is 1 and both modes are identical.

The multiplier field

Orders and fills publish the factor that was applied:

{
  "id": "1096473",
  "baseAsset": "NVDASPV",
  "baseAmount": "10.000658218334353",
  "rate": "18499.8",
  "multiplier": "1.0000658218334353"
}

With it you can reconstruct the other representation without another request:

• base → rebased: baseAmount × multiplier, rate ÷ multiplier
• rebased → base: baseAmount ÷ multiplier, rate × multiplier

This is what lets you reconcile an API amount against an on-chain balance.

The multiplier is point-in-time

This is the part that matters most and is easiest to get wrong:

The factor we publish is the one in effect at that fill, read off the row itself. It is never recomputed from today's factor.

A corporate action changes the factor going forward; it does not change what a past transaction delivered. Applying today's multiplier to last year's fill restates history: if an asset does a 10:1 split, your entire past history would appear multiplied by ten.

This is rule 3 of Solana's Scaled UI Amount extension guidance: a historical amount must be rendered with the multiplier that was in effect when the transaction happened.

multiplier: "1" does not mean "not a tokenized equity"

A factor of exactly 1 is simply a factor that has not moved yet — TSLASPV sits at 1 today. Do not use it to classify assets. Asset class is reference data and is read from GET /v2/assets/{assetSymbol}.

The ledger does not accept assetFormat

GET /v2/ledger deliberately exposes settled amounts, with no assetFormat.

The ledger is the double-entry record of what actually moved, and its entries do not currently carry the multiplier that was in effect when they were booked. Honouring assetFormat there would mean resolving the factor live, which is exactly the restatement bug described above. A correct unscaled figure beats a scaled, possibly false one.

To see a fill in share terms, read it from /v2/fills, which does carry its point-in-time factor.