Putting pasanaku.fun onchain and online has been an amazing journey, and it is a journey that is still ongoing.
The protocol has gone through many, many iterations. I’m grateful for all of them, because I learned a lot while trying to build the perfect onchain rotating savings mechanism.
In this article, I want to go over Pasanaku’s development journey so far: the decisions I made, how I built it, what I learned, and, most importantly, what comes next.
If you want to create something similar, whether you need smart contracts or the full stack, please feel free to connect with me on X (@rabuawad_).
But first, let me explain how Pasanaku works. It all started with a much simpler idea.
What Is a Pasanaku?
A pasanaku is a rotating savings pool. A group of people contributes a fixed amount on a schedule, and one participant receives the complete payout during each round.
Traditional pasanakus depend on trust. You know the other participants, and everyone trusts that the people who receive an early payout will continue contributing to the later rounds.
What I wanted to explore was simple: how much of this mechanism could be moved onchain? And, eventually, could a pasanaku work between people who did not know one another?
Core v1: Putting a Trusted Pasanaku Onchain
For the first version, I wanted to build a simple rotating savings mechanism for trusted participants. You had to know the other people in the group, just like in a traditional rotating savings pool.
Even with that trust assumption, Pasanaku let me explore some interesting uses of blockchain technology.
The most interesting one was using ERC-1155 to represent each pasanaku. Every pool had a unique token ID. I liked this because it opened the possibility of making pasanakus composable.
The first version was written in Vyper. It was a simple and efficient smart contract, and it consumed very little gas.
Creating pasanakus was also simple. You created the pool and manually added every participant’s wallet. At launch, only a few currencies were supported: ETH, USDC, and USDT.
Money distribution happened in two steps. Each participant deposited their contribution, and the participant assigned to that round claimed the payout.
The contract used personal custody. It received the contributions and distributed the money, but it did not try to remove the trust assumptions of a traditional rotating savings pool.
That was v1: a minimal and efficient way to put rotating savings onchain.
At the time, I still did not understand how to build a trustless version of Pasanaku. I was also interested in another idea: dynamic NFTs.
Core v1.5: Trusted Pasanaku With Dynamic NFTs
For this intermediate iteration, I ported everything to Solidity with one purpose in mind: adding dynamic, fully onchain metadata to the NFTs.
I wanted to understand what was happening inside each pasanaku simply by looking at its NFT image.
That took me down an interesting path. I developed a custom ERC-1155 onchain descriptor that read the pool’s state and generated the information needed to represent that pasanaku.
The system was still trusted. You still needed to know every participant. The difference was that each NFT now had dynamically generated metadata showing what was happening inside its pool.
I still think onchain metadata is extremely cool and useful. But I realized that, in this case, it did not add enough value to what the protocol already did.
There was a more fundamental problem.
The Problem With the Trusted Model
If you already know and trust every participant, do you really need a smart contract?
You could simply send USDC directly to one another’s wallets without using an intermediary. Putting the process onchain made it more transparent, but it did not solve the hardest problem.
The real question was whether Pasanaku could work between people who did not know or trust one another.
That was when I started thinking about a new version.
Core v2: The Overcollateralization Breakthrough
For v2, I went back to Vyper. I kept ERC-1155 because I still wanted to enable composability between pasanakus in the future, and maybe even a secondary market.
The model started to take shape when I realized that a completely trustless onchain rotating savings pool could work with one simple trick: overcollateralization.
The first iteration of v2 was only an overcollateralized pasanaku. It worked through a factory where users could create pasanakus using supported currencies.
The mechanism was simple:
- First, you supplied collateral.
- If you had enough collateral, you could join a pasanaku.
- Your collateral had to be worth more than the pool’s complete payout.
That was it.
The model worked, but there was nothing particularly special about it yet. It was an overcollateralized pasanaku, and users had little incentive to participate beyond the savings mechanism itself.
So I started working on an improvement.
Making the Collateral Productive
For this iteration, I dropped support for multiple assets and focused on one: USDC. I chose it because it is a widely used and widely available stablecoin.
Then I realized something. Users already had to supply collateral, and that collateral was sitting inside the protocol. It could be doing something.
So I decided to send that collateral to Fluid and make it productive.
That led to what I think is Pasanaku’s most innovative mechanism, and, as far as I know, the only rotating savings pool algorithm designed to work this way in a decentralized system.
The pool not only uses collateral to make participation between strangers possible. It also generates yield from that collateral, creating an additional game-theory incentive for people to participate.
You can read more about the current mechanism on the Pasanaku About page.
A Minimal Protocol
With this version, I think I created something special and useful.
I am planning several updates, but I do not plan to touch the smart contracts. What I wanted from the contract was something minimal and elegant, and I think that is what we have.
Pasanaku is a single smart contract that is also a soulbound ERC-1155. It does what it is supposed to do: create a decentralized, trustless rotating savings pool for people who do not know one another.
That was the idea, and I think the execution was excellent.
The protocol also generates yield from the collateral, giving participants an additional reason to join and remain in the system. I think that is one of the most interesting parts of the architecture.
If you have feedback about Pasanaku’s core architecture, please let me know. I will be more than happy to share my thoughts and hear yours.
Building a Frontend With Character
Something really important, and something that does not get enough attention, especially in the age of AI engineering, is that the landing page and the UI have to be pristine.
The old v1 interface is still online, and, well, I am not really proud of it.
It was built in only a few days with AI. It was not necessarily a flop, but it lacked something. For me, it lacked essence. It did not have anything I could call unique.
I mention this because an almost infinite number of AI-coded apps are reaching the market right now, and many of them feel the same. They look the same. They act the same.
They often have the same bugs and the same missing features. By many definitions of the term, they are AI slop.
The first version of the Pasanaku web app was probably somewhere in that territory. I built it for a hackathon, but I did not want the project to stay there.
I have around 10 years of frontend development experience, and I wanted to put that experience into practice.
For the v2 interface, I created a new design system. I also applied some of the most effective UI patterns available for Web3 applications.
The result is, I think, a genuinely good interface with a unique essence. It is not a shoddy template. It is useful, readable, responsive, and fast. It has achieved a 99% Lighthouse score.
The UI matters because it is how almost every user will experience the protocol. Almost no one is going to interact with Pasanaku directly through the smart contract.
The interface therefore has to make a fairly nuanced protocol feel understandable.
It has to display collateral, current interest rates, available pasanakus, and a user’s active pasanakus. It also has to coordinate all the steps required for each onchain interaction.
When someone creates a pool, the interface shows relevant active pasanakus so they can avoid paying a creation fee when a suitable pool already exists.
All of those pieces come together in an interface that I think is beautiful and, more importantly, useful.
I am grateful that I was able to deliver it in record time. I learned a lot, especially about reading onchain data quickly and reliably.
The frontend has features that you cannot create by simply prompting some code or copying a template. They required specialized knowledge of the protocol, Web3, and frontend development.
I was also able to compress that knowledge into a repository that I think is really clean. That is another part of the project I am proud of.
What Comes Next
Pasanaku is online, and its core protocol is working, but the journey is not finished.
The next updates will focus mainly on the product around the contract: making the experience clearer, improving how people discover and join pools, and continuing to refine the interface.
The smart contract is intentionally minimal. I do not want to add complexity simply for the sake of adding features. The goal is to keep the protocol elegant while making the product around it better.
There are also ideas I would still like to explore, including greater composability between Pasanaku and what a secondary market could eventually look like.
Closing
Building Pasanaku took me from a simple trusted savings pool to a protocol where strangers can save together through overcollateralization and productive collateral.
Every version taught me something. V1 taught me how to represent rotating savings onchain. V1.5 pushed me into dynamic NFTs. V2 forced me to solve the actual trust problem.
The frontend then forced me to make all of that complexity understandable and useful.
I think we now have something minimal, elegant, and genuinely interesting. There is still a lot to improve, and that is exactly what makes the journey exciting.
If you have feedback, want to discuss the architecture, or need help building something similar, from smart contracts to the full stack, please feel free to connect with me on X (@rabuawad_).
Top comments (0)