I have always been deeply cautious about raffle-based group buying.
Not because I oppose probability, and not because I oppose gamified participation, but because the core problem in this industry has never really been the format itself.
It has always been trust.
In traditional raffle-style group buying, users are almost always in the weakest position. You can see the rules, but you do not know whether there are hidden parts. You can see the result, but you cannot verify how the drawing was conducted. You can see the word “fair,” but you are not actually given the power to verify fairness for yourself.
There are plenty of real-world examples. The U.S. Hot Lotto fraud scandal from 2010 to 2017 is a classic case: Eddie Tipton, the information security director of the Multi-State Lottery Association, used his position to install a backdoor in the random number generator and manipulate lottery drawings across multiple states including Iowa and Colorado, involving more than 1.8 million. Hot Lotto fraud scandal 43 years ago today the Pa. Lottery scandal
In most traditional models, the organizer holds three kinds of power at the same time: the power to define the rules, the power to execute the rules, and the power to explain the outcome.
What does that mean? It means everything users see is often only the part the organizer is willing to show. You have no reliable way to know whether the rules were fully disclosed, whether the drawing logic was truly fixed, whether there was human intervention in the middle, or whether the final “winning result” was actually generated according to the original rules.
When rulemaking, execution, and interpretation are all controlled by the same party, fairness often becomes little more than a marketing phrase.
That has been true of many long-running legacy projects, and it remains true for many online raffle group-buying sites that came later. The interface may look more professional, the copy may sound more polished, and the operators may become more sophisticated, but as long as the foundation is still a black box, users are still being forced to trust the platform instead of verifying the outcome themselves.
That is why I am building OneTappy.
If the world is going to keep having raffle group buying, random allocation, and competition for scarce opportunities, then at the very least those systems should be built on a foundation that is more transparent, lower cost, and harder to abuse.
Many people assume that online raffle group buying is more advanced, more convenient, and more trustworthy than offline versions.
But based on more than a decade of work experience, I often feel the opposite is true.
The internet makes raffle group buying easier to reach users, but it also makes black boxes harder to notice. A website with a professional-looking interface appears more legitimate than a street-side booth, but legitimacy is not the same as transparency, and convenience is not the same as trustworthiness. It becomes even harder for users to know whether probabilities were adjusted behind the scenes, whether participant lists were edited, whether the drawing logic was changed, or even whether the process they saw on the front end actually matched what was executed in the backend.
The more convenient, the more frequent, and the more black-box a product becomes, the more dangerous it actually is for ordinary users.
Because it also outsources suspicion itself. Users stop questioning things not because the system became more transparent, but because the product experience became smoother.
“Smoothly trusting the organizer” is not real progress.
I do not believe that simply putting something on-chain automatically makes it fair.
What I truly believe in is not the word “blockchain” itself, but the key shift it enables: verification can begin to replace promises.
In the traditional model, players give money to the organizer, the organizer says the drawing will be fair, and if there is a technical service provider, it is usually just another part of the organizer’s stack. The whole model is built on trusting people.
Blockchain creates a different possibility: rules can be made unchangeable, execution can be made public, and outcomes can be made verifiable. That also changes the relationship between organizers, technical service providers, and players. Trust no longer has to be concentrated in a single party. Instead, it can be transferred into an open, verifiable execution system.
That is the real starting point for why I decided to build OneTappy.
What I want to build is not a raffle group-buying product that merely “looks more Web3.” I want a raffle mechanism that truly turns fairness from a verbal promise into something publicly verifiable.
That is also why I make several points very explicit in OneTappy’s public materials:
To me, these are not marketing slogans. They are preconditions for the project to deserve to exist. Only when the rules are public, execution is public, and fund flow is public does the word “fair” begin to carry real meaning.
I respect the value of existing Web3 randomness solutions. They have moved far beyond traditional centralized systems, and they have genuinely made verifiable randomness more discussable and more practical.
But that does not mean the problem is fully solved.
For me, once you try to bring these mechanisms into lightweight, campaign-oriented, high-frequency use cases, “technically feasible” is not enough. You also need to think about at least four things:
Many existing approaches focus on “how to generate a random number.” What I care more about is whether that randomness mechanism can truly enter real business relationships and be used over time by organizers, partners, and users together.
That is exactly why I keep building OneTappy.
Chainlink launched its Verifiable Random Function (VRF) in 2020. It is mature technology and highly respected across the industry.
If the only question is “how do we generate verifiable randomness,” then Chainlink is obviously an important answer. But I was never trying to build a technical demo. I want to build a product system that can actually serve campaigns, partnerships, and organizer growth.
From a practical cost perspective, Chainlink VRF is still expensive for many lightweight, high-frequency, campaign-driven scenarios. On Ethereum mainnet, the fixed premium for a single VRF request is often around 0.25 LINK, and once gas is included, one request can easily cost several LINK or more. Even on L2s like Arbitrum or Base, where gas is cheaper, you still have verification gas, callback gas, and L1 buffer overhead. For small, frequent campaigns, that accumulated cost and prepaid funding burden are far from trivial. Chainlink VRF cost estimation
It feels more like a powerful foundational infrastructure layer than a solution naturally aligned with the business structure I want to build around.
I am not saying it is bad. I am simply very clear that it is not a complete fit for the direction I care about: lower cost, closer to real campaign structures, and more suitable for sustained long-term use.
OneTappy uses a randomness design that combines partner commitment, player-contributed randomness, and on-chain data. It is transparent, publicly verifiable, and does not require paying an external VRF service fee for every single campaign.
Another common path is to use mechanisms like RANDAO or traditional commit-reveal.
They certainly have their strengths, but their weaknesses are also clear: the interaction flow is usually more complex, there are usually more steps, ordinary users have a harder time understanding them, and the real-world friction is higher.
That may sound like a product-detail issue, but in my view it is actually a core factor in whether a system can really work.
Because every extra step adds cognitive cost, waiting cost, and dropout cost. Multi-step flows are unfriendly to ordinary players. For partners, complexity directly harms campaign conversion. And for the whole system, complex interaction makes it much harder for “theoretical fairness” to turn into “real adoption.”
One number that OneTappy keeps emphasizing is reducing player interaction from 2 steps to 1. Instead of asking players to commit first and reveal later, OneTappy lets the player submit both the ticket payment and their personal random number in a single on-chain action. The partner submits a commitment in advance, then reveals it after the campaign ends. This structure is not meant to “look cooler.” It is meant to remove half the player’s interaction burden and move complexity away from the user.
My goal has never been to build something that only works in theory. I want to build something users are willing to join, partners are willing to organize around, and the whole system can actually run on.
This is where I differ most from many existing solutions.
A lot of systems frame the problem as “how do we generate secure randomness,” but real-world campaigns are never just a math problem. They also involve organizers, promoters, participants, fund distribution, responsibility binding, and incentive alignment.
Without a real cooperation model, even the best randomness mechanism is hard to adopt in practice.
From the beginning, OneTappy was not designed around “randomness alone.” It was designed with partners, players, revenue sharing, responsibility binding, and incentive constraints all built into the system. To me, those are not optional add-ons. They are part of the foundation for whether the system can stand at all.
I do not want to build just another “randomness tool anyone can call.” I want to build a fair participation infrastructure that can actually serve partners, campaign organizers, and long-term use cases.
More precisely, the model currently shown publicly in OneTappy is not one where “the platform takes most of the money.” Instead, the allocable structure of each campaign is written into the contract at creation time and made visible to both sides from the start.
For example, in the current on-site demo, suppose a campaign has 10 tickets priced at 0.1 ETH each, making the total participation amount 1 ETH. The default distribution currently shown is:
The key point here is not “how much gets split,” but that the distribution method is public, fixed, and verifiable from the beginning. The organizer knows how much they earn. Participants know how much the organizer gets, how much the protocol gets, and how much is in the prize pool. That kind of transparent cooperation structure is itself part of trust.
From this structure, OneTappy’s goal is not to let the platform extract most of the value. It is to leave as much value as possible with the people actually organizing and participating in campaigns.
Throughout the process of building OneTappy, a few judgments have never changed for me.
First, fairness is not a slogan. It must be verifiable.
Second, cost must be low enough to support real business, not just a handful of high-value scenarios.
Third, interaction must be simple enough that ordinary users can participate without understanding complicated mechanisms.
Fourth, the mechanism must naturally work for partners, not just for protocol designers.
Fifth, the system should not only reduce the space for cheating, but also make honest cooperation the more rational choice.
These are not pretty lines I came up with after the fact. They are things OneTappy is trying to implement directly in its product structure, one by one.
OneTappy does not ask users to “trust us to be fair.” It tries to place the verifiable parts directly in front of them.
In other words, OneTappy does not treat “fairness” as a branding phrase. It tries to turn it into a state that outside observers can independently audit.
If a system only works in high-value, low-frequency, well-funded scenarios, it is unlikely to change the industry in a meaningful way.
The direction OneTappy takes is to let campaigns start from participation thresholds as low as $1, while avoiding the kind of heavy fixed call costs that come with external randomness services. The phrase $1 -> Collectively Unlock Anything only means something if the underlying mechanism does not consume the economics of small campaigns.
At the same time, OneTappy does not build its revenue model around aggressive extraction. Instead, it publicly presents a sustainable but relatively restrained distribution structure. In a 1 ETH campaign pool, 90% goes to the prize pool, 5% goes to the organizer, and 5% goes to protocol maintenance. The protocol is not sustained by swallowing campaign value. It is sustained through scale, low friction, and transparent cooperation.
This is one of the biggest differences between OneTappy and many solutions that are “technically correct but product-hostile.”
In the traditional commit-reveal model, players usually need two actions: first commit, then reveal. OneTappy splits the flow across two roles, partner and player:
That makes the player experience feel much closer to “buying a ticket” than “participating in a cryptographic protocol.” At the protocol-design level, the complexity is moved entirely away from the user side.
Many Web3 infrastructure projects answer “how can this be done,” but fail to answer “who will keep using it.”
OneTappy is fairly explicit on this point. The partner is not just a supporting actor inside the protocol, but a core participant modeled seriously. They can independently configure ticket price, quantity, and duration, recruit participants, and automatically receive the revenue share written into the contract in advance after the campaign ends. This is a revenue-sharing campaign infrastructure for creators, communities, and DAOs, not just a randomness API.
More importantly, the cooperative relationship is not maintained by off-chain negotiation. It is maintained by visible on-chain rules. Revenue ratios, deposit logic, and fund destinations are all fixed when the campaign is created. Organizers do not need to explain verbally how revenue is split, and participants do not need to guess how the rules work.
This is the most important part of OneTappy.
At its core, OneTappy is not simply “a system that uses randomness.” It is a system that uses deposits and automatic penalties. When a partner creates a campaign, they must first submit a full deposit equal to ticket price x quantity, and that money is locked into the contract. If settlement happens honestly, the deposit is returned and the partner also receives their revenue share. But if the partner does not reveal, or reveals invalidly, the contract triggers a penalty and the deposit is slashed to compensate affected users.
What matters here is that “do not act maliciously” is no longer just a moral request. It becomes the more economically rational choice. If the potential gain from attacking is G and the deposit is D, then the system is designed to require D >= G, making the attacker’s expected return E = G - D <= 0. This does not assume people are naturally honest. It designs a structure in which honesty is more profitable than abuse.
That is also why I believe OneTappy is more complete than many solutions that only prove randomness can be generated. It is not merely trying to produce a random result. It is trying to construct a business structure in which abuse is harder and honest cooperation is easier.
Of course OneTappy serves end participants, because they are the ones who most need a result they can verify.
But they are not the only people I want to serve.
I also want to serve the partners who genuinely want to run campaigns, grow communities, spread ideas, and drive growth over the long term. I have become increasingly convinced that if a system cannot make partners willing to keep using it, then no matter how elegant it looks, it remains just a demo.
So OneTappy is not trying to be just a raffle group-buying page, and not just a one-off technical module. It is closer to a sustainable fair-campaign infrastructure. Its goal is not to support one campaign once. Its goal is to support many partners running campaigns repeatedly while preserving transparency, reducing friction, and maintaining trust throughout the process.
After the explosive years of blockchain growth, I think we are now in a phase that is actually better suited for serious product building. And to me, that makes this exactly the right time to build something truly usable.
The market is never short on new packaging. What it lacks is a new foundation of rules.
This industry already has too many projects selling “excitement,” “engagement,” and “luck,” while very few are seriously focused on whether users can independently verify the result.
I do not want to keep accepting the default assumption that as long as a product looks professional enough, smooth enough, and lively enough, users should simply trust it.
If people are still going to keep participating in raffle-based group buying, then at the very least they should be participating in a system they can verify.
If partners are still going to keep running campaigns, then at the very least they should be using a campaign system that is lower cost, simpler, and harder to abuse.
That is why I am starting now.
Not because this direction is the easiest, and not because this industry is the simplest, but because I believe it is worth rebuilding seriously.
I am not doing PR for this industry.
What I am saying is that if this raffle-style group buying model is destined to keep existing for a long time, then at the very least it should be more transparent, lower cost, and harder to abuse. It should not keep relying on black boxes. It should not keep relying on users’ blind trust. And it should not remain stuck at the stage of “the platform says it is fair, so you should believe it first.”
OneTappy is the answer I am trying to offer.
It may not be perfect from day one, and it may not solve everything in a single step, but it at least represents a clear direction: turning fairness from a slogan into a system capability that can be verified, cooperated around, and sustained over time.
If people continue to participate in this model in the future, I hope they are no longer participating in a platform they can only trust, but in a system they can verify for themselves.
If partners continue to build long-term campaigns in the future, I hope they are no longer relying on relationships maintained by verbal promises, but on an infrastructure where the rules, responsibilities, and revenue are all made explicit.
That is why I am building OneTappy.