Points have recently emerged as the catalyst of engagement in the crypto ecosystem, spearheading numerous successful initiatives by leading teams and protocols. Their concept is straightforward: engaging with the protocol in a manner that fosters its growth, results in the protocol rewarding users with points. This mechanism closely mirrors the XP system found in numerous video games, where accumulating points elevates a user's position on a leaderboard, incentivizing them to climb to the top.

Many protocols employ points as an initial step before introducing the protocol's governance token, indicating that the distribution of tokens will be based on the number of points a user accumulates. This strategy allows protocols and teams to gain valuable time before they need to unveil the specifics of their token, also delaying the inevitable scrutiny in case they mess up. Accumulating points functions similarly to yield farming but without the direct financial incentive, offering a more generalized approach to user engagement and reward.

It has now become the latest meta to incentivise users & grow the protocol. And the fun part is, points are theoretically infinite supply, adding a twist to the conventional airdrop mechanism and differentiating it with actual tokens.

Problems with Points

PMF should not stand for Points Market Fit. If a product isn't getting used without points, it's pointless to slap a point system on top of it and call it PMF. Points should not serve as the decisive factor for choosing product X over Y; rather, both products X and Y should offer inherent value to the user.

The next biggest problem is the fact that most point systems are black boxes, and specifically black boxes with unpredictable computation properties over time. This opacity has its advantages and disadvantages - it grants teams greater flexibility to adjust the system's rules, yet it simultaneously strips users of any sense of control or influence.

The rules of the game to accrue XP (read: points) should be clear and predictable!

What if points were auditable, transparent, and predictable — while still being flexible for teams to design campaigns around?

On-Chain Points

The idea of implementing points on-chain presents an intriguing concept, yet it should not merely serve as a facade for another ERC-20 token. There have been instances where protocols introduced a pre-release token, promising its eventual conversion into a different token (basically points in disguise) but littering the ecosystem with redundant tokens.

Envisioning on-chain points as distinct from ERC-20 tokens opens up the possibility for unique experiences through the composability of different point systems. However, the reality that both Layer-1 and Layer-2 solutions are cost-prohibitive for implementing an on-chain points tracking system raises a critical question: why not simply use an ERC-20 token to represent points?

This situation underscores why an on-chain points system is an ideal candidate for development as a micro-rollup on Stackr.

---

Looking at the problems with the current infra used to run point systems, the team pulled a night long internal research sprint and what has emerged is a specialised VM to track & manage points for your protocol.

Quick Primer on Micro-Rollups

Micro-rollups are essentially state machines that executes certain logic off-chain and then outsource the verification of the execution to another layer, which we call “Vulcan” that verifies the state updates and pushes the compute data on-chain.

• The state machine has a defined shape of the state and is initialized with a genesis condition.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan.

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF

2. Generates metadata for the verified block

3. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

Points System 🤝 Micro-Rollup

So, why are micro-rollups uniquely suited to build point systems?

1. Micro-rollups are fast, flexible, self-hosted execution environments

   This ensures that the delivery of points does not incur “on-chain” overhead and all the state updates happen as fast as possible.

2. Micro-rollups enable verifiable off-chain compute

   Despite being self hosted, the framework ensures that any data that enters the system and mutates the state can be fully verified before the data settles on L1. This ensures that the system is running predictably and not being tampered with.

3. Micro-rollups make the state auditable

   Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

4. Micro-rollups can directly settle on L1

   Since micro-rollups can settle directly on an L1, the state proofs can be consumed directly inside contracts to take on-chain actions. The verifier layer ensures that the settlement period is greatly reduced by providing pre-settlement guarantees.

Lets build the Points System

Disclaimer: This demonstration showcases the framework's capabilities and represents a highly unoptimized build not intended for production use. Please regard the content as illustrative and not as a finalized product.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK

The Design

• Events are triggered when a user performs an off-chain or on-chain action on a platform. Events can also be assigned to a user by the admin

• Points are stored off-chain inside a state machine

• The system holds a state transition function that determines when and how much points are granted to the user

• Events trigger the state transition functions and the state is updated with the user’s new points

• After every set epoch a block is generated which contains details of user events and updated points table state

• The block is sent to Vulcan network for verification

• If the block conforms the rules of the state machine it is approved

• The block data is split between L1 and DA for settlement

Defining the base state

1. As a starting point, we add admins and an eventRegistry

• admins : Addresses which can register an event entity and also assign points for users

• event : Any kind of entity that the user can receive points for. It could be an on-chain event or a custom manually added entity. eg : “sign-up” (custom) can give them 200 points, “swap” (on-chain) can give them 500 points and so on.

2. Next up, we need a way to track the events of the users which they are eligible for points.

So a user may have 1 sign-up and 5 swaps. Each event is an entry in the eventLog

