SUIBROKERS DAO · field note
An NFT community lesson on referrals and wallet actions
A community education format that separates NFT ownership, links, wallet connections, attribution, Trust, and verified activity.
An NFT community can teach wallet actions without implying that ownership creates a reward. The lesson should separate four things members often blend together: holding an NFT, opening a link, connecting a wallet, and receiving a measured service outcome.
Start with the action, not the perk
Choose a teachable action such as reading an asset identity, checking a swap quote, or following a referral link to the correct app route. Explain why the action matters before discussing any proposed community benefit. A holder can read a link and decide not to connect. A connected wallet can still have no verified activity. An NFT badge does not prove either event.
Use a simple comparison:
| Event | What it establishes |
|---|---|
| NFT ownership | The wallet owns the token recorded by its source |
| Link opened | The visitor reached the destination |
| Wallet connected | The app saw an explicit connection attempt |
| Referral attributed | The service accepted the wallet under its rules |
| Activity verified | The service recorded eligible activity |
Keep the rows separate in the Q&A and in any community dashboard.
Teach the wallet boundary
Show a redacted app route and a sample review screen. Ask members to check network, asset identity, amount, recipient, gas, and slippage before signing. A screenshot can illustrate the lesson, but only the current wallet prompt and later service readback establish what happened for a particular person. No moderator should ask for a seed phrase or private key.
If an assistant is part of the lesson, give it supplied data and ask it to define the fields, identify gaps, and list questions. The participant kit can read public status, stage, history, Desk, and partner records; its action plan is review-only. It does not activate referrals, request a payout, sign, or mint. The AI referral guide explains why a URL alone cannot establish attribution.
Explain proposed perks precisely
Use “proposed” for a benefit that has not been published as a current rule. Do not invent a reserved allocation, discount, reward, or partner result. If a current partner record reports Partner Points, Trust, accrued revenue, or payout state, define each as a separate ledger field. Trust is derived from credited Partner Points divided by five without dropping the fraction; accrued revenue is a ledger metric, not a paid balance.
An example can be hypothetical: if a service response reports 12.5 credited Partner Points, the arithmetic for Trust is 2.5. Label it as an interpretation of that supplied value, not as a promise to holders. If the response is unavailable, say so.
Give the community a repeatable format
Make the lesson a pinned card, a five-minute screen recording using redacted data, and a short exercise. Ask members to answer which event they observed and what evidence is still missing. Keep a change log when the app route or published rule changes. Link to the partner rules and the Sui wallet primer so the community has a source beyond a chat message.
The useful outcome is a reader who can say, “I own this NFT; I opened this link; I connected this wallet; the service reports this record.” That sentence keeps community identity, wallet control, attribution, and rewards in their proper places.