dropwhere

Demo

About

The problem it solves Recent polling of Gen-Z attitudes towards partying showed some interesting facts about the next generations social lives. Firstly that they’re way less interested in the traditional party life, they’re more “straight edge”, and they’re still yearning for their own real-life, era defining experiences. It’s no wonder that they (or “we” I should say as a member of the group) have so much nostalgia for a time they never lived through. Dropwhere aims to address this by creating fun real life experiences that seamlessly blend on-chain and off-chain worlds. Firstly, I see two opportunities in this. People looking for new things to do, and organisers looking for new ways to incentivise those people to go somewhere. What if you could bootstrap liquidity for a token by getting people to come to a party, and airdropping all of the attendees? What if a festival wanted to offer one off collectibles, to get attendees to visit every corner of the site? These sort of incentives are possible with the system I’m attempting to create. Secondly, Most people don't care how innovative a technology is. They just want it to make their life easier or better. I believe mainstream adoption relies on this fact. By using the strengths of what is possible on chain. Such as Tokenisation, easy authorisation and signing (without the need for sign up). We can lower the barrier to entry, and offer fun and profitable experiences to users, with already existing incentives rather than trying to force adoption.

How it's made

Challenges we ran into One initial problem I had was with unlocking a lock with a password. The contract needs to have some way of knowing the password without revealing it. And the user needs to be able to provide the password also without revealing it. Although MEV frontrunning isn't an issue on base, I still wanted to ensure that if a users TX failed for some reason the password wouldn’t be exposed on chain anywhere. Zero Knowledge Proofs seemed like the perfect technology for this. I solved the problem by requiring the locker to hash a password with their address when the lock is created. When the unlocker tries to unlock, they generate a proof with the password (this part is never revealed). When they call the unlock Function with their generated proof. The smart contract injects their address, the address of the original locker & the original lock hash. This ensures that a proof can never be generated with incorrect data to try and fool the contract & a proof stolen from another user will never work. Another problem I encountered was, how can users find the locks in a fun & engaging way? At first I thought of using the Google Maps API, but just showing the locks on a map would be too easy. Instead I decided to take inspiration from old submarine radars. I created a "pathfinder api" that a users phone can poll with their Geolocation to get the distance and direction of lockups nearby (after researching the haversine formula to calculate this from co-ordinates). I then used this data to create a react component that works like a compass using the mobiles in-built Magnetometers. After some focus I managed to get a pretty good “pulse” animation so that it really feels like the user is scanning the area with a radar. This is great because it's simple and easy enough to just get started without having to download any apps or buy new hardware. You just open your browser, connect your smart wallet and you're ready to go.