Rewards started from a recurring problem I had seen several times while working on Web3 products.
Every project eventually needs to understand who its users are, what they do, how valuable they are, and how they should be rewarded. At first, this often looks simple. A team wants to create a points system, run a leaderboard, reward early users, or launch an airdrop. But once the product starts growing, the system becomes harder to maintain. Actions happen across different places. Some of them are onchain, some are offchain. Wallets need to be tracked, scored, filtered, ranked, rewarded, and sometimes excluded. What starts as a small growth mechanic quickly becomes internal infrastructure.
Rewards was designed around that tension.
I did not want to build another campaign tool that only helps a team distribute rewards once. I wanted to design a product that could sit deeper inside a project's ecosystem. Something that could connect to a product, receive activity, assign points, track wallets, expose analytics, and help teams make better reward decisions over time.
That changed the way I approached the brand, the landing page, the dashboard, the documentation, and the developer experience. Rewards had to feel simple from the outside, but it also had to be precise enough to support real product and technical workflows.
The main challenge was not to make Web3 loyalty look more polished. The challenge was to make a complex system feel usable.
From loyalty to infrastructure
The first version of Rewards was mostly framed around loyalty. That was a good starting point, but it did not fully describe what the product was becoming.
Loyalty is usually associated with points, rewards, and retention. Rewards does include all of that, but the deeper value is in the system behind it. A team can track what users do, assign points automatically through triggers, inspect wallet activity, understand the quality of a wallet, and launch campaigns based on more meaningful data.
That shift changed the positioning.
Rewards became less about "creating rewards" and more about turning activity into a decision layer. The product needed to help teams move from raw actions to points, from points to rankings, from rankings to segments, and from segments to actual rewards.
This is why I started thinking about Rewards as infrastructure that still had to feel like a product.
Infrastructure is powerful, but it can easily become abstract. A product is understandable, but it can easily become too limited. The design work was about keeping both qualities together: the depth of infrastructure, with the clarity of a well-designed SaaS.
Branding for trust
The brand was not only a visual exercise.
Rewards handles sensitive product decisions. It can influence who receives points, who appears in a leaderboard, who becomes eligible for a campaign, and who receives a reward. In Web3, those decisions can have real financial value. That means the brand cannot feel like a short-term growth hack. It has to feel reliable.
At the same time, Rewards lives in a space that is community-driven, fast-moving, and often experimental. The product could not feel like a cold enterprise dashboard either. It needed to feel native to Web3 without relying on the usual visual clichés of the space.
The direction became more structured, more focused, and more system-oriented. The goal was to make the product feel like a serious layer for teams building onchain communities, while keeping enough energy to support campaigns, rewards, and community engagement.
This also influenced the language.
Instead of describing Rewards with broad marketing terms, I wanted the product to be explained through stable primitives. Points, wallets, triggers, leaderboards, scores, activity, campaigns, API, and MCP are not just features. They are the mental model of the product. Once those concepts are clear, the entire system becomes easier to understand.
A good brand for this kind of product should reduce ambiguity. It should help users understand what the platform does before they even open the dashboard.
Landing page
I treated the landing page as the first layer of the product, not just as a marketing page.
Rewards is not immediately obvious if you try to explain everything at once. It includes loyalty programs, wallet tracking, automated points, analytics, reward campaigns, API integrations, scoring, documentation, and MCP access. If all of that is presented at the same level, the product feels heavy before it even starts.
The landing page had to reveal the system gradually.
The first job of the page is to explain the outcome: Rewards helps teams build and scale onchain loyalty programs. From there, the page can introduce the underlying system. Activity becomes points. Points shape leaderboards. Leaderboards and wallet data help teams understand their community. Campaigns turn that understanding into rewards.
This progression matters because different people arrive with different questions.
A founder wants to understand the value quickly. A growth person wants to know how campaigns and rewards work. A developer wants to know if the integration is simple and reliable. A community lead wants to understand how wallets, points, and leaderboards can help them manage users.
The landing page needed to support all of those entry points without becoming fragmented.
That is why the structure follows the logic of the product rather than the logic of a feature list. It starts with the promise, then introduces the primitives, then explains how teams can integrate Rewards into their own product.
The page is simple on the surface, but it is built around the actual architecture of the platform.
Dashboard
Inside the product, the dashboard becomes the main operating surface.
The most important design decision was to avoid treating wallets as anonymous rows in a table. In Web3, a wallet often acts as the user, but a wallet address alone does not tell enough of a story. A team needs to know what that wallet did, how many points it earned, how it ranks, whether it looks trustworthy, and whether it should be eligible for rewards.
The dashboard is designed to give context to those wallets.
Analytics help teams understand the global health of their program. Wallet views help them inspect individual participants. Activity makes the system traceable. Campaigns help transform data into actions. Together, those surfaces create a workspace where teams can manage engagement instead of manually connecting spreadsheets, blockchain explorers, and internal scripts.
The activity layer is especially important.
Whenever points are assigned, a trigger fires, a wallet changes status, or a campaign is prepared, the product needs to show what happened. This is not just useful for debugging. It is a trust mechanism. If a team cannot understand why a wallet received points, the entire reward system becomes harder to trust.
That is why activity is not treated as a secondary log. It is part of the core experience. It connects the technical side of Rewards with the operational side of the dashboard.
Automation
A big part of Rewards is automation.
A team can create triggers inside the dashboard and connect them to actions that happen in their own product. When a user completes a meaningful action, the product can send that event to Rewards through the API. Rewards receives it, checks the trigger, assigns the right amount of points, and updates the wallet.
This flow sounds simple, but the design problem is deeper.
For automation to feel safe, users need to understand the relationship between a product event and the points being assigned. A trigger cannot feel like a black box. It needs a clear name, a clear key, a clear amount of points, and a clear place where the result can be verified.
This is where the dashboard, API, and documentation have to work together.
The dashboard gives teams the interface to create and manage triggers. The API gives developers the way to send events. The activity feed gives everyone a way to verify that the system behaved correctly.
That connection is the product.
A trigger is not just a backend event. It is a bridge between a user action, a business rule, and a visible result inside the dashboard.
Developer experience
Rewards is only useful if teams can integrate it into their own products without heavy setup.
That made the documentation and API part of the product design work. The developer experience had to be clear enough for someone to understand the model quickly, but flexible enough to support different types of products.
The core idea is simple: a product sends activity to Rewards, and Rewards turns that activity into points and wallet history. Behind that simplicity, the documentation needs to explain authentication, point systems, trigger keys, wallet addresses, API keys, and error states.
Good documentation is not only about having code examples. It is about reducing uncertainty.
A developer should understand where the API key lives, why it should stay server-side, how a trigger is created, what happens when a wallet does not exist yet, and how to check that points were assigned correctly.
The goal was to make the technical layer feel predictable.
That is important because Rewards sits close to user value. If a reward system is hard to integrate or difficult to debug, teams will not trust it. The API does not just need to work. It needs to feel legible.
MCP
One of the most interesting parts of Rewards is the MCP integration.
The dashboard is useful when users want a visual workspace. The API is useful when developers want to connect their product to Rewards. MCP adds another interface: it makes Rewards data and actions accessible through tools and agents.
This changes the shape of the product.
Instead of forcing every interaction to happen through the dashboard, Rewards can expose its data to external assistants. A team could ask about wallet activity, inspect a leaderboard, retrieve information about a point system, or perform operational actions through an agentic workflow.
The important part is not that MCP is new or trendy. The important part is that it introduces a new way to interact with the same system.
For a product like Rewards, this matters because community data is not always consumed in the same way. Sometimes teams need dashboards. Sometimes they need API calls. Sometimes they need quick answers. Sometimes they need automation.
MCP extends Rewards beyond a single interface while keeping the same underlying model.
The design challenge is to make that access feel powerful without making it uncontrolled. When a system can read wallet data or modify points, permissions and auditability become part of the experience. Agentic access should not feel magical. It should feel accountable.
Wallet scoring
Rewards also includes a scoring layer through score.rewards.so.
The purpose of the score is to help teams and users understand the quality of a wallet. In Web3, not every wallet represents the same kind of participant. Some wallets are old and active. Some are fresh. Some show meaningful behavior. Others may look like bots, farmers, or low-quality addresses created only to exploit campaigns.
A points system alone does not solve that problem.
A wallet can earn points, but teams still need to understand whether that wallet should be trusted. That is where the score becomes useful. It gives each wallet a value from 0 to 100 based on signals such as wallet age, onchain activity, identity signals, multi-chain behavior, and suspicious patterns.
From a product perspective, the score is not just a badge. It is a decision layer.
For B2B use cases, a company can use the score through an API to evaluate wallets and improve how it qualifies users. For B2C use cases, a user can certify their score and mint it as a soulbound NFT, turning reputation into something portable and verifiable.
This creates an interesting loop between the two products.
Rewards helps teams understand and reward their community. Rewards Score helps wallets prove that they are more than disposable addresses. Together, they make reputation part of the engagement system.
Campaigns
Reward campaigns are where the system becomes tangible.
Today, the most natural reward primitive in Web3 is the airdrop. It is familiar, easy to understand, and directly connected to the culture of the space. But Rewards was not designed to stop at airdrops.
The broader idea is to build a campaign engine where different types of rewards can be distributed from the same underlying logic. Airdrops are one output. Raffles, gift cards, direct sends, NFT rewards, and other formats can become additional outputs over time.
That is why the campaign system should not be designed only around the reward itself.
The most important part of a campaign is the decision that happens before distribution. Who is eligible? Based on which points? From which activity? With what wallet quality? Under which constraints? Once that logic is clear, the reward type becomes more flexible.
This is the difference between an airdrop tool and a reward infrastructure.
An airdrop tool helps distribute tokens. Rewards helps teams understand who should receive something and why.
What to expose
The hardest part of designing Rewards was deciding how much complexity to expose.
If the product hides too much, it becomes a black box. Teams will not understand why points were assigned, why a wallet ranks a certain way, or why a campaign includes certain users. But if the product exposes everything at once, it becomes too technical and too intimidating.
The work was about choosing the right level of abstraction for each surface.
The landing page abstracts the system into a clear promise. The dashboard turns wallet and activity data into workflows. The API turns product events into programmable triggers. MCP opens the same system to agents. The score turns wallet behavior into a usable reputation signal. Campaigns turn all of that into rewards.
Each layer has a different job, but they all depend on the same principle: make the system understandable enough to be trusted.
This is especially important in Web3. When rewards have value, clarity is not a nice-to-have. It is part of the product's credibility.
Teams need to see what happened. Developers need to know how to integrate. Users need to understand why they are eligible. Wallets need context beyond an address. Campaigns need rules that can be explained.
Rewards is designed around that need for clarity.
What Rewards became
Rewards started as a way to make loyalty programs easier to build for Web3 teams.
It became a broader product system: a landing page that explains the value, a brand that makes the platform feel trustworthy, a dashboard that helps teams operate community data, an API that connects external products to Rewards, an MCP integration that opens new interaction models, a scoring layer that helps qualify wallets, and a campaign engine that turns engagement into rewards.
The product is still evolving, but the foundation is clear.
Rewards is not just a loyalty tool. It is not just a dashboard. It is not just an airdrop product.
It is a way for Web3 teams to understand their users, reward meaningful activity, and build engagement systems without rebuilding the same infrastructure again and again.
That was the design challenge from the beginning: making a technical infrastructure feel simple, trustworthy, and usable enough to become part of how teams grow their communities.