Designing a Discord workshop for a first Sui transaction

A Discord workshop can make a first Sui transaction teachable by slowing down the moments that chat usually compresses: object and asset identity, gas selection, wallet approval, rejection, and confirmation. The goal is a shared mental model, not a live trading room.

Give the workshop a visible sequence

Start with a vocabulary board. Define an object as a uniquely identified unit of Sui storage, a wallet as the signer’s interface, gas as the network fee input, and a digest as the transaction identifier. The Sui object model is a useful reference for the ownership and version terms.

Move to a read-only demonstration. Show a redacted transfer or a quote with the network, asset, amount, gas, and route fields marked. Ask attendees to predict which fields belong to the app and which belong to the wallet prompt. If you use a programmable transaction block example, explain that composition describes how operations are arranged; it does not authorize them.

Finish with guided practice in which each attendee writes down the checks they would make before signing. Do not ask anyone to paste a seed phrase, private key, or unredacted address into a public channel.

Use facilitator prompts

Good prompts expose the boundary:

• “Which object or asset is this input referring to?”
• “What would change if the network label were different?”
• “Where does the gas payment appear?”
• “What can we conclude from a quote, and what needs a signature?”
• “What evidence would move this from pending to confirmed?”

When a participant gives a wrong answer, return to the field that would settle it. A confident model answer is not stronger evidence than the app or wallet prompt.

Include rejection and finality

A workshop that shows only a happy path teaches the wrong lesson. Use a harmless example of an invalid asset or missing amount and ask what the participant should correct. Then show a rejected wallet prompt as a user decision, not a failed Points event. Finally, distinguish a submitted transaction from a confirmed service readback.

The participant agent kit can help with the read-only layer. Its six tools read public status, stage progress, wallet history, Desk, or partner records. Its action plan maps a proposed swap, Desk action, partner task, or points review to an app route without prefilled transaction parameters. The plan does not quote, build, sign, send, activate referrals, or mint. That makes it suitable for a workshop demonstration when the channel clearly labels the result as a plan.

Keep community metrics legible

If a workshop discusses activity credits, say that verified Swap volume is what supports the current Points rule. A prompt, simulation, or unconfirmed event is not the ledger. If it discusses partners, explain that an invited-wallet count, Partner Points, Trust, accrued revenue, and payout state are different fields. Do not replace a missing readback with a screenshot or invented result.

Let the final exercise be explanatory: each attendee writes one sentence that separates app quote, wallet signature, network confirmation, and service verification. A workshop has done its job when members can ask a better question before they authorize a transaction.