Open-Sourcing the GRAMO Loyalty Platform (xGov Proposal 3500632412)

Governance Discussions xGov Proposals
1

xGov proposal: https://xgov.algorand.co/proposal/3500632412

GRAMO (gramo.io) is a blockchain-based loyalty and rewards platform built on Algorand, live in production since 2022. Customers at partner retail stores earn GRAMO tokens (ASA 393498731) by uploading purchase receipts through our web app. Tokens are managed through custodial wallets with self-custody withdrawal, bridging Web2 users into the Algorand ecosystem without requiring them to understand crypto or interact with exchanges.

The platform currently has ~2,000 registered users, >2,000 on-chain token holders, >7,200 verifiable on-chain rewards-related txs from rewards-distribution project wallets (see links in comments).

What are we proposing?

We are requesting 150,000 ALGO to fully open-source the entire GRAMO application codebase (backend, frontend, and Algorand integration) under MIT license. Code and documentation will be made public at GitHub before any funds are distributed (now they are private repositories).

What the Codebase contains?

The GRAMO platform is a full-stack web application with three years of production hardening, built on Django REST Framework (backend) and React (frontend):

  • Django REST Framework API: RESTful backend handling user registration and JWT authentication (via djoser/simplejwt), claim submission and receipt validation, token accounting, ASA distribution via the Algorand Python SDK (algod), custodial wallet management, and partner store administration. MySQL database. Environment-based configuration via django-environ.

  • React SPA frontend: Single Page Application using React Router v6 with client-side routing, context-based state management (AuthContext, GlobalContext), authentication middleware, and Axios-driven API communication. Full user flows for claim submission, token balance management, withdrawal to self-custody wallets, deposit, merchandise redemption, checkout, and order tracking. Bundled and served through Django.

  • Algorand integration layer: Direct connection to Algorand node via the Python SDK for ASA transfers, wallet generation, balance tracking, and on-chain interaction — designed as a separable, reusable component that other projects can extract and adapt.

  • Database schema and migrations: Complete MySQL data model for loyalty program operations including user accounts, claims, token balances, partner stores, orders, and wallet mappings.

  • Deployment documentation: Environment configuration, setup guides, dependency management, and infrastructure requirements for self-hosting.

All user data, API keys, and partner agreements will be stripped. The release will be a clean, deployable codebase.

Why this might be important for Algorand builders?

Tokenized loyalty and rewards is one of the most talked-about real-world blockchain use cases. However, there is no open-source, Algorand-native reference implementation for it. Every developer building an ASA-based rewards system starts from scratch, solving the same problems we solved years ago:

  • How do you bridge physical retail purchases to on-chain token distribution?
  • How do you manage custodial wallets for users who don’t know what Algorand is or don’t want to interact with crypto exchanges?
  • How do you handle receipt validation, claim workflows, and token accounting at scale?
  • How do you build the Algorand SDK integration in Django/Python for a production app?

GRAMO answers all of these with working, battle-tested code. Open-sourcing it means the next team building loyalty-on-Algorand doesn’t start from zero, they would fork, adapt, and ship.

It also gives the Python/Django developer community a rare production-grade Algorand reference. The ecosystem is heavily JS/TS-focused. This might broaden the on-ramp to Algorand. Opensourcing the code could also help to position Algorand for AI searches on blockchain applications in the context of Django/React projects or Loyalty Rewards.

Why now?

The Algorand Foundation’s roadmap emphasizes mainstream adoption and real-world use cases. Loyalty programs are exactly this: they connect physical businesses to on-chain activity and bring non-speculative users to Algorand. The platform is mature, stable, and ready for community use. The sooner it’s open, the sooner others can build on it.

Some metrics

Metric Value
Registered app users ~2,000
On-chain token holders 2,007
Total rewards-related on-chain txs >7,200 txs
Operational since 2022
Active partner stores 3 (Spain-based CBD/cannabis retail)
Open Program Available to any retail store globally

About the Team

The team is multidisciplinary and is composed by six members building on Algorand since 2021. The accumulated professional experience of the team includes more than 20 years experience in the fields of IT engineering, IT security, IT Networking, Biomedical Scientific Research, Marketing and Online Positioning, Risk Analysis of Financial Markets, and Real State Market.

Please check some links to team info in the comments below.

