DropKit: Sui Ticketing
DropKit is a testnet-oriented Sui Move hackathon prototype. The inspectable code covers event lifecycle and check-in; the submission describes a broader resale and royalty direction.
What the public submission claims, and what the code demonstrates
DropKit was submitted to Cal Hacks 12.0 as a Sui-native ticketing concept. Its public Devpost entry describes one-click transactions, Kiosk resale, Transfer Policy royalties, QR-based check-in, attendance minting and Walrus posters.
The retained repository is testnet-oriented. The inspectable modules support the event, payout, ticket and check-in model; those objects should not be read as evidence of audited mainnet deployment, functioning resale royalties or an operating ticket business.
The publication gate lives in event state
The event object records an organizer, time, location, supply, status and a Walrus poster content identifier. The setup path creates an event with payout configuration, activates a sales channel and issues distinct capabilities for administration and gate check-in.
Publication requires payouts and at least one active channel. Making those prerequisites explicit in Move reduces dependence on a front-end workflow to enforce them.
| Object or capability | Inspectible rule |
|---|---|
| Event state | Organizer, timing, supply, status and poster identifier |
| Payout configuration | One to four recipients; no duplicate addresses; total allocations at most 100% |
| GateKeeperCap | Bound to one event; used for check-in authority |
| Ticket | Records class, event identity and whether it was used |
Describes retained public source, not observed mainnet usage.
A ticket has an identity and a used state
The ticket records its class and event. A check-in operation requires a gate capability for that same event and aborts if the ticket is already used. A QR code alone is not the authorization mechanism.
The payout module validates recipient configuration and can split SUI using basis points. These rules make payout and gate rights inspectable independently of a UI, though they do not establish that full marketplace or resale handling exists.
A TransferPolicy scaffold is not a royalty rule
The public Move source includes a TransferPolicy administrator that creates and shares a TransferPolicy<Ticket> plus its capability. Its comments leave royalty-rule additions for later work. That constructor alone does not enforce the submission's proposed multi-recipient resale economics.
The intended anti-scalper pricing, attendance mint and Kiosk resale narrative should be evaluated against code still needed to realize those flows. No hackathon award, security audit or production use is claimed.
Inspect the public artifacts
The Devpost submission records the intended product; the public repository records the implementation boundary. The distinction is the useful engineering evidence.