Forem: Dima Zaichenko

How I Added On-Chain Rewards and NFTs to Solana Quiz: Practical Insights, Pitfalls, and Tips

Dima Zaichenko — Tue, 18 Nov 2025 08:32:05 +0000

In my previous article on Dev.to, I shared how I built a small app - Solana Quiz, where users answer daily questions and earn rewards.

Here’s the link to that article (to skip architecture and basic setup):

👉 Previous Article

Since then, I’ve significantly expanded the functionality: I added on-chain rewards, 7-day streaks, and the most exciting part - NFTs for a series of perfect answers.

At first glance, it seems simple: trigger an event → reward tokens → sometimes issue an NFT.

But that "sometimes" hides a mountain of nuances: from Solana PDAs to the order of metadata calls and weird errors not explained anywhere officially.

In this article, I’ll share:

How I implemented on-chain/off-chain rewards
Why streaks behave differently in these modes
How NFT rewards work
Common pitfalls I encountered
What you need to know about the correct command sequence when creating NFTs (if you change the order, everything breaks)

🟡 How Solana Quiz Works Now

When a user completes a quiz (currently always 5 questions, hardcoded; soon configurable in .env), the app:

Sends the result to Kafka
Rust service receives the event and grants the reward
Depending on the mode (SOLANA_ON_CHAIN=true/false), the reward is applied:
- On-chain → Solana transaction
- Off-chain → Local API
Rust confirms the reward via Kafka
Node.js marks the reward as issued
If a 7-day streak of perfect answers is achieved → NFT is minted

🧰 Working with Solana test-validator + Transaction Simulation

🚀 Why use solana-test-validator

When I started writing the on-chain part of the quiz, I quickly realized: testing everything directly on devnet is painful.

Transactions confirm slower
It’s hard to tell if an error is mine or the network’s
Some errors (especially PDA / metadata) are hard to catch in production

Solana has an amazing tool - the local validator:

solana-test-validator

This is a full local Solana chain, launched with a single command.

Benefits:

Fast, infinite tokens
Deploy programs locally without restrictions
RPC available by default: http://127.0.0.1:8899

Now you can point your app to it:

SOLANA_NETWORK=local
SOLANA_RPC_ENDPOINT=http://127.0.0.1:8899 # http://host.docker.internal:8899

When useful:

Writing your Solana programs (Anchor or pure Rust)
Testing mint NFT / PDA / metadata
Simulating transactions in bulk
Reproducing errors quickly and consistently

🧪 Devnet, Localnet, Mainnet - What’s the Difference?

Environment	Purpose	Pros	Cons
Localnet (`solana-test-validator`)	Instant dev	Instant blocks, full control	Not reflective of real network
Devnet	Pre-prod / public tests	Real load, public RPC	Sometimes slow, has limits
Mainnet	Production	Stable, real tokenomics	Expensive transactions

💡 Recommended workflow:

80% of the time → work on test-validator
20% → final checks on devnet

🔍 Simulating Transactions & Getting Readable Errors

Without simulations, you lose half the debugging info. Simulation allows you to:

Catch errors before sending
See program logs
Read SPL token, Metaplex errors, etc.
Check which PDAs don’t match
Verify if you have enough signers
See on-chain stack traces

Example:

let simulation = self.rpc_client.simulate_transaction(&transaction).await?;
println!("Simulation logs: {:#?}", simulation.value.logs);

These lines saved me a lot of time.

🔄 On-chain vs Off-chain: What SOLANA_ON_CHAIN Really Controls

A common mistake is thinking this variable enables or disables rewards.

No. Rewards are always calculated. It only affects how the reward is applied:

SOLANA_ON_CHAIN	Token Calculation	Streak Calculation
true	On-chain (Solana transaction)	Based on successful on-chain tx
false	Off-chain (via Rust API)	Locally in Rust, without interacting with Solana

Why? Streak logic must be consistent. On-chain → real transactions. Off-chain → faster and cheaper to calculate locally.

🧩 NFT Rewards for Streaks

NFTs are issued for 7-day streaks of perfect answers (SOLANA_STREAK_DAYS=7).

Future plans: rarities, levels, different types of NFTs. For now, only one type is implemented.

Technically, NFT creation process:

