DEV Community

Ujjawal Tyagi
Ujjawal Tyagi

Posted on

Smart Contracts in Production: What We Learned Building a Tokenized Loyalty Platform

Most blockchain projects we see in India are theatre. Tokens with no utility, NFTs that nobody actually owns, smart contracts copy-pasted from a tutorial. When a client at Xenotix Labs (https://www.xenotixlabs.com) asked us to build a tokenized loyalty platform for a real B2C brand, we had to make blockchain actually pay for itself. Here is what worked and what didn't.

The constraints

The brand wanted: customers earn loyalty tokens for purchases, can spend tokens on cashback or merchandise, can transfer tokens peer-to-peer, and (this was the hard one) can NEVER lose tokens because of a wallet failure or seed phrase loss. Most consumers in India don't understand wallets. They just want the points to work like points.

Custodial-first, with optional self-custody

We built it custodial-first. The platform owns the wallets, the customer signs in with email + OTP, and the tokens live on a private ERC-20 deployment on Polygon. Customers can later "graduate" their wallet to self-custody if they want to, but 99% don't bother—which is fine. We use OpenZeppelin's MinimalForwarder for gasless transactions so customers never see gas fees.

This got pushback from blockchain purists ("not your keys, not your coins"). We don't care. Mainstream adoption requires custodial UX. The blockchain is an implementation detail.

The contract architecture

Three contracts. (1) ERC-20 token contract with mint/burn limited to the platform multisig. (2) Loyalty engine contract that records earn and burn events with merchant ID and category, so we can do reporting on-chain. (3) P2P transfer contract with built-in compliance hooks (we throttle large transfers and require KYC above a threshold).

We deliberately did NOT make the contracts upgradeable on day one. Upgradeable proxies introduce admin keys that are basically a backdoor; security auditors hate them. Instead we wrote a migration-via-snapshot pattern: when we need to upgrade, we deploy new contracts, snapshot the old state, and bulk-mint into the new contract. Manual, but auditable.

Off-chain state matters more than on-chain

Here's the unglamorous truth: 90% of our backend code is off-chain. The on-chain work is the source of truth for token balances and transfers, but everything else (merchant catalogs, redemption rules, fraud detection, customer support) lives in PostgreSQL. The blockchain is the ledger. The database is the application.

We sync between the two using an indexer (we use Goldsky on top of Polygon RPC) and a reconciliation cron that flags any drift.

What we'd do differently

We'd skip Solidity for v1 and use a programmable database with cryptographic audit logs. The marginal value of public chain immutability for a closed-loop loyalty program is low. We learned this 4 months in. The next iteration of the product is moving to that direction.

Other apps we've shipped at Xenotix Labs

Veda Milk (D2C dairy subscription, Country Delight clone), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app with 7 user personas and live lawyer calls), ClaimsMitra (insurance survey platform with 114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). Stack: Flutter, Next.js, Node.js on AWS plus blockchain integrations when actually needed. 30+ products shipped.

Hiring us

If you are building a loyalty product, a tokenized rewards platform, or something that needs blockchain plumbing without blockchain theatre, we would love to talk. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Top comments (0)