Open-Source Commitment

  • License: MIT
  • Repository at GitHub
  • Timeline: Code published within 30 days of approval, before fund distribution
  • Post-release: 6 months of issue triage and community support

We are happy to answer all your questions questions and open to feedback.

5

This needs moderation from AF, to display the forum post as it was automatically hidden/flagged for some reason.

6

Yes, the summary of the proposal is hidden and we were limited to only two links in the post, probably to avoid spam. The post was labeled as spam anyway, maybe because we tried to add another two links in the comments. I think this restriction with the number of links is detrimental specifically for xGov proposals, as more links helps to provide additional information allowing xGovs to do their better, own research. Anyway, hope is someone from AF fix this soon and you all guys can read and discuss our proposal. Cheers

8

Thank you for your proposal!
Loyalty programs have been a promised use-case of blockchains for a while now but unfortunately haven’t been massively adopted yet.

It would be interesting to know more about your product stats. E.g. could you share how many retail stores use your solution and how has the number been developing throughout the 4 years of operation? Or where are the stores based?
What are the main benefits for them to use your solution rather than traditional loyalty programs or other Web3 solutions?

I’d be also curious to hear what you’d need to reach more users and what’s your business model?

As the team seems to be anonymous and the ask medium-size, I’d much prefer the project were
open-sourced in advance.
The option to open-source after approval was meant for large asks and projects that are exceptionally vital for the ecosystem.

9

Hi, thank you for the questions!

First, almost all of these are answered in the 10-minute video of the Gramo team presenting the platform at Algorand Decipher 2024 in Barcelona.

Let us answer your questions directly one by one, with honesty and good info.

1) Main benefits of GRAMO compared to traditional loyalty programs

  • Trading: Customers can trade their loyalty rewards for other cryptocurrencies or sell them, something impossible with traditional points cards. Rewards have real, market-determined value, and instant gratification.
  • Transparency: Every token distribution is verifiable on the blockchain. No hidden expiration, no unilateral devaluation of points, no opaque terms changes. As documented in our whitepaper (written before LLMs, page 5 ), traditional reward points are subject to expiration, changing values, and abandonment, billions of dollars sit in corporate liabilities as unused loyalty points worldwide.
  • Portability and interoperability: GRAMO tokens work across all partner stores. And the loyalty platform can run in parallel to traditional points card in one retailer, if needed.
  • No physical cards: Your phone is your wallet. No plastic, no forgetting your card at home.

2) Why blockchain-based loyalty rewards haven’t been adopted massively?

Because there are several frictions that are extremely difficult to solve in the real world. We tried to remove them with Gramo, and we were successful in some:

  1. The wallet problem. Requiring a crypto wallet to custody blockchain-based loyalty points is a non-starter for retail customers. We learned this the hard way. Our first approach was to onboard users via Pera Wallet, and it was catastrophic. Think about it from the perspective of a customer standing at the counter in a CBD shop: download Pera, download Binance, send euros, buy ALGO, fund your Pera, opt-in to the GRAMO token. And only then can you start receiving rewards. Nobody did it. Zero conversions in the first trial period with our first retail partner.

  2. The custodial wallet solution. We solved this by building a Gramo custodial wallet, automatically generated upon email registration. Each wallet is pre-funded with ALGO and pre-opted-in to the GRAMO token. After confirmed registration, the user is ready to receive rewards with zero blockchain knowledge. In 2022, this was an innovative solution, today it looks obvious, but at the time we were one of the first on Algorand to implement this Web2-to-Web3 bridge for retail users. This is precisely the kind of reusable pattern we want to open-source: any developer building a loyalty platform on Algorand can take our custodial wallet module and skip the time of engineering we spent on it.

  3. The receipt validation challenge. Connecting a physical purchase to an on-chain token distribution requires a trust layer: someone needs to verify the receipt is real, the amount is correct, and it hasn’t been claimed before. Our whitepaper (page 10) describes the hybrid validation system: automatic duplicate detection combined with manual verification of receipt data. We also built an OCR module for automated receipt validation, which is ready, tested, and can be included in the codebase if requested. However, AI changed the game here: with modern generative AI, anyone can produce convincing fake receipts, which means OCR-based automated validation is no longer reliable as a standalone verification method. We reverted to manual verification for production use (less than 20 sec per receipt)

