How I Designed Blockster V2: A Look at the Technology Powering Our Next Chapter

Rebuilding Blockster for V2 did not start with a technical blueprint. It started with years of lived frustration. I have built, used and studied enough Web3 products to notice a pattern.

People love the idea of decentralization but lose patience the moment they are asked to create a wallet, manage a seed phrase or pay gas just to click a button. All of that friction shows up before users get any value.

So the question that shaped Blockster V2 was simple. What would Web3 look like if the user never had to wrestle with the technology?

Once I framed it that way, the architecture almost designed itself.

Choosing Rogue Chain as the Core

I knew from experience that if Blockster V2 relied on a congested or unpredictable chain, the entire product would suffer. Real-time earnings and mass participation would be impossible. That is why I built V2 on Rogue Chain, a Layer 3 Arbitrum Orbit chain I co-founded.

Rogue Chain had already proven itself. It had been running on mainnet for a full year and consistently handled more than six hundred thousand transactions a day. That level of throughput was exactly what Blockster needed.

Rogue Chain allowed us to do something Web3 products keep promising but rarely deliver. It let us make:

• every action gasless; Rogue Chain isn’t gasless (it's powered by its native token $ROGUE), but Blockster V2 uses account abstraction so members never pay gas fees. Blockster sponsors all transactions in real time.)

• every wallet self-custodial; users just enter their email and V2 auto-creates a self-custodial smart contract wallet linked to it.

• every $BUX reward instant and onchain; rewards hit the user’s smart wallet the moment they engage, and they can instantly redeem $BUX for a number of rewards within the platform.

This was the first building block that made the rest of the design possible.

Loading tweet...

View Tweet

Onboarding without the Pain

I cannot count how many times I watched someone get excited about a Web3 product, only to abandon it within thirty seconds because the onboarding was too heavy. That insight drove one of the most important decisions in Blockster V2.
 
We removed the wallet from the beginning of the journey.

Blockster V2 starts with just an email. The platform automatically creates a self-custodial 'smart wallet' in the background—no setup, no seed phrases, no technical steps. Users simply read content, and their $BUX rewards appear instantly onchain.

This flow is a direct response to the biggest barrier I’ve seen in Web3 adoption. Users want value first. Then they are willing to engage deeper. V2 respects that.

Why the Elixir / Phoenix Framework Became Non Negotiable

Once the engagement layer became real time and the reward system became continuous, the backend needed to be extremely fast and fault tolerant. I had worked with enough social architectures to know that traditional stacks would collapse under these demands.
 
The Elixir / Phoenix framework offers the reliability and scalability I was looking for. They power WhatsApp, Discord and Pinterest for a reason. These frameworks are designed for high concurrency, low latency and constant real-time activity.
 
For Blockster, that matters when:

• thousands of users earn $BUX at the same time

• articles go viral and feed activity spikes

• airdrop windows open and everyone rushes in

• notifications and earnings happen second by second

I needed a backend that treated all of these as normal behavior, not a crisis. Elixir was the only choice that matched that requirement.

Designing Airdrops that Feel Fun, Not Technical

Airdrops have always had the potential to be interactive and rewarding — but most platforms make them feel like homework. With Blockster, I wanted the experience to feel less like navigating a protocol and more like stepping into a game. So we built the entire system around simplicity and excitement. 

Inside the dashboard, users will see one button: “Claim Airdrop.”

Clicking it automatically burns their $BUX to enter the weekly giveaway. Winners are selected at random — and the more $BUX a user submits to the weekly giveaway, the higher their odds. We’re currently organizing partnerships with exchanges to fund a weekly prize pool ranging between $10,000 and $25,000.


Another important piece: all prizes are airdropped instantly to the winner’s wallet (associated with their Blockster account). From there, they can withdraw or keep playing. 

Because Blockster V2 will also include games of chance, users can choose to replay their winnings for the opportunity to double their prize — adding a layer of strategy, thrill, and entertainment to the entire airdrop experience.

Building $BUX as the Utility Layer

One of the most important lessons I learned from V1 and from years of community work is that rewards only matter if they can be used meaningfully. That is why $BUX was designed to be the connective tissue across the entire platform.
 
It can be earned, spent, burned and used in multiple ways, including:

• claiming sponsored airdrops

• getting discounts in the Blockster shop (or redeeming merch completely free)

• accessing meetups, conferences, and parties

• participating in future games of chance that boost your $BUX balance when you need it

The idea was to build one system that ties engagement, content, commerce and entertainment together. And to make the experience entirely frictionless.

Loading tweet...

View Tweet

Looking Back at the Architecture

Every part of Blockster V2 reflects something I learned the hard way. Every onboarding frustration, every chain bottleneck, every user who said they loved Web3 in theory but hated it in practice. V2 is my attempt at building the version of Web3 I wish existed years ago. Something fast. Something simple. Something that finally feels usable.

The best part is this. Everything is real and running on infrastructure that has already proven it can scale. If reading this makes you curious, the whitelist for Blockster V2 is open: https://v2.blockster.com/waitlist. And if you have spent any amount of time in Web3, you will immediately recognize why this version needed to exist.