Points and Broker NFTs: activity, thresholds, and allocation

Points are a running activity measure. A Broker NFT allocation is a later qualification and capacity question. Treating those as one progress bar makes an ordinary status value sound like a promise.

Read the pipeline in order

One activity record can pass through several states:

1. The service observes an eligible event.
2. It verifies the event and records its volume or activity value.
3. The wallet receives Points in the relevant stage.
4. The stage compares the total with its threshold and capacity.
5. The service reports qualification and, where applicable, allocation state.

An AI answer can help you label these states, but it should not recompute the authoritative result from a visible list of entries. The participant kit’s suibrokers_get_season reads one published stage and optional viewer row. The API response, including threshold, cutoff, capacity, rollover, qualification, and viewer fields, remains the source to quote.

Why a threshold is not an allocation

The current season contract uses four stages with thresholds of 1,000, 2,000, 4,000, and 8,000 Points. Each stage has a capacity rule, and the service keeps qualification, capacity-full, and not-allocated states distinct. A wallet can have positive Points and still lack a current qualification or available place. A threshold can be reached while the final allocation step remains pending.

The program also separates verified Swap or Desk activity from Partner Trust. A referral can change the partner record without changing the wallet’s own verified activity total. Trust is not a second name for Points, and a partner revenue figure is not an allocation record.

Use an example without turning it into a forecast

Suppose a stage response reports 760 Points, a threshold of 1,000, and available capacity. The useful statement is that the viewer is 240 Points below the reported threshold, subject to the stage’s current rules. It is not useful to say that an NFT is “nearly earned.” If a later response reports 1,040 Points but the capacity state is full, “qualified” and “allocated” must still be reported separately.

The same discipline applies to a hypothetical activity calculation. The current Swap rule is one Point per $4 of verified volume, so $400 of verified volume corresponds to 100 Points. That arithmetic describes the rule applied to eligible, verified volume; it does not prove that a particular quote, pending transaction, or simulation will produce those Points.

What an assistant may read

A model can turn a stage response into a timeline, compare two timestamps, or explain why a viewer row says partial or unavailable. It should preserve the response’s source origin and asOf time. Ask it to quote the fields it used and to leave null values as unknown.

It should not claim a live NFT mint, invent a missing cutoff, infer rollover from the number of visible entries, or convert a points plan into a claim transaction. The current agent kit’s review-only points plan opens the leaderboard route and explicitly has no wallet signature requirement; it does not refresh, claim, activate, or mint.

Read How referral links attribute a wallet for the partner side of the model and what a dry run can tell you for the simulation boundary. A status read is useful when it keeps the reader close to the raw service record. It becomes misleading when it turns a progress measure into an outcome.