DEV Community: Nikhil Siripurapu

Inside SCAI Lucky Loop: Building a Provably Fair Daily Lottery as a Telegram Mini App

Nikhil Siripurapu — Fri, 10 Jul 2026 11:03:04 +0000

Technical breakdown of the architecture, authentication flow, and verifiable randomness behind **SCAI Lucky Loop—a coin-based daily lottery built during my Web3 internship at **EtherAuthority.

Over the past few months, I've been building SCAI Lucky Loop: a daily, coin-based lottery delivered as a Telegram Mini App (with a browser fallback), where players earn in-app coins, purchase ticket slots, and withdraw eligible winnings as LLT, an ERC-20 token deployed on SCAI Mainnet.

Rather than focusing on the user experience, this article explains the engineering decisions behind the application: authentication, backend architecture, commit–reveal randomness, and the trust model that makes the system verifiable.

🎥 Project Demo

Watch SCAI Lucky Loop in action:

https://vimeo.com/1215772223

Technology Stack & Deployment

The project is split into three independently deployable components.

Component	Responsibility	Deployment
Frontend	React + Vite client, Telegram integration, wallet connection	Vercel
Backend	Express API, SQLite database, cron jobs, withdrawals	Render
Smart Contracts	LLT ERC-20 contract, Hardhat tests	SCAI Mainnet

The frontend is built using React 18, TypeScript, and Vite, while the backend runs on Express.js with SQLite acting as the system of record for users, tickets, draws, referrals, and withdrawals.

Wallet connectivity is handled using Reown AppKit with the Ethers adapter, configured exclusively for SCAI Mainnet (Chain ID 34).

One important architectural decision is that ticket purchases are currently off-chain. Players spend in-app coins rather than sending blockchain transactions. Wallets are connected only when withdrawing LLT rewards. This separation significantly reduces gas costs and simplifies the user experience while still enabling blockchain payouts.

Authentication

The application supports two independent authentication mechanisms.

Telegram Mini App Authentication

The primary authentication flow is native to Telegram.

Telegram launches the Mini App.
The client receives window.Telegram.WebApp.initData.
The frontend sends the signed payload to the backend.
The backend verifies Telegram's signature using the bot token.
If valid, the backend creates (or loads) the user and returns a JWT.
Future requests authenticate using the JWT.

The important security boundary is the server-side verification of Telegram's signed payload. Simply copying the JSON payload is insufficient because the signature cannot be forged without Telegram's secret.

This prevents ordinary browser sessions from impersonating Telegram users.

Wallet-Only Authentication

To support users outside Telegram, I also implemented wallet-based login.

Instead of relying on Telegram identity:

The backend generates a unique nonce.
The wallet signs that nonce.
The backend verifies the signature using ethers.verifyMessage().
A JWT session is issued.

Supporting this required modifying the database schema so telegram_id became nullable while ensuring every account contains at least one valid identity through database constraints.

Additionally, every authenticated request reloads the user directly from SQLite instead of trusting cached JWT information. This ensures administrative changes, bans, or balance updates take effect immediately.

Verifiable Randomness with Commit–Reveal

Lottery systems often ask users to trust that draws are random.

Lucky Loop instead uses a commit–reveal mechanism that allows anyone to independently verify every draw.

Before ticket sales close:

The backend generates a cryptographically secure 32-byte random seed.
The SHA-256 hash of that seed is published immediately.
The seed itself remains secret.

Once ticket sales end:

The original seed is revealed.
SHA-256 is computed again.
The first four bytes become an unsigned integer.
That integer is reduced using modulo arithmetic against the number of tickets.

Because the hash was published beforehand, the backend cannot secretly generate multiple seeds after ticket sales close until it finds a favorable winner.

Either:

the revealed seed matches the published hash,

it doesn't.

There is no middle ground.

Public Verification

Lucky Loop exposes a public verification endpoint.

Given a draw date, anyone can independently verify:

the published commitment hash,
the revealed seed,
the computed winning ticket,
and the recorded winner.

No trust in the backend is required—the mathematics speaks for itself.

Handling Zero-Ticket Draws

One interesting production issue appeared during testing.

Originally, a draw record only existed if someone purchased a ticket.

On days with zero ticket sales:

no draw record existed,
the scheduled draw job executed,
the cron process failed because there was nothing to draw.

The fix was straightforward.

When ticket sales close, the scheduler now creates an empty draw if one does not already exist.

This allows every scheduled draw to execute successfully—even if nobody played that day.

Admin System

Administrative privileges are determined through three independent mechanisms.

An account becomes an administrator if any of the following is true:

Telegram ID exists inside ADMIN_TELEGRAM_IDS
Wallet address exists inside ADMIN_WALLET_ADDRESSES
Database column is_admin is true

Environment variables provide the initial bootstrap administrator.

After that, existing administrators can promote or demote users directly from the admin panel without redeploying the backend.

This avoids the common problem of requiring infrastructure changes whenever administrator access changes.

LLT Withdrawals

Blockchain interaction occurs only during withdrawals.

The process is:

Connect wallet.
Switch to SCAI Mainnet.
Submit withdrawal.
Backend validates:

minimum coin balance,
referral requirements,
withdrawal eligibility.
1. Backend signs an LLT transaction using the server payout wallet.
2. Transaction hash and explorer link are returned.

The payout wallet is the application's most sensitive secret.

It is stored securely using Render environment secrets and is never exposed to the frontend.

A critical distinction when building Vite applications is remembering that every environment variable beginning with VITE_ becomes public inside the browser bundle.

Private keys should never appear there.

Future Improvements