We added an eventLog to the state to keep track of all the on-chain events that have been tracked for a user and the max points corresponding to them for each. We at the moment do not need the points subfield as it can be fetched from the eventRegistry, but we add it nonetheless to keep the system flexible for further development.

Adding a handler for state update

After we setup our minimum viable state, we need to define reducers that update the state.

3. Let’s add a logEventReducer which is responsible for creating a log entry for an event for a user

Breaking down the above

• Admin calls a logEvent action (out of scope for this article) with the name of the event and identifier of the user.

• The action hits the stateMachine and triggers logEventReducer

• The reducer then →

  • Finds the points corresponding to the event.

  • Updates the event log for the user with the event and the corresponding points.

For example —

• Admin calls logEvent({user: mg-labs.eth, event: "deposit"})

• The reducer would then find the deposit action in the eventRegistry and log the event for mg-labs.eth along with the points corresponding to the deposit event.

We’ve reached the point where the minimum viable system works.

Smart Contracts vs Micro-rollup

To calculate the total points of a user, we would need to iterate over the event logs for the user and this has to be repeated each time we want to fetch the total points of the user.

Now, that could be a viable approach if you were building a points system as a smart contract because storage is extremely expensive inside the EVM compared to a micro-rollup.

But since we’re building a micro-rollup, we can be more liberal with the state and compute to prioritise user experience over cost.

Storing the computed points

4. Adding userPoints to the state.

It’ll be tasked to keep the sum of the points allocated to a user.

We update the logEventReducer to also update the points for the user when an event is logged.

Done!

And it’s that simple to build an event-driven point system with on-chain traceability! Surprisingly easy to give on-chain superpowers to a backend server no?

Off-chain Points brought on-chain → Airdrops and more ✨

The beauty of this system is that it allows points to seamlessly be used on-chain without severe overhead.

As mentioned at the beginning, micro-rollup’s state root is settled on L1, It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, if we extract the userPoints and settle it’s merklized root on L1, we open up the possibility of direct inclusion proofs of users in the merkle tree.

This property would let us seamlessly build on-chain experiences for trust-less token redemptions, rewards against points, on-chain secondary market for points, etc. By getting user points data on-chain with inclusion proofs the possibility of on-chain experiences explode

This approach brings points on-chain without the points having to be strictly on-chain! (And for significantly cheaper with superior user experience)

Musings

The Point System we’ve built so far in this post is just the tip of the iceberg and can be significantly expanded to build a wealth of features. Some of them could be as follows:

Multipliers

Teams love to play with time-bound multipliers on the baseline points for certain events or campaigns as it’s a beautiful mechanism to collaborate with other projects, increase activity in the community and the protocol, etc.

With this version of the Points System, it’s trivial to iterate and implement multipliers as we were already storing the points that are to be allocated for the event at that specific time.

First, we update the EventRegistry to hold a list of multipliers for each event.

As you’ll notice above, it’s a list of multipliers per event which can be activated and deactivated by the team to achieve interesting campaign design.

To take the above state update into account, we update logEventReducer to apply active multipliers.

The above logic not only applies a multiplier but also stacks multiple multipliers for the event when calculating the amount of points to allocate.

Referrals

Similar to multipliers, referrals are key to several point systems. Referral systems are hard to build completely on-chain as they can get quite complex in their structure.

For example, MarginFi has a multi-level referral system —

Building points system as micro-rollup gives you the freedom to implement the above mechanisms, as complicated as they maybe, in your own sovereign execution environment.

Points Automation

The system discussed above allows for a lot of flexibility, but also requires additional infra as overhead on the admin (or bots) to update the user points.

One could increase the autonomy of the system by piping in all the user events from selected contracts to the micro-rollup through the L1Syncer (Inbuilt module inside the SDK) and the state transition function of the rollup being purely the algorithm to compute the points for the users with transparency on how the points are calculated.

Points as Reputation

Points can easily be thought of as XP or reputation points in a social economy.

They serve as a form of recognition for contributing value to a protocol or product. The potential for creating on-chain experiences using the Points System as a reputation tracker in a social economy is vast and filled with exciting possibilities for engagement and innovation.

For example, Reddit’s Karma Points built on a micro-rollup could instantly make the “useless internet points,” as they like to call it, useable on-chain.

Using this framework, it is probably a few days of work to port over the existing karma point system to bring it on-chain.

Conclusion

The Points System represents a compelling use case situated at the crossroads of Web2 and Web3, warranting a novel hybrid architecture. This is precisely the opportunity provided by micro-rollups.

Micro-rollups offer the flexibility to choose your position on the decentralization spectrum. They empower builders to construct applications according to their preferences, whether that entails full decentralization, sufficient decentralization, or a secret third thing yet to be unlocked.

---

Interested in building your own Points Infra?

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build a Points System for your protocol or building tooling for points, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz