Drop Shop Logo

Inspiration

One of us bought and resold sneakers back in the day and he remembered lots of inefficiencies and unfairness:

  • Loyal customers without the means or capabilities to set up bots have to buy from the resellers at inflated prices (not fair).
    • Products are being double shipped - first to the reseller and second to the end consumer (inefficient).
    • Brands and resellers are constantly evolving their anti-bot and bot software (inefficient).
    • The marketplace is flooded with fake products and scams (not fair).
    • Consequently, an entire ecosystem has been built around product authentication (inefficient).
    • Resellers with "plugs" (eg. they know somebody at Nike) have special access to more products (not fair).
    • Although resellers help brands promote and sell out of products, brands don't capture any of the value generated in the secondary market.
    • For concert tickets, i.e, they can't increase supply because there's a physical limit to how many people can attend, nor can they raise prices because that would anger their customer base, so they're forced to sell out to resellers (not fair).

Then we looked around and noticed a few more areas to be improved:

  • Chainlink did a t-shirt giveaway, but it wasn't the most loyal Chainlink fans who won, it was the people with the quickest hands (not fair).
  • SF artist Fnnch sent an email to promote their eBay art auction where the proceeds would go to a charity. That sounded nice, but how could we verify where the proceeds ended up? Bicycle brand Trek did a similar fundraising promotion (not transparent and possibly not fair).
  • A strong community is a huge asset these days, take Chainlink's community for example. But, how can all those loyal fans who post on Twitter, set up fan pages, and engage with the brand/organization, be rewarded in some form?

Finally, we thought about the mechanisms that products/any form of value can be transferred these days:

  • Given away for free.
  • Sold for a flat fee.
  • Auctioned to the highest bidder.
  • Raffle.
  • Bartered for.

All of these (except getting something for free) require capital from both parties. However, for many people, they have more time or passion , than they have money or assets. Time and passion and helping build community is extremely valuable, yet, it's always been a struggle for organizations to attract and for individuals to be compensated for.

This ultimately led us to what we built.

What it does

Use case #1 - Limited release drops Brands promote their drop by encouraging community engagement with brand-specific tokens. Nike promotes shoe drop by giving tokens in exchange for promotion There's a fixed quantity of items, a minimum USDT entrance fee, and a set time period to enter:

  • Quantity = 2,500 shoes
  • Minimum fee to enter = 100 USDT
  • Duration = 2 days

Maximum 1 item can be won per wallet address. A participant's odds of winning are determined by how many USDT and BRAND (i.e. NIKE) tokens they stake. Brands can parameterize these:

  • Odds = USDT * (currency weight) + NIKE * (token weight)

You may also find NIKE tokens being listed on decentralized exchanges. Fans enter Nike drop using Nike tokens or USDT While the lottery goes on and tokens are locked in the contract. Brands may wish to do low-risk lending and distribute the interest between them and the participants. Yield farming while lottery takes place When it comes time to pick the winners, the smart-contract fairly and transparently decides by taking into account each participant's odds (based on their stakes and the brand's weighting parameters), and some verifiable randomness. The winners trade their entire stake for an NFT exchangeable for the item and the losers get refunded. Winners and losers Since the final winners may have staked a lot more than than the minimum entrance fee, brands may choose to split the surplus between themselves, all participants, and maybe a good cause like a charity. They could also send brand tokens to everyone who participated which could be used in future lotteries.
Surplus split The winners receive NFTs that can be used in three ways:

  • Exchanged for the real item
  • Resold on the secondary market
  • Destroyed for assets that the brand may have locked inside

Brands get to decide if the NFTs can be resold, how the resale royalties would be distributed, how long the NFTs could be resold for if the NFTs have burnable assets locked inside, and whether or not consumers can keep a copy of the NFT (to be used in metaverse worlds) in addition to the real item they exchange it for. We expect brands to allow resale for a limited time period because they don't want to store physical inventory. If a brand isn't too trustworthy, we expect them to lock a fair amount of value inside the NFT as insurance for the winners in case they get cold feet and just want a partial refund instead of the risk of sending their NFT back to the brand and possibly never receive the physical item. Post release scenarios Finally, since all of this is occurring via decentralized networks and smart-contracts, it's all transparent and verifiable. The flow of tokens and smart-contract computations can be easily tracked and monitored. Analytics

Use case #2 - Fundraising and Promotion An organization (possibly a non-profit) or an artist wants to raise awareness or promote something. Similar to a brand, they announce their promotion and can give away tokens to promote it. art

