Inspiration

Graphics cards are notoriously hard to get hold of. Scalping bots will automatically scrape websites for releases and buy up all the stock and avoid mechanisms such as queues, meaning humans have a very low chance of actually getting hold of one at a reasonable price. The same scenarios can be applied to ticketing systems. The systems lack fairness and the consumer loses trust in the supplier. It doesn't have to be this way.

What it does

Users mint tickets for a set fee. The contract can be modified to limit the amount held by an individual address. The released contracts are unlimited however. The admin role can then set a date and time to draw winners from the pool of ticket holders automatically and award them with a new ERC721 that can only be minted from the ticket contract. Winners are drawn automatically via Chainlink Keepers, which call Chainlink VRFv2 to obtain a random word. Once the word is obtained the Keepers will call the contract again so winners can be picked randomly (using a Fisher-Yates shuffle algorithm).

How we built it

Workflow diagram: Chainlink Service flowchart

Splitting up the contracts enables a single contract to consume a single Chainlink service whilst distributing work to multiple contracts. The project can therefore be expanded to handle multiple products without needing to deploy additional core contracts like VRFManager.sol and Treasury.sol.

  • Oracle - Relays latest ETH/LINK price for use by the Treasury.
  • Treasury - Holds WETH and LINK used to refill Chainlink services to a minimum balance.
  • VRFManager - Central contract for managing the VRFv2 consumers and subscription.
  • PrizePicker - Keeper callable contract that calls AntiScalperNFT contract once winners are ready to be picked.
  • AntiScalperNFT - ERC721 allowing public mints. Requests random word from VRFv2 and picks winners in a batch.
  • WinningTicket - Represents the actual token of value, or token that can be exchanged. Only mintable by AntiScalperNFT.

The inspiration for this came from the recent Yuga Labs mint, which could have easily avoided clogging the Eth chain by utilising a raffle based system such as this.

Challenges we ran into

The Keeper system is notably dated compared to VRFv2. Being able to subscribe to the Keeper network on-chain and be able to control the parameters like callback gas limits would be beneficial for the expansion of this project to handle multiple consumers under a single Keeper subscription. Unfortunately this is not possible under the current implementation, so running multiple product raffles must be accompanied by multiple Keeper registrations.

Having to upkeep multiple Chainlink services consumes a lot of time. This is why the Treasury contract was added. It takes revenue from minted tickets and converts it to LINK using the Uniswap V3 SwapRouter, taking care to not pay too much by comparing the swap price to the Chainlink ETH/LINK data feed. The treasury can therefore be used to upkeep all Chainlink services without manual management.

Keeper Registry code is using an old version, which means that performUpkeep overwrites the balance at the end of execution. The Treasury therefore sends funds into a blackhole on the demo project as it attempts to fund the upkeep as part of the performUpkeep function, which does not work on the current version of code. In v1.2 of the Keeper Registry this is fixed.

Accomplishments that we're proud of

There is no Vue3 drop-in component available that works well right now. This project uses a custom connection component for the prototype site that should prove useful for many other dapp developers in the future.

The contracts are fully documented and covered using unit and e2e mainnet tests, ensuring integrity of future development and an easy start for anyone wanting to fork the code for their own product releases.

What we learned

  • Managing LINK upkeeps via a central treasury makes systems much easier to manage.
  • VRFv2 subscriptions make consuming random words a breeze.
  • Keeper network is great but could use an iteration much like VRFv2.
  • I should read through the Chainlink workshops before deciding on a project to see if they're planning on making a basic version as a workshop!

What's next for Anti-Scalping Prototype

I'd like to add one more Chainlink Service once made available - CCIP. Adding cross chain ERC721 to the workflow will be a huge breakthrough for fair distribution of tokens across all chains.

Built With

Share this project:

Updates