Loading
Loading
Loading
Loading
Loading
Loading
Loading
A resale price is admitted or refused by one comparison between integers. This page shows the comparison, works its boundary, and then says plainly what enforces it today.
price * 10000 <= face * (10000 + cap_bps)
Every term is an integer. There is no division in the predicate and no rounding, so the boundary is exact: a price on the ceiling is admitted, and one lamport above it is refused.
The cap is the only thing in this product that carries the warning colour. That chip and the dashed rule a price chart draws at the ceiling are the two places it appears.
One SOL of face value, capped at 2500 bps over it. The four lines are the comparison above with those numbers in it.
face 1000000000 lamports cap 2500 bps bound face * (10000 + 2500) = 12500000000000 price 1250000000 * 10000 = 12500000000000 admitted price 1250000001 * 10000 = 12500000010000 refused
The cap is set once, at InitializeRecord. The instruction takes the face value and the cap in basis points as arguments, and there is no instruction that changes either one afterwards. Nothing can raise the cap and nothing can lower it: an organiser who wanted a different number would be initialising a different record.
The jurisdiction gate sits above that and can only tighten it. It resolves the legal ceiling for the region, compares it with the platform cap, and takes the lower of the two. A jurisdiction can make the ceiling smaller. It can never make it larger.
The cap program is deployed on Solana devnet. A verified run recorded the program id, the mint it guards, and two transfers against it: one priced exactly at the ceiling, which executed, and one lamport above it, which the program refused. The panel below is that record, printed as it was written.
The recorded deployment
The boundary, executed
E5RCrLwWikWCdHSd5MfqEBowXsmLn2n9fwYjnSwn8NhPi9j7weahbuRhgofu8ca8MVXzQUbvPrJqENDLNab7pJfslot 519,845,933 · 08 Nov 2026, 00:50
custom program error: 0x177a (6010 E_CAP_EXCEEDED)22dqSriig968nx8aA3YaFVt4CErgNbkwvxFtDKn2MWpcCdnA2KQhFYvhwTWZSpP64wzQjoBeMUKEZLRW1e7jKe79slot 519,846,008 · 08 Nov 2026, 00:50
Read from records/devnet-artefacts.json at build time. This build asked no cluster, so this is the recorded verification and not a live re-read: the fields below are what was asked, and they stay what was asked.
No backend is configured, so this process asked no cluster and read no artefact. Nothing here is a deployment claim.
This build queried no cluster, so programDeployed records that no check was made. It is not a statement that the program is absent: the recorded deployment above is what a verified run wrote.
dataSource BUNDLED MOCK DATA. Generated from lib/mock on this machine, not read from the backend.
There is no account and no session in this backend. Nothing authorizes a caller, so every screen in this build is open. The one check the backend performs is the signature below, and it proves exactly one thing: that whoever asked holds the private key for the wallet in the message.
This deployment is a static export and calls no backend, so that check runs nowhere on this site: /verify says so on the screen where a visitor would look for it. The check described here is the one the backend implements, and the rest of this section is its specification rather than a record of a verification.
The message is rebuilt byte for byte on the backend before the signature is checked. Its first line, its blank line and its cluster are fixed, and the format belongs to one function in this front end. Changing it invalidates every nonce already in flight.
Verify wallet ownership for ticket issuance. Wallet: <wallet> Nonce: <nonce> Cluster: devnet
The two angle-bracket values are the wallet address and the single-use nonce. Everything else, including the cluster line, is the fixed part.
The verification record carries canPurchase, canReceiveTransfer and a flags array. They gate nothing at runtime. They are advisory: no endpoint refuses a request on them, and no screen decides a purchase or a transfer from them.