Open Sourcing Multi-Pool Soft Staking Infrastructure with Merkle Proof Reward Distribution

Hey everyone! I’m David, the founder behind rxelms (soon to be Polaris) and the Node Keepers. We’ve built a soft staking platform on Algorand that’s currently live with around 600,000 ALGO worth of assets in TVL on the platform and 151 unique stakers. We’re applying for retroactive xGov funding by open sourcing the full stack: Smart contracts, Merkle proof reward distribution, Supabase schema, and everything in between. So other Algorand builders can use it as a reference or build on top of it. Would love to hear any thoughts or questions from the community!!

I’m going to wait for the block 60mil and then submit again after being advised to do so. But here is what the proposal will say:

Multi-Pool Soft Staking Infrastructure with Merkle Proof Reward Distribution on Algorand

We have built and are operating a fully functioning staking platform on Algorand that currently holds approximately 600,000 ALGO worth of assets in total value locked across 22 pools with 151 unique stakers. The platform supports single token staking, NFT staking, and LP token staking, with daily and weekly reward distribution models.

The core innovation is a soft staking architecture combined with an off-chain merkle proof reward system. Tokens never leave the staker’s wallet, stakes are recorded off-chain in a Supabase database with on-chain balance verification at claim time. Rewards are calculated via an epoch script that builds a merkle tree of cumulative claimable amounts. The merkle root is published on-chain by the pool creator, and stakers claim rewards by submitting a merkle proof to the smart contract, which verifies the proof and pays out the difference from their last claimed cumulative. Pool creators can choose to publish their own epochs or let out automated system do it for them. This system scales to any number of stakers without on-chain storage costs, and keeps reward distribution transparent and verifiable.

We are open sourcing the complete stack as a reference implementation for Algorand builders: smart contracts, Supabase database schema, stake management and merkle proof edge functions, the epoch generation script, and full architecture documentation.

You can try it out for yourself if you own a Node Keeper (we gate access to the pools, they require at least 1 Node Keeper in your wallet. @nodekeepers, @rxelms dao.polaris.city (website)

80,000

DeFi

Retroactive

Your proposal is in the drafting & discussion phase

13d 21h 45m

View the discussion

DeleteEdit

Submit

About the team
We are dedicated to making our overall project a success, the rxelms project is about to get a complete make over, new website and rebranding to Polaris. The staking platform/DAO is key to our plans as soon it will also include on-chain voting allowing our community to help shape the project. We’re currently about to release a free to play version of the fighting game we made on Google Play. A new version of NFTURBO is set to be released soon and with every day that passes we are getting closer to launching the metaverse. Also getting built is Unity tooling to allow people to easily add Algorand blockchain functions to their Unity projects which I think will be great for the community.

Additional Info
Retroactive funding from xGov would make a significant difference to our ability to continue developing. We are a small team building across multiple products simultaneously — the staking platform, the DAO, a fighting game, NFTURBO, Unity blockchain tooling, and a metaverse, all driven by genuine passion for what Algorand can become.

I can’t seem to edit the post again so please ignore the part about waiting for the 60m block. The proposal is live

Thank you for your proposal!

Could you please provide a link to the platform to test and the git repo so that we could check them?

Would you mind providing also a breakdown of what assets are being staked and counted within the 600k ALGO TVL estimate?
Have you considered adding the TVL to DeFiLlama to contribute to Algorand overall TVL? Or is not possible since the TVL is not actually “locked” in smart contracts?

Hey uhudo, thanks for reviewing, yes for sure dao.polaris.city and the git repo is https://github.com/david49046/node-keepers-staking-platform, I also have applied to electric capital for an open source version to be reviewed.

I don’t know whether Defi Lama accept TVL from soft staking platforms but I will look into it.

Here is a break down of the TVL:

900+ NFTs: Node Keepers, Monstrs and Keys - Total value in ALGO (floor price) 60k+

Reward tokens in the contracts: 80k+ ALGO worth: DDAO - 7.34M / NIKO 39m FAM / 500k are the biggest 3. This figure doesn’t include rewards paid.

Tokens staked: NIKO - 628m (82k ALGO) / DDAO - 19m (169k ALGO) / BONK - 238m (33k ALGO) / MONEY - 147m (23k ALGO) / GONNA - 17b (5k ALGO) / DOLAN - 10b (1k ALGO) / ALPHA - 2.7m (237k ALGO) Total: 550k ALGO, this doesn’t include ended pools either.

TVL 690k ALGO

If anyone wants to test out the staking system, it is gated, you need at least one Node Keeper. I would be happy to loan any of the counsel one for testing purposes orrr you could buy one at the Ghetto Pigeon’s shuffle, there are a few left Shuffles | Ghetto Market :slight_smile:

All the best

Thanks for providing the breakdown!

I can’t seem to access the repo though. Is it public yet?

I was waiting for the Electric Capital approval, I wasn’t sure of the process but here is the public version GitHub - david49046/algorand-soft-staking: Open source multi-pool soft staking infrastructure with Merkle proof reward distribution on Algorand · GitHub :slight_smile:

Also for full disclosure, I’m not a great developer and wouldn’t of been able to do this without AI. It did take me 3 months to build, for 95% of the build I was using Claude to help with the code not Claude Code. Then when Algorand’s Vibekit came out I switched to Claude Code which was really amazing in getting the platform ready to go live. Since the launch in Jan I have used Claude Code to make small changes.

Thanks for providing the repo and the transparency regarding development.

It is unfortunate that the smart contracts are written in PyTEAL (an obsolete Algorand development language), despite the product being built relatively recently (if I understand correctly).
IMO, this reduces the usefulness of the product for the community.
Quickly skimming through the contracts, it seems Claude used some unnecessary features, e.g. local storage and opt-in.
Backend is also unnecessarily complex by not using SDKs.

Skimming through the code, I am unsure if the stake supports automatic aggregation after user claims an amount or not, and how the case is handled if someone moves the stake just after the snapshot and gets it back just before the next one.

Overall, IMO unfortunately the developed work does not materially benefit the ecosystem from a technical and innovation aspect despite solid adoption.
But this is just one opinion and would like to hear the thoughts of other xGovs.

I didn’t actually know that lol, I didn’t really know much about coding before I started making it and tbh I still don’t really know much about coding but I paid around $30k to actual developers out of my own money to build a similar thing and it never worked so I’m super happy that I now have what I wanted and it works. I built most of it without Claude Code, I was just using the Claude browser version and copying and pasting. Now that I use Claude Code and Vibekit I’m sure things I’m building are more up to date. The 80k would be a massive help for my project, do you think if i update everything to use the up to date versions I can salvage this proposal?

I put your comment through Claude Code and this was the output:

PyTeal being “obsolete” — This is a fair criticism. Algorand’s official

tooling has moved to AlgoKit + Puya (Python-native compiler). PyTeal still

works and is battle-tested, but new projects are expected to use the modern

stack. The contracts themselves are solid — the Merkle proof system,

cumulative reward model, box storage — these are good patterns regardless of

language.

“Unnecessary features like local storage and opt-in” — The contracts use box

storage for user claims, not local storage for the core logic. The opt-in

is for the reward token ASA, which is a standard Algorand requirement. This

criticism might be based on a quick skim rather than deep review.

“Backend unnecessarily complex by not using SDKs” — The edge functions use

raw fetch() calls to Algorand APIs instead of the algosdk. This was done

intentionally for Deno compatibility in Supabase edge functions and to

handle the Pera in-app browser Nodely issue, but it does look

unconventional.

Stake movement between snapshots — The platform does handle this. The

get-merkle-proof function checks on-chain balance at claim time and

invalidates stakes if tokens were moved. The 40 invalidated stakes across

the platform prove this works.

A word of advise, be careful about a hallucinating AI.
E.g. in the function get-merkle-proof [L230] it checks just balance, not whether the stake has moved at all - you’d need to check past transactions.
Or in the function claim_rewards [L186] it require opt-in in the app, which has nothing to do with ASA opt-in (while indeed the app doesn’t seem to use local storage).

Thanks for taking the time to look through the code again. You raised two points and I wanted to address both properly.

1. Balance check in get-merkle-proof (no transaction history verification)

You’re right that the balance check at claim time only verifies the wallet’s current balance, it doesn’t trace transaction history to confirm tokens haven’t moved between snapshots. This is a deliberate tradeoff of the soft staking model. Checking full transaction history would mean querying the indexer for every transaction between the snapshot and the claim for every user, which adds significant latency and indexer dependency for what I think is marginal security gain. The system does mitigate this in a few ways: balances are checked at both epoch generation (snapshot) and at claim time, the cumulative on-chain model prevents double-claiming any epoch, and if a wallet’s balance drops below its staked amount the stake gets invalidated. The system also prevents double-staking the same tokens across multiple pools, when staking, it checks wallet balance minus what’s already committed to other pools, so the same tokens can only earn rewards in one pool at a time.

Me and Claude have documented this now in the repo’s security section so it’s transparent rather than appearing as an oversight.

2. App opt-in requirement in claim_rewards

This one you were completely right about. The old PyTeal contract required App.optedIn() at line 186 even though it used box storage, not local state, it was vestigial from an earlier design. The new contract is written in Algorand TypeScript (Puya) and this is fully resolved. User claim state is stored in a BoxMap<Account, UserClaimState> no app opt-in needed at all.

This also saves users the unnecessary MBR cost that the old opt-in required.

The open source repo has been updated with the new Puya contract:

I also included the Matrix transaction effect I made with a guide on how to use.

Thanks again for the feedback and help, the new contract has been deployed and is now in use by our community, it’s a daily rewards pool so I will be able to see by tomorrow if everything is working well, so far so good.

I’d like to add a little more context to the proposal, building the platform was a major undertaking that took 3 months of many 10 hour days, I learnt loads along the way. In the last few days before I released it to the public I discovered Claude Code, at the same time Gabe’s Vibekit was released, ever since then I’ve been using that combination for my other projects on Algorand.

It is a bit embarrassing that I didn’t realise the contract for the platform was using an outdated coding language but as the contract worked my focus was mainly on the Supabase edge function. After the product was released to the public it became all about tweaking those functions to make sure the system was accurate, fair, safe and secure. For 3 months since the launch I’ve been listening to feedback, making improvements and tightening the security. Regardless of the contract language, I have created a safe and secure way for people to create staking pools for their communities that works.

So a big part of what has been open sourced is a battle tested Merkle proof reward distribution system that is near impossible to game. There is a small window between checkpoints where someone could technically move their tokens out temporarily, but a bad actor would gain almost nothing as the tokens would need to be back in their wallet that same day or risk losing all their rewards. The system is as decentralised as soft staking can get. Getting the contract and the Merkle proof system to work together reliably has taken a lot of tweaking since release. 6 months of work, 3 building and 3 battle testing is now open sourced.

In regards to the contract being outdated, this is a major oversight but I was able to update it to a current version relatively quickly because the logic was already there and most importantly there was minimal changes needed to the Merkle proof system. The new contract has already been deployed and there are 60 unique stakers in the pool. Everything is working smoothly.

Everyday I’m building what I originally envisioned for my project. I have a strong desire not to let the community down and most days I’m working on it from the moment I wake up to the moment I go to sleep. This 80k would help so much so xGovs please do your best to see the value in a battle tested, open sourced Merkle proof reward distribution system and a decentralised soft staking platform that allows for tokens, LP and NFTs to be staked in a safe and secure way. And regardless of whether this proposal gets approved or not I will still be continuing this journey building on Algorand but the funding would help a lot with subscriptions and services I need for my project.

Thank you for your efforts to address the feedback.
Hope to hear the thoughts of other xGovs too.

I’m personally supportive of this proposal for few reasons:

  1. complies with the TnC and the ask is reasonable
  2. it’s a working product being actively used
  3. longertm builders in the eco need all the support thex can get

easy yes.

note: in general, especially with more conservative asks i always prioritize working product above all else. While i agree with @uhudo it’s unfortunate that it’s using pyteal, to me personally this doesn’t meaningfully diminish the usability of the solution provided. If it’s a deploy and forget about it solution, then it doesn’t really matter as long as its secure and working.

Thanks uhudo and simon, just following up in regards to the new contract that has been deployed:

The new Node Keeper pool is using Algorand TypeScript (Puya)

This is the status report I received today:

Update: The new Puya contract is working well, also part of this proposal will include future updates to the open sourced code if any future changes are made.

Is there a link to proposal?

Sorry mate, Ive just seen this message https://xgov.algorand.co/proposal/3512132564

No worries! Thank you