3) Retail stores and progression

We have 3 partnered retail stores, all based in Madrid (Spain), all in the CBD/cannabis industry. Our strategy, documented in the whitepaper (pages 5-8) was deliberate: start with one industry vertical, learn the real-world frictions, then generalize. After extensive market research, we chose CBD/cannabis because of the explosive growth of the European CBD market (valued at $2.8B in 2020 with 21.2% CAGR projected through 2028) and the crypto-savvy demographics of its customer base (young, digitally literate, 18-45 age bracket).

Unfortunately, our experience showed that combining the cannabis industry with crypto was not the best business decision, for a reason we could not have predicted: the JuicyFields scandal. JuicyFields was a massive Ponzi scheme centered around cannabis crypto-investments that collapsed in July 2022, exactly when we were deploying Gramo.io. Many cannabis retailers across Europe, and specifically in Spain, were caught up in it, either as investors or as associated businesses. Cannabis shop owners who had been burned by JuicyFields wanted nothing to do with anything that combined cannabis and crypto. They saw our token-based loyalty program and their immediate reaction was suspicion.

Thus, cannabis shop owners were in general not very happy of being involved with crypto as they would face a double stigma: the existing social stigma around cannabis (even legal CBD), compounded by the crypto-scam stigma that JuicyFields created specifically at the intersection of cannabis and crypto. Expanding to new retail partners became extremely difficult. The platform has been continuously sending rewards to customers during these 3-4 years, with a stable base of 20-50 clients using it regularly, but we were never able to scale the partner network beyond these three stores in Madrid (Spain).

4) How to reach more users and why open-sourcing now

Arriving at this point, we concluded that the best path forward is to open-source the platform and let any developer create a similar system for any retail vertical worldwide. We discussed extensively within the team about next steps, but we were never able to dedicate 100% to the project, all team members have day jobs outside both the cannabis and crypto industries.

Our original vision for the next phase was to build a platform that would allow any retailer to create and deploy their own blockchain-based loyalty system. Essentially a white-label loyalty-on-Algorand builder. We had this quite advanced. But then AI changed the game again: we realized that the real opportunity is not traditional loyalty programs for physical retail, but loyalty programs for agentic commerce, where AI agents make purchasing decisions on behalf of users and loyalty/rewards become part of the agent’s decision-making layer. We’re actively exploring this direction now.

Given all this, open-sourcing GRAMO is the right move now at the right time. The retail loyalty codebase is production-ready and immediately useful: any developer can fork it and deploy for their own vertical. Meanwhile, we can focus on the agentic commerce frontier. And eventually, the white-label loyalty platform builder (letting anyone create their own Algorand-based loyalty program without writing code) can be completed and released as well.

5) Business model

The original business model was B2B: partnered shops would buy GRAMO tokens at a discount from the team and pay an annual subscription for platform management, including token provision, receipt validation, technical support, and access to the rewards infrastructure. The token economy described in our whitepaper (see graphical abstract in page 12 and section 4) was designed to create sustainable buying pressure from shops, which would offset the token distribution to customers. Open-sourcing decouples the platform from the GRAMO token. Anyone can fork and deploy with their own ASA and their own business model.

6) Team “anonymity”

The anonymity of the team is only public-facing. In private, everybody knows us. The reason for pseudonyms is simple and practical: all team members have day jobs in fields unrelated to both cannabis and crypto. Public association with a cannabis-adjacent crypto project (even a legitimate one in a legal market) could create real professional problems in our respective workplaces. This is a known issue in the cannabis industry broadly (our whitepaper Section 7 addresses it directly).

That said, the team is fully transparent where it matters:

  • The GRAMO team presented the platform live at Algorand Decipher 2024 in Barcelona.
  • The team has been interviewed in person multiple times by the Algorand Foundation, including discussions about the project’s direction and ecosystem contribution. Specifically we had in person meetings with Fred Estante, John Woods and Marc Vanlerberghe among others.
  • We have established working relationships with many other builders and key people in the Algorand ecosystem over four years of continuous presence (comments appreciated :slight_smile:
  • All project wallets and team member addresses are publicly documented and verifiable on-chain.
  • The Gramo team completed full KYC verification with the Algorand Foundation several times and in the xGov program, as required.

7) On open-sourcing in advance

We understand the preference and we’re open to discussing this. We’re willing to explore a middle ground, such as granting to any member of the xGov Council temporary access to the private repository before the vote, with the full release upon approval.

8) Why the ask reflects retroactive value

All the innovations described above, the custodial wallet system, the Web2-to-Web3 onboarding bridge, the receipt validation pipeline, the OCR module, the full Django REST Framework + React architecture with Algorand SDK integration, the JWT-based auth system, the partner management layer, were built starting in 2021-2022, when these patterns were not common on Algorand. The platform has been running in production for over four years. This retroactive grant reflects the value of proven, battle-tested infrastructure being contributed to the ecosystem, it’s not speculative future development.

Happy to answer any follow-up questions.

10

Three additional things:

  1. The link to project wallets was wrong, sorry. Is this one project wallets

  2. We added you Uhudu (uhudo · GitHub) to the private repository for your revision. It needs a big effort in completing documentation, which will be done if proposal passes.

  3. Gramo app is unfortunately down at this very moment, sorry for that. The team member in charge (Fer) suffered a surgery last week and will work on bringing the app online asap

11

Thank you for providing additional context and details about the metrics.

While I appreciate your trust in the xGov Council with the openness to provide us access to the repo, IMO the xGovs should not have to trust the Council to make an opinion about a proposal. This is why I still believe open-sourcing in advance is the right path for the vast majority of cases.
Also note that the Council members are voluntarily participating in the role and reviewing code is out of the scope of our duties.

Hope to hear the thoughts of other xGovs too.

12

An OG team building through cycles and pivoting and adopting to the industry as it changes is exactly the kind of builders we need in the eco.

Since this is OSS after aproval request i cannot comment on the code quality, but the tech stack is apprently good enough to serve real, paying customers over the years, so it’s a working product in my book. Naturally i’ll be looking at the code once opensourced, but as far as my personal support this is a clear yes.

Let me also say, that CBD/cannabis x crypto field, while it wasn’t yet majorly adopted, doesn’t mean it won’t be, same can be said for algorand and its recognition… So having an active loyalty project with opensourced repo available is great headstart for ensuring Algorand captures that market if it decided to move to crypto rails.

13

Regarding this proposal and in absence of publicly available code, I think xgovs need much more stronger numbers and traction reports so that this proposal could have a well desrved opportunity.
Generally, I would have been supporting a loyalty program with well defined architecture and sound codebase but for now May I humbly suggest you provide more details on impact and traction metrics? Especially on traffic and direct usage

14

Hi Emg110, fair request. We ran a full on-chain analysis of our three distribution wallets. All data is independently verifiable (GRAMO is ASA 393498731 with 2 decimals).

We fetched all outgoing GRAMO transfers from the three distribution wallets (PLF…, 3XB…, GVB…), then excluded: days with >25 txs (promo campaigns*), all known team wallets (10), whale investor wallets (30), dolphin investor wallets (13), project wallets (5), and 3 large reserve/liquidity distribution wallets. Script is available upon request.

[ *promo campaigns: we performed around 30 promo campaigns where we distributed custom cash receipts to users to use Gramo platform and claim rewards using cash receipt tickets (full loyalty pipeline). These campaigns are excluded from the metrics below, but gramo fans used the system and we used these campaigns to test and harden the code and promote Gramo. ]

Clean on-chain metrics

Category Txns GRAMO Notes
Retail reward txns (validated receipts) ~954 ~32,485 1 tx = 1 validated purchase receipt
Unique customer wallets 159 — Distinct recipient addresses
Airdrops (promo campaigns, >25 txs/day) 4,423 ~46,585 32 airdrop days across 2022–2024
Active retail months 35 — Jan 2022 to Dec 2025

The reward amounts directly reflect our evolving program structure. In 2023, individual rewards were 1-5 GRAMO per receipt (matching the original whitepaper tranches: 1 GRAMO for purchases <€40, 2 for €40-80, 5 for >€80). From mid-2024 onward, rewards shifted to 100-200 GRAMO per receipt (matching the updated legal terms: 100 for <€40, 200 for ≥€40). Both patterns are clearly visible in the on-chain data. Repeat customers are also visible, several wallets show 15-33 txs over months, consistent with regular buyers at the Madrid partner stores.