For the fundraising auction, people can participate by depositing money and organization tokens. We expect a low or zero entrance fee since the priority is raising awareness and having low barriers to participate (this is for charity). The process is similar to use case #1. The winners get whatever is being auctioned but the losers don't get refunded, instead, their money goes to the charity/artist/organization. All of this is transparent, you can see if the money really went to the charity or if someone actually did a dollar-for-dollar match, and it provides a fun way of encouraging participation in fundraisers/promotion events.

How we built it

Smart contract details:

We have two main contracts and each one is a composition of many modules/legos/building block contracts.

  1. Manager smart-contract: Responsible for creating, editing, and canceling lotteries. Sets royalty rules, stores data, communicates with Chainlink to pick winners.
  2. Assets/tokens smart-contract: Its base is an ERC1155. It holds all of the non-fungible, semi-fungible, and fungible tokens. Non-fungible tokens are one-of-a-kind like a single painting. Semi-fungible tokens are semi-unique, like 20 size medium Supreme t-shirts. Fungible tokens aren't unique, like general brand tokens. This contract manages all the token minting, burning, and transferring. Additionally, it allows brands to lock tokens inside their NFTs. It does this by accepting ERC20s, ERC721s, and other ERC1155s, and maps them to their associated NFT id. Then, if an NFT owner desires, this contract can burn the NFT and transfer the assets locked inside. This was inspired by Enjin's gaming NFTs.

These two contracts communicate with one another. Organizers create and manage their lottery via the manager contract and NFTs representing their items and their organization/brand tokens are minted on the assets/tokens smart-contract.

The following describes how interactions with the smart-contracts are logged, what off-chain events occur, and how the smart-contracts pick the lottery winners:

  1. Both smart-contracts emit events over time and TheGraph builds a subgraph from them (like when token transfers happen). This keeps track of all the deposits, lottery states, token transfers, and more. It's not only useful for analytics, but it's critical for picking the winners.
  2. To pick the winners, the manager smart-contract makes a request to a Chainlink oracle asking for a verifibaly random number. This also gets logged on the subgraph.
  3. Next, the manager smart-contract makes a request to a chainlink oracle which forwards it to a Chainlink external adapter, asking for computationally expensive math computation to pick the winners. This is an expensive computation because winners are decided via a token weighting algorithim that would be too expensive to compute with the blockchain's resources
  4. The external adapter then makes a request to the Fluence service (off-chain decentralized server).
  5. The fluence service queries TheGraph and uses data on the subgraph+our weighting algorithim+the chainlink random number to pick the lottery winners.
  6. (optional) Fluence connects to Ceramic and sticks the result on IPFS.
  7. Fluence returns the result to the Chainlink external adapter.
  8. Chainlink external adapter returns the result to the chainlink node which returns it to the smart-contract.
  9. The manager smart contract uses the assets contract to transfer the NFTs to the winners, refund the losers, and distribute surplus tokens however the organizer set it up. NFT metadata is put on IPFS and stored with NFT.storage so that the winners can rest easy, knowing the NFTS will forever remain online.

You may wonder why we chose to run the selection algorithm with Fluence instead of a simple AWS lambda server. This was because an AWS or Google server would represent a single point of failure (risky) and the computation it does can't be easily verifiable and monitored. Fluence lets us run the selection algorithm on decentralized servers and every computation it does is logged, transparent, and can be watched.

smart-contracts

Selection algorithm details:

We randomly select the winners among participants who have different probabilities to win. As mentioned above, the probability depends of the USDT and brand token a participant stakes for the lottery, i.e., $$ \mathcal{P} \left{ \textrm{winning with USDT 110 and brand TOKEN 15} \right} \sim \left(\frac{110}{100}\right)^m \times 15^n $$ It should be noted that the probability is not absolute but relative.

Now we select the winners randomly. It is important to note that randomness is not just arbitrary but has to be verifiable. Thus we generate a seed using Chainlink's VRF. With the seed, we generate a list of participants randomly.

Whitepaper details:

As we began developing a specific solution to the problem of Bots and Drops, we realized a Blockchain powered lottery based solution could be generalized further. As such, we felt it important to document this in both our Whitepaper, as well as our Gitbook.

Devpost submission details

Have you noticed? All of our images or located on IPFS and stored with NFT.storage! They make it so effortless now!

Challenges we ran into

Each one of us had our own challenges.