Create a new mint
Create ATA for the user
Mint 1 token to the ATA
Create metadata (with master edition)

Here begins the magic - or rather, the pain.

🔥 Main Pain: Command Order Matters

If you look at Metaplex or Solana SDK examples, you won’t see warnings about call order. I didn’t either.

In my real project, here’s what happened:

❌ Doing it incorrectly:

create_metadata();
mint_token();

Result: NFT often didn’t create; errors like:

"mint must have exactly 1 token minted before metadata creation"
"MasterEdition account does not match mint supply"
Or transaction failed silently

✔ Working order (experimentally verified):

mint_token();
create_metadata(); // metadata is created (along with the master edition)

Why this order?

Mint must have supply = 1 before metadata creation
ATA must exist beforehand; otherwise mint_to_checked has no destination
MasterEdition can only be created after successful mint_to_checked
All encapsulated in create_metadata()

I tried many variations; only this order works reliably, regardless of RPC or environment.

⚠️ Signers Matter

Errors often happen if authority is incorrect or keypair not signed. Any transaction without the correct signer will fail or return weird errors.

💡 Tip: Use transaction simulation to see all errors and warnings in readable form, without wasting SOL on devnet or mainnet.

🧠 Why NFTs at All?

Motivates users - 7-day streak is a small achievement, but tangible rewards feel nice
Great way to learn Metaplex & Solana SDK deeper
GitHub showcase - Rust + Solana + Node.js + Kafka interaction

Repository: Solana Quiz GitHub

Solana program: lib.rs
Example logs: Solscan tx

NFT API: nft_api.rs
Example logs: Solscan tx

🎯 Other Technical Notes

PDA for Metadata & MasterEdition must be calculated manually. No convenient module exists (mpl_token_metadata::pda)
Mint authority should exist only until token issuance
ATA for NFT is always unique (NFT = 1 token, 0 decimals). Errors occur if decimals != 0

🎯 Future Expansion

Different NFT types for different streak lengths
On-chain streak counting fully in Anchor program
Reward levels
NFT collections
mainnet-beta support

Currently, one NFT type & 7-day streak, but architecture allows painless future expansion.

⚡ Conclusion

I went through:

On-chain/off-chain reward logic
Full NFT creation on Solana
Manual PDA calculation
Metaplex errors not documented anywhere
Experimentally determined correct NFT creation sequence

Now Solana Quiz is not just a game - it’s a service where:

Tokens are awarded honestly and transparently
Streaks are tracked correctly
Users can earn a small but real NFT for persistence

Check the working code or fork the project: 👉 GitHub

🧠 How I Combined OpenAI, Rust, and Solana: a Quiz That Pays You in Tokens

Dima Zaichenko — Mon, 13 Oct 2025 20:06:14 +0000

What if every correct answer in a quiz rewarded you with crypto?

I decided to test this idea and built Solana Quiz - a decentralized app where users answer daily quiz questions generated by OpenAI and earn Solana tokens for correct answers.

Yes, it really works. And yes - we even mint our own token 😎.

🚀 The Idea

I’ve long wanted to combine AI, Rust, and blockchain into a single project where each piece actually works, not just “for show.”

The result:

OpenAI generates fresh questions daily.
Node.js checks answers and handles the business logic.
Rust mints tokens on Solana.
Kafka ties all the services together in a clean event-driven system.

The outcome? A smart, fair, and transparent quiz where rewards don’t land in your email - they land in your Phantom Wallet.

💡 How It Works

1️⃣ Solana Wallet Authentication

Users connect their Phantom Wallet and sign a message. Node.js verifies the signature and confirms wallet ownership.

No passwords, tokens, or logins - just pure blockchain authentication.

Currently, only Phantom Wallet is supported, but adding more wallets is possible.

2️⃣ Questions Powered by OpenAI

Every morning, Node.js queries the OpenAI API (gpt-4.1-nano) to get a new set of questions.

OPEN_AI_API_KEY=your_openai_api_key_here
OPEN_AI_MODEL=gpt-4.1-nano
OPEN_AI_LANGUAGE=English

💡 You need an OpenAI account and API key. Without it, the quiz stays silent 🤖

The questions are varied: from blockchain history to logic puzzles.

