the field named multiplier
1.0130866005227463
The previous value. Token-2022 keeps the multiplier in force before the most recent activation here, and this is the field a reader reaches for first.
01/ a real xStock, held
The two multipliers, the dividend that was withheld, and the verdict on your own stock.
A real mint on mainnet, read live. The verdict applies the program's settlement_window rule in your browser; the devnet desk asks the deployed program itself.
the live value, in the field beside it
1.017648970535191
In force since 2026-08-15T00:30:00Z. These two disagree, which is the trap.
what your wallet would show
1.013087
Your raw amount times the field named multiplier. This is the number a wallet that read the obvious field puts on screen.
what you own
1.017649
Your raw amount times the live value. The difference between these two is what one corporate action is worth to you.
your raw amount
Base units, as the mint stores them. 8 decimals on this token, so the default is one share.
the dividend, reinvested
3
Activations this token has had in the issuer's own feed. It is reinvested rather than paid: the raw balance never moves and the multiplier does.
per share, gross to net
3.09
The feed's gross cashflow per share, against the 2.163 the multiplier actually reinvests. The gap is the withholding.
withheld at 30%
0.927
Per share, taken before the reinvestment. Across this token's whole float it is $112,966, and no surface a holder looks at reports it.
withheld on your holding
0.927
The same rate applied to the raw amount above, at this token's own decimals. This is the figure the entry exists to surface.
at 162.05 USD a share
XsaHND8sHyfMfsWPj6kSdd5VwvCayZvjYgKmmcNL5qh
The mint account this is read from, live, over plain RPC with no key.
the program's two numbers
33.7 days ago · nothing staged
Seconds since the last activation, and seconds until a staged one. -1 is "nothing to report", because 0 is a real answer and means 1970.
Read over plain RPC from https://solana-rpc.publicnode.com, with the build from 2026-09-17 16:44:53 UTC as the fallback.
02/ every xStock that has paid
The whole market, read live, in one table.
Every xStock the issuer has reinvested a dividend into, read from its mint on mainnet the moment this page opens. Sort by any column, find your ticker, and pick a row to open it above.
| ticker | field named multiplier | live value | gap | in force since | withheld, whole float | settle now |
|---|
03/ the devnet desk
Pick a registered mint. Everything below follows it.
These are the mints this program has registered on devnet, and there are 6 of them. A dot marks one where the field named multiplier and the live new_multiplier disagree, which is the state the entry is about.
multiplier
1
The field a reader reaches for first. Token-2022 keeps the value in force before the most recent activation here.
new_multiplier
1.0042
Live from 2026-09-16T17:02:02Z, and the value the program applies. These two disagree, which is the trap.
mint account
5N7aHZRBfQ92y4NBjwKx2EKzvFCaUPZRzReA8gRAQCjR
token record
7MupvMRPG1RCmxsy1xGM9nM3a1mhprNSZv241mrjX1BV
activations recorded
1
Receipts this program has written for this mint.
The two fields are read from the mint's own scaledUiAmountConfig extension. The rule for which one is live is Token-2022's: new_multiplier once its timestamp has passed, multiplier otherwise. This page applies that rule to say what a naive reader would get, and then asks the program for its own answer below, so the two are compared rather than asserted.
04/ what a holding is worth
The program's answer, against the obvious one.
One question, asked twice. Once of the deployed program through its read_entitlement instruction, and once by multiplying the field named multiplier by the raw amount, which is what a wallet that reached for the obvious field would show.
the obvious read
1
raw × multiplier, which is the previous value.
the program's answer
1.0042
read_entitlement, signed by nobody, executed by the deployed program on devnet.
the difference
0.0042
raw × 1 against the program's own answer.
raw units, at 8 decimals
// the whole question, as the page sends it instruction read_entitlement(raw_amount: u64) accounts mint, token_record // both read-only signed by nobody. sigVerify: false, nothing is spent. answered by ycg2obpKmccwAz1zGf4QqgV2vnkWd6CQKLdJSGDxtmG returned 0x00000000000000000000000005fc49a0 // little-endian u128, the program's own bytes
Why the gap is the dividend. Token-2022 reinvests a dividend by
raising the multiplier. The balance does not move, so the multiplier is the only record that
anything happened. A reader one activation behind loses exactly the dividend, and on this
devnet mint that is 0.4182% of the
position. On 17 September 2026, 370 of the 927 xStock mints on Solana mainnet were in this
state.
05/ whether to settle
The window, from the program's own clock.
The issuer's own documentation recommends that venues and protocols pause around each activation, and nothing in a mint account can enforce that. The program's settlement_window instruction returns two numbers: the seconds since the multiplier in force took effect, and the seconds until an activation the issuer has staged. Both are measured against the validator's clock rather than yours, so the answer is the same from any machine.
The second of those is the one the mint cannot supply. The issuer stages the next value about four hours before it takes effect, and staging it overwrites the timestamp of the value now in force, so during that window the mint says nothing about when the live multiplier started. This program's own record does hold it, and the first number is where that shows.
Settle
The activation was 1.1 days ago, which is outside the 15 minute window this desk holds for, so this trade is clear.
since the last, until the next
96,724s ago · nothing staged
Two little-endian i64s. Either is -1 when there is nothing to report.
the venue's rule
±15 min
Hold inside 900 seconds either side of an activation. This is the desk's policy, and the program supplies both of the numbers it is applied to.
the raw answer
d479010000000000ffffffffffffffff
The program's return data, unedited. Sixteen bytes, two i64s.
the 15 minute window
now, placed on the program's own clock
the axis spans two hours either side of the activation
// settlement_window: two numbers, because the issuer's window is two-sided let since = if live.staged_at == 0 && live.effective_at > 0 { now - live.effective_at // the mint can answer this one itself } else if record.live_effective_at > 0 { now - record.live_effective_at // the mint overwrote it; the record kept it } else { -1 }; let until = if live.staged_at > 0 { live.staged_at - now } else { -1 }; // A venue holds while either is inside 900.
A window that was open. On 2026-09-17 14:10:34.650 UTC the desk was asked about 5KLQzvg4… with an activation 2 seconds old and nothing staged, and it held. That reading is recorded here because the window is only open for fifteen minutes: a live page cannot be made to show a hold on demand, so one was staged and captured. The activation was written in transaction 28PumW49gSYhbagp…, which a judge can open. Every other number on this page is read live.
06/ the trail
The series the mint does not keep.
A mint keeps the latest two multipliers and nothing before them. There is no sequence and no account per activation, so the history of what a token paid lives in an HTTP API and in transaction logs. These are the receipts this program wrote, one per activation, and they are the same on every machine that reads them.
| seq | activation | before | after | change | effective | recorded | raw supply |
|---|---|---|---|---|---|---|---|
| 0 | moved | 1 | 1.0042 | +0.0042 | 2026-09-16T17:02:02Z | 2026-09-16T17:02:03Z | 100,000,000 |
1 receipt for this mint, written in order and never changed. Read from the program's own accounts, not from an index.
07/ the reference price
The one number the issuer does not own.
Everything above reads the issuer's own mint account, so a number taken from there is the issuer agreeing with itself. verify_against_pyth is the check against a value this program does not control. It refuses for three reasons: the account is not a Pyth price, the price is for a different feed, or the price is older than the caller's limit.
| mint | feed bound | newest account | published | age | the program |
|---|---|---|---|---|---|
| DEMOx · 5N7a… | AAPL | DJgUxxLVN1QxAXykPzpH5Kz5feo1bTCBDipGRUYYqMw | 2026-08-14T20:00:19Z | 34.0 days | StalePythPrice |
| DEMOx · 8RUM… | SOL | 7UVimffxr9ow1uXYxsr4LHAcV58mLzhmwaeKvJ1pjLiE | 2026-09-17T19:53:02Z | 1.5 minutes | accepted |
| DEMOx · DoF9… | SOL | 7UVimffxr9ow1uXYxsr4LHAcV58mLzhmwaeKvJ1pjLiE | 2026-09-17T19:53:02Z | 1.5 minutes | accepted |
The caller settles at exactly Pyth's own number, so the deviation is zero and the age is the only thing left that can refuse it. A desk that settled at a different number would not isolate the cause. On devnet the equity feed's publisher stopped on 14 August 2026, which is why the newest price for a stock feed on this cluster is weeks old while a crypto feed on the same cluster updates every second. Same instruction, same cluster, and the only difference that matters is the age.
08/ how this page talks to the chain
No key, no backend, no library.
Everything on this page was produced by the browser talking to api.devnet.solana.com with fetch. Nothing was signed and nothing was spent.
The transaction is assembled by hand
The page builds the Solana wire format itself: a compact-u16 signature count, a zeroed 64-byte signature, the message header, the account keys in the order the header requires, then the instruction. There is no web3.js here and no CDN to load, which is also why the page opens from a file on disk.
Nothing is signed
The simulations run with sigVerify: false and replaceRecentBlockhash: true. The runtime still requires an account in the fee slot, so the page uses one whose key is the sha256 of a fixed public string and was never generated. It cannot be spent from.
Every read is a real answer
The figures on this page are in the markup as their resting state, so the page reads correctly with JavaScript switched off and from a file on disk. The script re-reads devnet and replaces them. If the read fails the page says so and keeps the recorded values rather than showing a blank.
// what the page sends, in full POST api.devnet.solana.com {"method":"simulateTransaction","params":["<base64 transaction>", {"encoding":"base64","sigVerify":false,"replaceRecentBlockhash":true}]} // fee slot, so the runtime will load it. The key was never generated: // sha256("record-date settlement desk fee payer v1") payer 9GwUYoXLix8k27MjwnYFqzwsn4bKD2tZf5Dcz9ydp9vX
The program is deployed at ycg2obpKmccwAz1zGf4QqgV2vnkWd6CQKLdJSGDxtmG and its accounts are readable at that address. The receipt accounts below are real devnet accounts and each one links to the explorer.