I write code sometimes.
My Articles →
Joined September 2021
- Tweets4K
- Following842
- Followers3.3K
- Likes10.5K
At some point you just gotta call out insanely stupid tweets.
People have been doing on-chan hot potato for legit years. Even during the peak NFT bull run.
But yeah insanely gud tech. 😂
One of the best pieces of tech I've seen on Solana in a while is getting almost no attention.
These guys built an onchain hot potato game, but instead of passing a potato, you're passing a bomb 💣
It's actually pretty simple.
You pay 0.05 SOL to take the bomb. Every time someone takes it from you, the price increases by 2% and the 2 minute timer resets.
Here's the catch. The bomb can explode at any second, and the longer nobody takes it, the higher the chance it blows.
Whoever is holding it when it explodes wins 75% of the entire pot. The remaining 25% goes into the next round.
Every 25th round on average is a GRAND SLAM, where a jackpot funded by $BOOM trading fees gets added to the pot.
Every time someone takes the bomb, 94% goes into the pot, 5% buys and burns $BOOM, and 1% goes to the team.
And if nobody takes the bomb from you, you get your SOL back plus a bonus.
The craziest part is that everything happens onchain. Every move, every explosion and every payout is verifiable on Solana.
No bots sniping the last second, no team holding the prize money, no trusting anyone to pay you.
Just a bomb, a growing pot and people trying to be the last one holding it.
Pretty wild that something like this is flying under the radar.
Another funny thing was when sites implemented queue on product pages but not the API calls required for ATC through to checkout.
Even better was when they added it on ATC but didn't think to cover alternate ATC paths like adding from wishlist or some other obscure path.
Demandware was/is honestly one of the sauciest eComm platforms to bypass WAF on. You can always bank on there being SOMETHING there.
Don’t think I ever touched a single DW site without finding something.
File ext, path traversal, URL encoding, and the list goes on.
The Adidas stock bypass:
So this was only protected on the Akamai WAF layer rather than being removed from the website meaning any Akamai bypass on the path would let me access the endpoint as if it was normal.
The rule spec was any path directory with "Product-GetAvailability" would be blocked. I had to find a way to trick Akamai into thinking it was a different path whilst the origin still returned the same content
The specific bypass for this was appending: "; %2f" before "Product-GetAvailability".
Akamai interacts with semicolons very strangely, it would ignore everything after the semicolon up until the next forward slash, in this case it was the %2f (encoded "/") This caused Akamai and the origin to disagree about what the URL truly means. Akamai thought it was different but Adidas' origin normalized it to the same demandware URL returning the correct response.
The reason for the massive quantity parameter was because if you put 1,000 it would only return up to 1,000 in the "IN_STOCK" quantity.
There used to be a super interesting/niche queue bypass for Demandware + QueueIT.
If you routed all your requests through DW API calls and inserted thousands of full stops somewhere in the URL, you’d bypass all Queue/Antibot.
I never understood why it worked but it did. 🤷
Funny cause this approach of distributed systems for queues is still being used in some bots today.
There was a queue bypass on old Mesh where all you had to do was rename the initial queue cookie (akavpau?) to the passed queue cookie name (akavpwr?) and you’d bypass queue.
Seeing a lot of cool engineering stories from bot developers, so I want to share a cool innovation from Sneakercopter I think about a lot which revolves around handling of the Queue.
In 2018/2019 Mesh used to always drop their limited sneakers on the app. This meant they always had to try and hide their HAWK hashing secret key somewhere in the app, but that was basically impossible for them to do as if it's signing requests - an android debugger will find it.
They then switched to web releases directly on their website, powered by a Queue-It based "waiting room" style mechanism where users had to wait in a waiting page before being able to access any of the website. Like many others, this was powered by a cookie that needed to be issued if you'd been given permission. No cookie, no entry. This meant I had to build a Queue style handling mechanism similar to some of the other waiting room bots.
In doing so, I noticed two key characteristics of the cookie that was populated when you were allowed to go through the page:
1. It had an expiry, but the expiry would refresh on every new interaction you did with the website.
2. The cookie was not locked to an IP address.
Those two findings were actually super important, especially when realising that what point 1 was actually doing was issuing you a *new* cookie with a new expiry date, and not expiring the old cookie. This means that in theory, you would only need to have one valid cookie in order to generate many more (simply by visiting new pages). Then, those cookies could be used by anyone for their TTL.
With this in mind I fundamentally rebuilt Sneakercopter to actually be a large distributed system with only one mission in mind - get one instance through the queue at least one time and then announce the cookie to all other instances. This means that every Sneakercopter instance was actually connected with a TCP socket server reporting it's progress in the queue to see if it was selected to go through the queue.
Once somebody was selected to get through the queue, that user's instance of Sneakercopter actually sent the cookie that they got in order to enter the website to the TCP server, and that server would announce and distribute that cookie to every single other user of Sneakercopter instantly - allowing everybody to make it through the queue and create their own queue access cookie that they could use to check out.
This architecture powered probably the most successful period of Sneakercopter when it came to frontend web checkouts, and the beauty of it is that it was an edge that was only possible with scale. You had to get through the queue normally at least once to use it. We had a large user base of people running the bot that all were working together to make it past the queue. So a single person making a script would not be able to use the same approach as our full user base was actually helping each other succeed.
This was patched a long time ago of course, but it always stuck with me as an innovation i'm most proud of, but also as a lesson I took with me when I went on to build the mechanics to protect major sneaker launches. Details matter and they can have compounding effects when a creative mind tries to bend the rules - always when building a mechanic I thought "how can I break this?"!
As standard, these solutions were implemented and thought of in the middle of the night before a drop 😃
Fun fact, a variation of this bypass existed for Footlocker sites in Asia (inc. AU) that were on Intershop eCommerce.
I’m confident a few friends and I were the ONLY people using it in AU. Had it for about 6 months before it was clipped for good and shoes died.
Money was MADE.
some footlocker bypasses from the past:
origin bypass, if you set up fastly vcl pointed at ftl origin, u would get past the timeout on the website, but they had another layer so me and the nyte guys sifted through a ton of logs (when fastly used to return other peoples headers in your requests lmao) and found one specific header (iirc x-fl-edge-id) and one specific value that would get past it
i remember i stopped socks on footlocker from being able to be bought for an hour by accident w/ it
queue/dd/cache, would send requests from fastly edge that would get no datadome, set fastly host header to ftl, then in host header cycled between ports 1 thru 65535 (minus a few) to bypass cache, and also queue. also needed some other headers to prevent 5xx error server restarts (lol)
Fun fact, I once had a Queue-It bypass that worked on all sites powered by a specific e-comm platform (it was a popular one).
It worked by inserting thousands of . characters at a specific point in the URL. For some reason, it would completely bypass the queue.
Made $$ with it.
This quoted post is unavailable.
This is beautiful, brings a tear to my eyes.
I built a script that gives me a fake phone call to escape boring and awkward situations. I bought a virtual number from @twilio and saved it as one of my relatives.
Whenever I feel stuck, I just tap a button called “ESCAPE” on my phone. It sends a request to my remote server. The server runs a small Python script which schedules an actual call. After a minute, my phone rings and plays a pre-recorded audio.
I simply say “sorry, I’m getting a call” and walk away. A tiny project, but it has saved me so many times 😅
Alan retweeted
Low liquidity coins on automated market makers with exponential price curves are shitcoins.
You can call them Creator Coins, Culture Tokens, Internet Capital Markets, Music Tokens, AI Tokens, or Memecoins, but it won't change the toxic fundamentals.
It's a zero sum PvP game of musical chairs. Nobody leaves with more than they came with unless someone else is losing. And retail gets rinsed by snipers, bundlers, coordinated pump and dumps, FNF groups, and industrial scale autonomous trading bots.
Repeatedly pretending you don't know that is disingenuous, delusional and at best naive for anyone who's been in crypto for more than a year to suggest otherwise.
You can't just rename "minting dogshit with no liquidity and putting it in a Uniswap pool" to Creator Coins and expect the outcome to be any different without at least trying to alter the tokenomics, or at least some kind of flywheel, to prevent the obvious outcome.
99.99999% of tokens like this go to zero with haste, anything that survives for more than a year is an extremely rare exception to the rule.
I"m quoting Coop directly here, but really I'm talking to everyone making new token launchpads and shipping the same product over and over and over again promising different results.
Also talking to anyone buying these coins and professing that, "Bro. I swear bro this time it's different. They're culture coins, creators bro. I swear bro, this time it's different. No no, there's an AI. You don't get it. The token is for a song and you're early to the song. No bro trust me. This is the future. It's not like literally every other coin with the exact same tokenomics. This time it's different bro. Buy my bags bro please. Please buy my bags. I am crying, pissing, and shitting in my pants bro trust me."
And to be clear, sometimes I like trading shitcoins. It's occasionally fun to light money on fire trying to hit a 20x. But I know what game I'm playing. And I'm not flooding the timeline trying to convince anyone it's not a toxic hypercasino hellscape.
Alan retweeted
Never embed "product concepts" into code, specially smart contracts.
If it's an escrow call it an escrow.
If it's an oracle, call it an oracle.
Call it whatever you want when marketing it externally, but introducing marketing terms inside code is just horrible devX