3️⃣ Checking Answers & Rewards

Once the quiz is submitted, Node.js publishes an event to Kafka, and the Rust worker listens for it. It then connects to Solana RPC and… 💸 sends tokens straight to your wallet.

Every correct answer instantly becomes real crypto on the blockchain.

🏗 Architecture

Service	Technologies	Description
Frontend	Next.js, React, TailwindCSS	User interface and wallet integration
Backend	Node.js, Express, Prisma, KafkaJS, OpenAI API	Quiz logic, question generation, API
Rust Worker	Rust, Solana SDK, rdkafka	Token minting and Solana transactions
Database	PostgreSQL	User data and quiz results storage
Infra	Docker Compose	Service orchestration

🪙 Creating Your Own Token

The heart of the quiz is a custom SPL token on Solana. This isn’t just a demo coin - it powers the whole quiz economy and makes the reward system transparent and decentralized.

⚠️ Before running the Rust commands, make sure your .env file is ready:

SOLANA_NETWORK=devnet
SOLANA_RPC_ENDPOINT=https://api.devnet.solana.com
SOLANA_AUTHORITY_KEYPAIR_PATH=./secret/authority.json
SOLANA_MINT_KEYPAIR_PATH=./secret/mint.json
SOLANA_TOKEN_NAME="Solana Quiz Token"
SOLANA_TOKEN_SYMBOL="SQT"
SOLANA_TOKEN_METADATA_URI="https://raw.githubusercontent.com/di-zed/internal-storage/refs/heads/main/solana-quiz-token/metadata.json"

💡 Important: You can change the token name, symbol, description, and metadata - it’s your token, your universe.

🚀 Step-by-step: Minting your own Solana token

Let's go through the full process — from building the binary to minting your first million tokens 🪙

# 🦀 Enter the Rust container
docker-compose exec rust /bin/bash

# ⚙️ Build the release binary
cargo build --release

# 💧 Request some SOL for your authority account
./target/release/solana request-airdrop --sol-amount 5

# 🪙 Create a new token mint
./target/release/solana create-mint

# 💼 Create a token account to store your tokens
./target/release/solana create-token-account

# 💰 Mint 1,000,000 tokens
./target/release/solana mint-tokens --amount 1000000

💡 These tokens are your reward bank —
every time someone answers correctly in the quiz, the Rust worker distributes tokens from this pool.

To make your token display nicely in Phantom Wallet and Solana Explorer, add metadata such as:

https://raw.githubusercontent.com/di-zed/internal-storage/refs/heads/main/solana-quiz-token/metadata.json

🧠 Why Rust

Rust is perfect for working with the Solana SDK - safe, async-friendly, and memory-safe.

Even if you were a bit intimidated by Rust before, this project will make it your new crypto buddy 🦀.

💎 Use Cases

🎓 EdTech: tokenize learning - correct answers = real rewards.
🏢 Corporate quizzes: motivate employees with tokens.
🌐 Crypto communities: daily activities and rewards on Solana.
💰 Loyalty & gamification: on-chain incentives for engagement.

🧭 Roadmap

🏆 NFT rewards - issue NFTs for streaks of correct answers.
🔗 Solana Program - store quiz history and auto-distribute NFTs.
🚀 Mainnet-beta migration.

The Solana program will eventually track quiz history on-chain and automatically reward users who maintain a streak (e.g., 7 days in a row).

NFTs can be created manually via Metaplex - your collection, your designs, your rewards 🎨

🧩 A Bit of Technical Info

I didn’t dive into setup commands in this article - we want it to be easy to read 😄

If you want to actually run the project, mint your own token, connect OpenAI, and see Solana deliver real rewards - check the README on GitHub.

It has step-by-step instructions, .env examples, and Docker, Rust, and Node.js commands - everything you need to dig deeper.

🧱 Bottom Line

Solana Quiz isn’t a demo or experiment. It’s a live app where AI, Rust, and blockchain work together:

OpenAI generates content
Node.js manages logic
Kafka connects everything
Rust handles real transactions

The result? A fair reward system where knowledge brings you crypto, not just points.

⚙️ The project runs entirely via Docker - clone the repo, follow the README, and you’re good to go. Everything is covered, including key generation and OpenAI/Solana setup.

