6,400 NFTs that played a real basketball tournament, live.
- 6,400 dynamic NFTs: 100 for each of the tournament’s 64 teams
- 100 left standing at the end; every other token became a participation trophy
- 2 months for the smart contracts, backend and mint page
What did Bushido build for this basketball NFT collection?
A collection of 6,400 dynamic NFTs that followed TBT, The Basketball Tournament, as it was played: 100 tokens for each of its 64 teams, each showing its team’s live score or next opponent. When a team was eliminated, its tokens turned into participation trophies, until only the champion’s 100 remained. Two Bushido developers built the smart contracts, backend and free, whitelist-only mint page in two months. Stack: Solidity, Hardhat and OpenZeppelin on Ethereum, Next.js, and SST on AWS.
We build products,
not just tech.
NFT, Sports
2 months, 2022
2 developers
Smart contracts
Backend system
Mint page
Next.js, Tailwind, Ethereum, Solidity, Hardhat, OpenZeppelin, Ethers.js, SST, AWS (Lambda, API Gateway, DynamoDB, S3, CloudFront)
The starting point
An NFT collection that did not sit still. It would follow TBT, The Basketball Tournament, while it was being played, and react to live score events: each token backed one team, and when that team went out, the token would stop being a contender and become a trophy for having taken part.
Sixty-four teams, one hundred tokens each, and a collection whose value would be settled by the results.
What we built
-
One hundred tokens for every team.
Sixty-four teams at a hundred tokens each made a supply of 6,400, each token designed to represent its team, so every holder had a side in every game.
-
The live score, on the token.
While its team was playing, a token showed the score and the opponent; between games it showed who they played next. The NFT was the scoreboard.
-
Eliminated teams become trophies.
When a team went out, its tokens changed their image and metadata to a participation trophy — still owned, no longer in the running.
-
A champion’s hundred.
By the final whistle, only the winning team’s 100 tokens were still “valuable”, so the collection’s scarcity was decided on the court, not at mint.
-
A free claim, for the whitelist only.
Tokens were free to claim, and a Merkle tree whitelist meant only approved addresses could claim one, checked by the contract itself.
-
Contracts on known foundations.
Solidity on OpenZeppelin’s building blocks, developed and tested with Hardhat and wired to the mint page with Ethers.js.
-
A serverless backend and a mint page.
The backend runs on AWS through SST — Lambda, API Gateway, DynamoDB, S3 and CloudFront — and the mint page on Next.js with Tailwind.
A typical NFT, and this one
| A typical NFT | This collection | |
|---|---|---|
| What the token shows | The same image it had at mint | Its team’s live score, or the next opponent |
| When the team loses | Nothing changes | It becomes a participation trophy |
| What makes it scarce | The supply set at mint | The tournament: 100 of 6,400 survive |
Dynamic NFTs that responded to live score events and turned into trophies when their team went out, built in two months.
Questions people ask about this collection.
How did the NFTs follow the games?
Each token represented one of the 64 teams. While its team was playing it displayed the live score and the opponent; between games it listed the next opponent.
What happened to the NFTs of eliminated teams?
Their image and metadata changed to a participation trophy. The holder kept the token, but by the end only the champion’s 100 tokens were still in the running.
Who could claim a token?
Only whitelisted addresses. Claiming was free, and the whitelist was enforced with a Merkle tree, so the contract itself checks who is allowed to claim.
Yours is next.
Same team, sharper tools. Tell us where you are and we will tell you what it takes — scope, shape and a timeline we would actually hold ourselves to — on a 30-minute call with an engineer.