Application-level: ~2,000 registered accounts, 20-50 regularly active users across 3 partner stores. We’ve been transparent about the modest scale throughout this thread.

The value of this proposal is not massive user numbers, we have been clear about that. The value is the production-hardened infrastructure (custodial wallet system, receipt validation pipeline, Django REST + React architecture with Algorand SDK integration) being permanently released under MIT license for any developer to fork. The on-chain data above confirms this is a real, continuously operating system with genuine retail usage, not a prototype.

Hope this answers your question, Emg110. Happy to answer any additional question.

15

Thank you very much for prompt response. Next and final question based on your response to previous one:

  • How do you measure the re-usability of your software code and functionalities (separately please) for other users/devs and which charactiristics of your loyalty system architecture and design provides that (e.g which functionalities are adjustable parametrically or which different loyalty models it can support and finally will it be applicable to other businesses different than yours or it is designed to fit your business requirements)
16

Hi emg110, great question. This is really the core of the proposal’s value proposition, so let us be specific.

Code reusability, separable modules:

The codebase is a Django project with distinct apps that can be extracted or adapted independently:

  • Algorand integration layer (api/ app): wallet generation, ASA transfers via algod, balance tracking, opt-in management. This is the most directly reusable module. Any Django project needing to interact with the Algorand blockchain can lift this layer as-is. It’s a generic Algorand-Django bridge.

  • Custodial wallet system: automatic wallet creation on user registration, pre-funding with ALGO, pre-opt-in to the target ASA. This pattern is reusable for any application that needs to onboard Web2 users to Algorand without requiring them to manage their own wallet. Think event ticketing, gaming rewards, employee recognition, charitable donations… any context where the end user shouldn’t need to know what Algorand/blockchain/crypto is.

  • Claim/validation pipeline: receipt upload, claim arrival to validator, manual verification. The receipt validation is specific to retail, but the pipeline architecture (submit proof → validate → distribute tokens) generalizes to any proof-of-action reward system.

  • React frontend: auth flows, wallet management UI, claim submission, and redemption. Structurally reusable as a starting point for any token-based user-facing app on Algorand.

Parametric adjustability:

Several key parameters are already configurable without code changes (via Django settings and database): the target ASA ID, partner store configuration and distribution wallet addresses. A developer forking for a different vertical (say, a coffee shop chain or a gym) would primarily need to change these parameters, the logo of the app, and adapt the receipt validation logic to their domain. The app is live at app.gramo.io, it’s easy to see how the whole platform can be adapted to any other retail business.

Applicability beyond our business:

The platform is designed around a generic loyalty loop: user performs action → submits proof → retail or Gramo team validates → tokens distributed. The “action” in our case is a CBD purchase, but this loop applies to any retail vertical, any service business, or any context where you want to reward verifiable behavior with on-chain tokens. The Django/React stack, the Algorand integration, the custodial wallets, the JWT auth are not CBD-specific. The only CBD-specific element is the partner store branding and the receipt validation rules, which are the easiest parts to swap out.

Under MIT license, any developer can fork, strip the GRAMO branding, plug in their own ASA, adjust the mailbox for reception of claims, and deploy for their own use case.

17

Update for all xGovs:

After listening to the feedback in this thread, we’ve decided to open-source the repository in advance. We’re currently cleaning the codebase of sensitive data (API keys, DB passwords, wallet signature keys etc) and will make it public during the discussion period.

A note on documentation: the repo documentation is minimal at this stage. Improving it will be a priority if the proposal moves to voting. But the code itself will be available for anyone to inspect in the following hours/days.

18

Thank you for response, and the open-sourcing is a great move. I already am very positive on this.

19

Same issue that happened to me. I feel that if this were addressed we would have more participation as im sure people have given up in the process. i nearly did…

20

You say that the token is the main engine of the project since 2022 yet it has a TVL of $1000?

i also noticed in your plans and responses that the original plans and visions have shifted and changed a lot over time. A lot of, “the original plan was this, but then this happened, so we did this instead.”

That much inconsistency and lack of value for a token you say plays a vital part in the project is a bit concerning. You also said there are 2,000 registered app users but your token activity isnt showing that as “Active” users.

Are you able to supply metrics of current activity and active users of your service for the past 90 days? Thank you.