📦 GitHub: github.com/di-zed/solana-quiz

📜 License: MIT

✍️ Author: @di-zed

Telegram AI Companion: A Fun Rust + Local AI + Telegram Project

Dima Zaichenko — Tue, 24 Jun 2025 07:09:05 +0000

Hey dev.to! 👋

Recently I built a small but fun pet project — Telegram AI Companion.

It's a Telegram bot that chats with you using a local LLM via LocalAI.

No OpenAI, no clouds — everything runs on your own machine! 🧠💻

The goal? Not to reinvent AI, but to explore Rust, async programming, Telegram API, and local LLMs. Think of it as a “developer's companion bot”. 😄

🧩 What It Can Do

✅ Replies to any message in Telegram

✅ Works with LocalAI (or OpenAI if you want)

✅ Runs via Docker + Docker Compose

✅ Written in Rust with Actix Web

✅ Has a REST API (/chat) — hook up any UI

✅ Includes tests and has a clean project structure

⚙️ How It Works

Overview

User sends a message to the Telegram bot
Telegram calls our webhook (/telegram/webhook)
Rust app sends the prompt to LocalAI
Gets a reply and sends it back to the user

Tech Stack

🦀 Rust — strict but powerful

🌐 Actix Web — high-perf async framework

📦 Docker & Compose — clean and reproducible

🧠 LocalAI — local alternative to OpenAI, supports GGUF/LLaMa

☁️ Optional: OpenAI support via .env

🚀 Quickstart

Clone the repo:

git clone https://github.com/di-zed/tg-ai-companion
cd tg-ai-companion

Download a model (e.g., Mistral 7B) and configure:

cd models/
wget https://huggingface.co/TheBloke/Mistral-7B-Instruct-v0.2-GGUF/resolve/main/mistral-7b-instruct-v0.2.Q4_K_M.gguf

Create mistral.yaml:

name: mistral
backend: llama
parameters:
  model: mistral-7b-instruct-v0.2.Q4_K_M.gguf
  temperature: 0.7
  top_p: 0.9
  top_k: 40
  n_ctx: 4096

Or configure OpenAI in .env:

OPEN_AI_URL=http://localai:8080
OPEN_AI_MODEL=mistral
OPEN_AI_API_KEY=your_openai_key

Start the app (don't forget to edit .env):

cp .env.sample .env
cp volumes/root/.bash_history.sample volumes/root/.bash_history

docker-compose up --build
docker-compose exec rust bash
cargo run

Now your bot runs locally, and LocalAI listens on localhost:8080.

🤖 Create Your Telegram Bot

Open Telegram and talk to @BotFather
Run /newbot, set a name and a unique username (something_bot)
You'll get a token like:

123456789:AAH6kDkKvkkkT-PWTwMg6cYtHEb3vY_tS1k

Paste it into .env:

TELEGRAM_BOT_TOKEN=your_token_here

🌍 Expose Webhook via ngrok

Make your local server reachable:

ngrok http 80

Then set webhook:

curl -X POST "https://api.telegram.org/bot<YOUR_TOKEN>/setWebhook" \
     -H "Content-Type: application/json" \
     -d '{"url": "https://your-subdomain.ngrok-free.app/telegram/webhook"}'

🔐 API Mode (No Telegram)

You can also call it like a standard LLM API:

POST /chat

Header: Authorization: Bearer YOUR_TOKEN

{
  "prompt": "Hi, who are you?"
}

LocalAI (or OpenAI) responds.

🧠 Why I Built This

Main goals:

Learn Rust hands-on
Explore local LLMs without API keys
Build something fun and useful
Play with Telegram bots 😎

This can be a base for future AI bots with memory, content generation, assistants, and more.

📅 What’s Next?

Memory + conversation context
Web interface
Multi-model support

💬 Final Thoughts

If you're just starting with Rust or want to try local LLMs — this might be a perfect playground.

The code is clean, the stack is modern, and setup is smooth.

I kept this post light — for deep dives, check the full README:

🔗 GitHub: tg-ai-companion

🔗 Useful Links

🧠 LocalAI — LLM backend

🦀 Rust Book — start here

☁️ ngrok — webhook tunneling

Thanks for reading! 🙌

If the bot responds cheerfully — that’s on me.

If it’s silent — blame Telegram or ngrok 😄

How to Automatically Renew Let’s Encrypt SSL Certs with Certbot on Ubuntu 🔐

Dima Zaichenko — Mon, 23 Jun 2025 05:36:30 +0000

“I’m not a DevOps engineer, but I play one in production.”

Tired of manually renewing SSL certs every 90 days like it’s a Tamagotchi from 2005?

This guide is for you: developers who want HTTPS without DevOps nightmares.

🤔 Why Certbot?

Because:

It's free (thanks, Let's Encrypt).
It works (thanks, Certbot).
It renews itself (mostly).
And most importantly: you can get back to writing code instead of deciphering NGINX logs at 3AM.

