SUIBROKERS DAO · field note
How a trading community can analyze verified volume
A practical framework for reporting event scope, time window, verified volume, activity credits, partner data, and PNL boundaries.
Verified volume can answer questions about activity. It cannot, by itself, answer whether the activity was profitable or whether a wallet will receive a future allocation. A trading community gets more from its data when the report names the event, time window, asset, and ledger field behind every number.
Define the row before aggregating it
A useful activity table might contain:
| Field | Question it answers |
|---|---|
| Wallet | Which account is the row about? |
| Digest | Which confirmed transaction is the event tied to? |
| Pair and asset types | What was exchanged? |
| Verified volume | What value did the service accept for the rule? |
| Timestamp and stage | When and under which season state? |
| Points or Trust field | Which ledger measure changed? |
Do not fill an unknown field with zero. Keep an unavailable provider response, an empty verified history, and a pending event visibly different.
Work through a daily report
Suppose a report groups three verified Swap rows on one day: $40, $80, and $120 of eligible volume. The total is $240. Under the current rule of one Point per $4 of verified Swap volume, that total corresponds to 60 Points. The calculation is only as good as the service’s verification and the row scope. It is not PNL, return, or a prediction of allocation.
Add a second column for PNL only when the source actually provides cost basis and valuation. Volume says how much activity the service recorded. PNL says how a position or trade performed under a defined basis. One cannot be substituted for the other.
Treat partner data as a separate report
A referral report may include invited wallets, Partner Points, Trust, accrued revenue, and payout state. Keep those beside the activity table as separate measures. Partner Points describe eligible invited activity; Trust is credited Partner Points divided by five with fractional precision; accrued revenue is a ledger metric rather than a paid balance. A referral count alone does not establish activity or revenue.
The participant kit’s suibrokers_get_partner tool reads the public partner stats and history for a canonical referrer wallet. It preserves source origin, endpoint, asOf, and service states. If the service is partial or unavailable, the community report should say that rather than interpolating a total. The partner guide describes the reader-facing boundaries.
Make the report auditable
Store the query time, source endpoint, filters, and calculation formula beside the result. Link each chart to a row-level view or digest. If an AI assistant formats the report, ask it to show the source fields and arithmetic, retain nulls, and flag rows it cannot reconcile. Tool access does not turn an assistant into a verifier.
For an educational example, compare a day with verified Swap rows to a day with only a quote preview. The first can support a ledger calculation. The second can teach quote reading but should contribute no Points row. A simulation or plan belongs in a separate test table.
This structure helps a community discuss activity without promising performance. It also makes corrections possible: if a service changes a row from pending to confirmed, the report can be rerun with the new timestamp and state. Read Points and Broker NFTs before turning a stage total into any qualification statement.