The story
Collecting ingredients on Intersect
Lionscraft's development work involved the first Ramadan Feast round on Intersect, using the network's native token and smart contracts for collectible items.
The archived code includes an ERC-721 contract for the food collectibles, supporting metadata and assets, and separate badge-related contract work. The initial implementation included approximately 50 food-item categories in the available metadata.
The core game let users collect or exchange items and participate in a leaderboard challenge built around Ramadan meals.
Connecting contracts to the leaderboard
Smart-contract minting was only one part of the application. The project also required an interface through which people could interact with the game and a way to read activity back from the chain.
The handover record describes a blockchain-event listener connected to a database. The listener stored relevant activity, and application logic used that data to calculate leaderboard scores.
That combination – blockchain contracts, token metadata, event ingestion and a user-facing interface – was the working application delivered for the first round.
What the first round actually recorded
A retained PostgreSQL export provides unusually detailed evidence of application activity. It covers records timestamped from approximately 28 February to 3 March 2025.
| Measurement | First-round data snapshot |
|---|---|
| NFT event-table records | 272,600 |
| Distinct token identifiers | 272,600 |
| Distinct wallet addresses | 10,293 |
| Non-null food categories in source metadata | 50 |
The event-table rows are not automatically individual blockchain transactions. The wallet-address count is not a count of people.
The value of this evidence is that the delivered application generated a substantial, inspectable event record that the team could analyse.
The second challenge: interpreting the activity
The incentive and leaderboard mechanics produced concentrated patterns of use. The technical team investigated whether some of the activity was automated or came from particularly aggressive participants using multiple addresses.
The subsequent records include analysis of suspicious patterns and work on new qualification and eligibility mechanisms, including badge-related concepts.
Those records are useful evidence of a real application encountering real usage behaviour. They do not prove every proposed follow-on round was fully deployed, or that suspected automation was conclusively established for every flagged address.