Ryan:

As a team with relatively little hackathon experience, establishing workstreams, coordination structures and communication norms took some time, but that was helpful learning in itself. From a project mechanics standpoint, as someone who doesn't have much smart contract development experience (and not much development experience period) working through gaps of knowledge to create sound decentralized protocols was challenging at times. Fortunately, Colin was up to the task in walking me through the possible and impossible.

Seung:

Vague idea we had in the beginning has to be realized into concrete forms. This has been the challenge. My vague ideas were not the same as others not meticulous enough, but toward the same goal we ran a race together. Personally, it was my first hackathon, so I was not quite sure about the process how things are done in a hackathon as well as my role of "a math guy". But I managed to fill in the jobs that need math. Specifically in random selection. I have been the user of random number generators but never looked into seriously before. This experience let me think about ergodic theorems that I forgot so long. The last but not the least challenge has been the fast changing scenery of blockchain development environment. Maybe it's because I am not a real blockchain developer yet, but those concepts and protocols in this world have overwhelmed me. So my personal study goal has been set, thanks to those hard working people. Sooner or later, I would be one to contribute to this community.

Colin:

At the beginning of the hackathon, I was going through analysis paralysis. I was spending too much time comparing different developer tools, frameworks, and templates, instead of just building. I was also trying to learn Figma and UI dev when I should have just focused on the smart-contracts. The smart-contracts ended up being my most advanced ideation and hardest build to date. I dug deep into the Ethereum EIPs, specifically EIP-1155 (it's awesome by the way) and EIP-2981. The challenging part was trying to learn and build in parallel. I constantly had solidity docs, medium posts, GitHub discussions, blogs, and tutorials in one window, and my VSCode editor open in another window. I kept building and destroying and rebuilding. The whole team kept brainstorming new ideas. I always hope things would go smooth and easy but it's always a challenge and I'm always being pushed.

Accomplishments that we're proud of

Each one of us is proud of different things.

Seung:

I contributed to the team with my math skills, which has been underutilized in my current job. I become a proud mathematician again. Besides, I have finished my first hackathon project, which I am proud.

Ryan:

Decentralization is a very difficult concept to fully absorb. Centralized structures have been all most of us have ever known. We create centralized process without even realizing them. I'm proud that over the process of building out this protocol with the team, my thinking has become way more decentralized. I've developed a whole different way of looking at interactions and incentives.

Colin:

Thanks to Zak's Chainlink video on running your own oracle node, I felt confident enough to run my own. I'm really proud of this, I feel like it's a rite of passage in a way. I ran my own oracle node in order to test my fluence external adapter. I'm also really proud of that, it was my first time successfully building an external adapter! I'm also proud of everything I learned ...

What we learned

Each one of us learned different things.

Colin:

I learned about so many web3 protocols. I loved exploring the Ethereum proposals, TheGraph, Fluence, Ceramic, and SuperFluid. SuperFluid is sick by the way! I tried thinking of ways to incorporate it but nothing spectacular came to mind. Oh, and when I uncovered Enjin NFTs tokens within the tokens mechanism (by listening to some podcast), I was ecstatic. I haven't really seen this catch on yet, nor have I seen ERC-1155s catch on, but I think there's a ton of potential. However, perhaps the biggest lessons I learned came from working with a team. In the last hackathon, I worked solo. Although that went fine, nothing great is built alone. This hackathon taught me more than ever before how important a team is. We had big ambitions and could have used an even bigger team. Even with three smart teammates grinding daily, we weren't able to build everything out. Great products need lots of hands to build them and working with a team was new for me and something I need to get better at.

Ryan:

I really enjoyed learning more about the capabilities and limitations of smart contracts and oracles systems. And as I mentioned earlier, learning how to think in a decentralized manner has been helpful even beyond this project.

Seung:

I learned there is a whole new world of blockchain. As a newbie knowing hypes in blockchain, I was not quite aware of many apps protocols. Though I do not digest all those things yet, I have become to think in blockchain and in decentralization. Moreover, it is a valuable experience to work remotely with team members in the different time zone.

What's next for DropShop

Ha, we have a lot to build! #TODO - Build out community, UI, smart-contracts, subgraph, and Fluence service. Maybe make it a DAO. But first, are people even interested in this? Let us know in the comments below ⬇️ or tweet on Twitter 🐦 #DropShop. Who knows, maybe you'll get our first DAO token 🤷

Built With

Share this project:

Updates