The next major milestone is replacing off-chain ticket purchases with native SCAI payments.

Doing so would move the entire lottery lifecycle onto the blockchain rather than only withdrawals.

Other planned improvements include:

migrating from SQLite to PostgreSQL,
replacing local rate limiting with Redis,
supporting horizontal backend scaling,
expanding transparency around draw verification.

Conclusion

Building SCAI Lucky Loop taught me considerably more than writing React components or Solidity contracts.

It required thinking carefully about authentication boundaries, backend trust, scheduled systems, wallet integration, cryptographic randomness, and operational edge cases that only appear after deployment.

The commit–reveal pattern ended up being one of the most valuable engineering techniques I implemented. It's relatively simple to build, easy for users to verify independently, and significantly increases trust in any application that depends on server-generated randomness.

If you're building a Telegram Mini App, a Web3 application, or any system where fairness matters, I highly recommend considering commit–reveal as part of your design.

Demo

🎥 https://vimeo.com/1215772223

SCAI Lucky Loop's smart contract has been audited by EtherAuthority. This project was built during my Web3 internship at EtherAuthority.

#React #TypeScript #ExpressJS #Solidity #Ethereum #Web3 #Blockchain #TelegramMiniApps #SmartContracts #Cryptography #OpenSource #SCAI #EtherAuthority

🔒 Building a Full-Stack DeFi Staking Platform on SecureChain AI — A Week 4 Web3 Internship Training Journey

Nikhil Siripurapu — Sat, 13 Jun 2026 16:59:52 +0000

Introduction

Staking is one of the most widely used mechanisms in DeFi — deposit tokens, earn yield over time, withdraw whenever you want. It sounds simple, but building one correctly means getting the token approval flow, the reward math, and the live dashboard data all working together without confusing the user at any step.

For Week 4 of my Web3 internship at Ether Authority, I built a complete, production-ready DeFi Staking Platform from scratch — smart contracts, frontend, and a live deployment on the SecureChain AI (SCAI) Mainnet.

🌐 Live Demo: https://de-fi-staking-platform-vert.vercel.app

💻 GitHub: https://github.com/feudcommon/DeFi-staking-platform

Architecture Overview

Smart Contracts

1. ERC20Token (STK)
An ERC-20 token with a built-in faucet. Features:

Public faucet (faucet()) — any wallet claims 100 STK, enforced with a 24-hour cooldown per address
Owner-only minting — used by the staking contract to mint reward tokens directly to users on claim
Packed faucet storage — faucetAmount and faucetCooldown are both uint128, packed into a single storage slot to save gas on every faucet read

2. StakingContract
The core of the platform:

Stake any amount of STK with no minimum
Token-weighted, time-based rewards — yield accrues continuously based on stake size and a basis-points APR
No lock-up period — withdraw staked tokens at any time
Reward snapshot pattern — every stake, withdraw, or claim first snapshots pending rewards via an updateReward modifier, so yield is always calculated up to the exact second
Faucet passthrough (claimFaucet()) — lets users claim free STK directly from the staking interface without touching the token contract separately

Frontend Features

Built with React + TypeScript + Ethers.js v6:

Automatic MetaMask integration — connects to SCAI Mainnet, prompts users to switch if on the wrong network
Live dashboard — staked amount, available rewards, APR, APY, and wallet balance, all pulled from a single getDashboardData() call
Auto-approval flow — approve() is called automatically before staking, so users never see a confusing failed transaction
Multi-wallet support — MetaMask, WalletConnect, and Coinbase Wallet via RainbowKit
Transaction hash links — every stake, withdraw, and claim links directly to the block explorer

Tech Stack

Layer	Technology
Smart Contracts	Solidity ^0.8.19
Development	Hardhat
Frontend	React 18, TypeScript, Ethers.js v6
Wallet Connectivity	RainbowKit, Wagmi, WalletConnect
Deployment	Vercel (frontend), SCAI Mainnet (contracts)

Deployed Contract Addresses (SCAI Mainnet — Chain ID: 34)

Contract	Address
ERC20Token (STK)	`0x822Bc4Be4e784e0a9b78d92Fa2c79cF1E471512e`
StakingContract	`0x530944aC3cb1A8AC17Ca11b90EB17D90c5d5bE78`

All contracts are verified on the SecureChain Explorer.

How to Run Locally

Clone the repo

git clone https://github.com/feudcommon/DeFi-staking-platform.git
cd DeFi-staking-platform

Install dependencies

npm install

Start the dev server

npm start

The app opens at http://localhost:3000. Connect a wallet, switch to SCAI Mainnet, claim STK from the faucet, and start staking.

Key Learnings

The approve → stake two-step is where most dApp UX breaks. Checking the existing allowance first and only prompting for approval when needed turns two confusing transactions into one smooth click.

Struct packing saves real gas at scale. Packing lastUpdateTime, stakedSince, and a reserved field into a single storage slot means every stake and withdraw call writes less data on-chain.

A public faucet is essential for review. Letting anyone claim test tokens directly, with a simple cooldown, means reviewers and new users never have to ask for funds manually before trying the platform.

Basis points avoid floating-point math entirely. Storing the reward rate as BPS instead of a percentage keeps reward calculations precise and avoids decimal handling issues that Solidity doesn't support natively.

Acknowledgements

Massive thanks to the Ether Authority team for designing such a structured, hands-on internship program. Building and shipping a real project every week is the fastest way to grow as a Web3 developer.

Web3 #Blockchain #Ethereum #ReactJS #SmartContracts #SCAI #Internship #Solidity #SecureChainAI #EtherAuthority #DeFi #Staking #OpenSource #Hardhat #Vercel