🧪 Step 1 — Install Certbot

sudo apt update
sudo apt install certbot

Boom. That’s it. The easy part.

📜 Step 2 — Get your first SSL cert

sudo certbot certonly --standalone \
  -d yourdomain.com -d www.yourdomain.com

Check what you got:

sudo certbot certificates

🧠 Heads-up: --standalone runs a temporary HTTP server on port 80.

If you're using Nginx or Docker, stop them first or use --webroot.

More information about plugins can be found in the official documentation.

🔁 Step 3 — Let it renew itself (like magic)

Certbot installs a systemd timer by default:

systemctl list-timers | grep certbot

You can see output like:

Mon 2025-03-10 03:12:00 UTC  10h left  Mon 2025-03-09 03:12:00 UTC  certbot.timer  certbot.service

Test if it works:

sudo certbot renew --dry-run

You should see something like:

Certbot dry-run was successful.

📅 Certbot renews certificates when they’re 30 days from expiry.

Latest update logs:

journalctl -u certbot.service --no-pager --since "2 days ago"

🧓 Prefer old-school cron? No problem

Disable the timer:

sudo systemctl stop certbot.timer
sudo systemctl disable certbot.timer

Then add this to your crontab (sudo crontab -e):

0 0 1 * * /usr/bin/certbot renew --standalone --quiet

To find out the exact path to certbot, use:

which certbot

Because nothing says “legacy and proud” like a 1AM cron job.

🧙 Use Hooks Like a Wizard

Automatically stop/start your services when certs are renewed.

Open your renewal config:

sudo nano /etc/letsencrypt/renewal/yourdomain.com.conf

Add:

pre_hook = systemctl stop your-app.service
deploy_hook = systemctl reload your-app.service
post_hook = systemctl start your-app.service

Perfect when you want Certbot to renew certs and do the dishes.

🛠 Bonus: Bash Script of Champions

This is what you actually wanted — a copy-pasteable script to handle everything:

#!/bin/bash
APP_PATH="/home/you/yourapp"
DOMAIN="yourdomain.com"

FULL_CHAIN="/etc/letsencrypt/live/${DOMAIN}/fullchain.pem"
PRIVATE_KEY="/etc/letsencrypt/live/${DOMAIN}/privkey.pem"

CRT_DEST="${APP_PATH}/ssl/${DOMAIN}.crt"
KEY_DEST="${APP_PATH}/ssl/${DOMAIN}.key"

echo "[$(date)] Stopping the service..."
systemctl stop your-app.service

echo "Renewing certs silently..."
/usr/bin/certbot renew --standalone --quiet

echo "Copying certs like a pro..."
cp -f "$FULL_CHAIN" "$CRT_DEST"
cp -f "$PRIVATE_KEY" "$KEY_DEST"
chmod 644 "$CRT_DEST" "$KEY_DEST"

echo "Starting the service again..."
systemctl start your-app.service

echo "🎉 All done. Go grab a coffee."

Crontab it like a boss:

0 0 1 * * /bin/bash /home/you/scripts/renew-ssl.sh >> /var/log/certbot.log 2>&1

🧠 Final Thoughts

SSL shouldn't be harder than writing JavaScript regex.

Certbot + Let’s Encrypt is one of those rare tools that actually “just works” — if you let it.

✅ Works with cron

✅ Supports systemd

✅ Has deploy hooks

✅ Costs $0

Just test it every now and then. Let automation do its thing.

And for the love of uptime — back up your certs.