DEV Community: Rohit Purkait

What If the Blockchain Could Judge Your Bluff Without Seeing Your Dice?

Rohit Purkait — Wed, 19 Aug 2026 09:07:15 +0000

Liar’s Dice sounds like a perfect game to put onchain.

The rules are simple, every move can be verified, and you don’t need a centralized game server deciding who won.

There is just one problem.

Blockchains are public. Liar’s Dice only works if your dice are private.

If I simply stored every roll inside a normal smart contract, anyone could inspect the state and know exactly what everyone was holding.

At that point, there is no bluffing.

You would basically be playing poker with everyone's cards face up.

So I built FHE Liar’s Dice, a decentralized version of the game where your dice remain encrypted while the game is being played.

Not hidden behind a backend.

Not stored privately in some database.

Encrypted onchain.

And the interesting part is that the smart contract can still use those encrypted dice to determine whether you are lying.

The problem with putting hidden-information games onchain

Most blockchain games actually benefit from transparency.

If you're building something like chess, every player is supposed to know the complete state of the board.

Liar’s Dice is different.

Each player starts with five dice that only they should be able to see.

Players then make public claims about the combined dice across the entire table.

You might say:

There are six 4s on the table.

The next player has two choices.

Raise the bid.

Or call your bluff.

The entire game comes from the fact that nobody knows exactly what everyone else is holding.

But a traditional smart contract has the opposite property.

Its state is transparent.

Even if the frontend refuses to display your dice, someone can simply inspect the contract, query the state, watch events, or build their own interface.

Hiding something in the UI isn't privacy.

I needed the actual game state itself to remain secret.

FHE turned out to be a very good fit for the game

I built the game using Fhenix CoFHE.

Fully Homomorphic Encryption is interesting because it allows computation to happen directly over encrypted values.

Normally encryption gives you privacy while data is stored, but you need to decrypt the data before doing anything useful with it.

With FHE, you can keep the value encrypted and still perform computations over it.

That completely changes what an onchain game can do.

In FHE Liar’s Dice, the contract generates each player's dice as encrypted values.

Conceptually, instead of the contract storing:

[2, 6, 4, 1, 3]

it stores encrypted representations of those values.

No plaintext die value is written into contract storage or emitted through an event while the round is active.

Only the player who owns that hand can unseal it and see what they rolled.

So your opponents can't read your dice.

An indexer can't read your dice.

And even the application operator doesn't get the plaintext values.

That gives the game something I couldn't get from a normal smart contract:

private state with public execution.

The weird part: checking a bluff without revealing the dice

This was the part I found most interesting while building the game.

Imagine I bid:

Six 4s.

Someone calls me a liar.

Now the contract needs to inspect every active player's dice and determine how many 4s actually exist.

In the version of Liar’s Dice I implemented, ones are wild, so they also count toward most bids.

The obvious implementation would be:

decrypt all dice
count the matches
compare count >= bid

But that defeats the entire point.

Instead, the contract performs the comparison over the encrypted values themselves.

It checks every encrypted die, calculates whether it matches the bid, includes wild ones where appropriate, and builds the result without revealing the underlying hands.

The final thing that needs to become public is essentially one bit of information:

Was the bid valid?

Yes or no.

If the true encrypted count meets the bid, the challenger loses.

If it doesn't, the bidder was lying and gets eliminated.

The actual count doesn't need to be revealed to reach that verdict.

That distinction is small, but it is the entire architecture of the game.

The chain gets enough information to enforce the rules without learning information it doesn't need.

What stays private and what stays public

I didn't want to make everything private.

That would remove one of the reasons to build the game onchain in the first place.

So I separated the game state into two categories.

Things like these are public:

who joined the table
turn order
every bid
who challenged
whether the bid was valid
who was eliminated
the final result

The active dice are private.

That creates a nice split.

The strategy stays private. The execution stays verifiable.

After a challenge resolves, the hands from that round can be revealed so everyone at the table can see what actually happened.

Then the surviving players receive fresh encrypted hands for the next round.

The last player standing wins.

Why I didn't just use a server

The easy version of this project would have been straightforward.

Generate the dice on a backend.

Send each player their own hand.

Have the server determine whether every challenge succeeds.

From a game-development perspective, that works perfectly fine.

But then the server becomes the dealer, referee, and source of truth.

It knows everybody's dice.

It could theoretically alter rolls.

It could leak information.

And players ultimately have to trust whoever operates it.

That isn't particularly interesting to me.

The point of the experiment was to see whether we could remove that trusted game master without destroying the hidden-information mechanics that make Liar’s Dice fun.

FHE makes that possible.

The smart contract becomes the referee without becoming the omniscient dealer.

I also built a completely offline practice mode

One problem with building blockchain games is that people often need to connect a wallet before they even understand what the product does.

I didn't want that.

So FHE Liar’s Dice also has a practice mode.

It uses the same basic bluffing loop but runs locally against bots.

No wallet.

No blockchain transaction.

No encryption.

You can understand the game first, then enter the actual onchain lobby when you want to play the privacy-preserving version against other people.

The distinction is intentional.

There is no reason to pretend the offline version is decentralized.

It exists purely as an onboarding layer.

The game is still intentionally simple

The current version is a prototype.

There are no wagers.

No ranked mode.

No tournament system.

No timers.

I wanted to solve the harder primitive first:

Can you run an actual hidden-information bluffing game through a smart contract without exposing the hidden information?

Once that loop works, everything else becomes product design.

One known tradeoff in the current implementation is dice generation.

The dice are derived using an encrypted random uint8, reduced modulo six and shifted into the 1–6 range.

Because 256 isn't perfectly divisible by six, there is a very small distribution bias: faces 1 through 4 appear marginally more often than 5 and 6.

For a casual prototype I accepted that tradeoff and documented it rather than hiding it.

The contracts are also unaudited, so this is absolutely not something I would attach real-money wagering to in its current form.

What building this changed for me

Before this project, it was easy for me to think about blockchain privacy mostly in terms of private transfers or private financial positions.

Building a game made the idea much more tangible.

There is a huge class of applications where you don't necessarily need to hide the entire system.

You need to hide specific pieces of state while still allowing programs to compute over them.

Games are one example.

Auctions are another.

Voting, identity, trading strategies and many financial applications have variations of the same problem.

Public blockchains are extremely good at proving that computation happened according to known rules.

FHE adds another interesting possibility:

proving that rules were followed without forcing every input involved in those rules to become public.

Liar’s Dice happens to make that idea very easy to see.

You have five dice.

Nobody else should know them.

The contract still needs to know whether your bluff worked.

And somehow both things need to be true at the same time.

That is what I wanted to build.

Try bluffing against the blockchain

The project is live here:

https://fhe-liars-dice.vercel.app/

You can jump into practice mode without a wallet or create an onchain table and play the FHE version with other players.

The simplest description of the project is still probably the one I started with:

Nobody sees your dice.

Everyone sees your lies.

I built TraceGate because my AI agent demo passed, but the traces told a different story

Rohit Purkait — Sun, 26 Jul 2026 12:46:53 +0000

Most AI agent demos stop at the final answer.

Mine did too at first. I had a support agent that could answer a refund question, call a policy tool, and avoid a prompt-injection path. From the outside, it looked fine.

Then I asked a less comfortable question: if this agent broke in production, would I actually know what happened?

That question became TraceGate.

TraceGate is a release gate for AI agents built with OpenTelemetry and SigNoz. It runs agent scenarios, sends telemetry to SigNoz, then checks whether the run produced enough evidence to safely ship.

The problem

AI agents can pass a demo while still being hard to debug.

A tool can retry three times and still return a successful answer. An LLM call can happen without cost metadata. A prompt-injection test can pass, but leave no trace of which safety path was used. Those are not product failures in the usual sense. They are observability failures.

That is what I wanted TraceGate to catch.

The idea is simple: before an agent ships, it should satisfy an observability contract. If the contract fails, the release is blocked.

What TraceGate checks

TraceGate uses a YAML contract to describe what a safe release run should include.

Here is part of the contract I used:

name: TraceGate AI Agent Release Contract
serviceName: tracegate-demo-agent

budgets:
  maxRunCostUsd: 0.005
  maxP95LatencyMs: 2000
  maxToolRetries: 1

checks:
  - id: span-agent-run
    type: required-span
    spanName: agent.run
    severity: critical

  - id: span-llm-call
    type: required-span
    spanName: llm.call
    severity: critical

  - id: attr-llm-model
    type: required-attribute
    spanName: llm.call
    attribute: gen_ai.request.model
    severity: critical

  - id: retry-budget-trace-lookup
    type: max-tool-retries
    toolName: trace.lookup
    maxRetries: 1
    severity: critical

The default demo intentionally fails one check. The trace.lookup tool retries three times, but the contract only allows one retry.

That makes the demo useful because TraceGate is not pretending everything is healthy. It blocks the release and explains why.

TraceGate FAIL
Checks: 7/8 passed
Critical failures: 1
FAIL retry-budget-trace-lookup - Worst retry count for 'trace.lookup' was 3; limit 1.

The architecture

The stack is:

Vite
React
TypeScript
Node.js
OpenTelemetry
SigNoz
OpenAI
YAML contracts

The flow looks like this:

Scenario -> Agent runner -> OpenTelemetry -> SigNoz -> TraceGate contract evaluator -> Pass or block

The Node runner executes the scenario. OpenTelemetry records spans, metrics, and logs. SigNoz receives the telemetry through OTLP. TraceGate reads the run result and evaluates it against the contract.

For the OpenTelemetry setup, I used the OTLP HTTP exporters:

const endpoint =
  process.env.OTEL_EXPORTER_OTLP_ENDPOINT ?? "http://localhost:4318";

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: `${endpoint}/v1/traces`
  }),
  logRecordProcessor: new BatchLogRecordProcessor(
    new OTLPLogExporter({
      url: `${endpoint}/v1/logs`
    })
  ),
  metricReader: new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter({
      url: `${endpoint}/v1/metrics`
    }),
    exportIntervalMillis: 1000
  })
});

In my local setup, SigNoz received spans for:

agent.run
llm.call
tool.ticket.lookup
tool.policy.search
tool.trace.lookup

A build issue I hit

The part that took the most debugging was the local SigNoz setup.

I used Foundry to run SigNoz locally. The first time I started everything, the UI was up, but the telemetry path was not useful. The collector looked alive, but the pipeline was effectively not sending the data I expected.

The issue was in the generated local configuration around the OpAMP and MCP service wiring. I patched the generated setup so the ingester pointed to the actual SigNoz service and the MCP server pointed to the SigNoz UI service. After that, the OTLP export worked and I could verify spans in ClickHouse.

That was the most “real” part of the project for me. The code for the gate was straightforward compared to proving that telemetry actually reached the backend.

The workbench

TraceGate has a landing page and a workbench.

The landing page explains the idea: ship agents only when the traces agree.

The workbench shows:

latest release verdict
checks passed
critical failures
cost
latency
gate matrix
failed evidence
SigNoz investigation query

The gate matrix is the part I care about most. It turns vague release confidence into specific checks.

For example:

Root agent run span: pass
LLM calls traced: pass
Model attribute present: pass
Cost attribute present: pass
Cost budget: pass
Trace lookup retry budget: fail
Refund support scenario: pass
Prompt injection scenario: pass

That gives a reviewer a much better starting point than “the demo worked on my machine.”

Judge test mode

I also added a judge-operated test mode because I did not want the hosted app to feel like a static mockup.

A judge can enter:

service name
scenario
tool name
retry budget
observed retries
cost
latency

Then TraceGate generates a new verdict.

For example:

service: checkout-agent
tool: inventory.lookup
allowed retries: 1
observed retries: 3

That blocks the release.

If the observed retries are changed to 0, the release becomes ready.

This makes the product easier to test without asking someone to set up my whole local environment first.

What I learned

The main thing I learned is that observability is more useful when it is tied to a decision.

Before this project, I mostly treated observability as something I would open after a bug. With AI agents, that feels too late. If an agent takes a risky path, skips metadata, hides cost, or retries a flaky tool several times, I want to know during release validation.

The second thing I learned is that “the agent worked” is too broad. I now split it into two questions:

Did the agent produce the expected outcome?
Did the agent produce enough evidence to debug that outcome?

TraceGate focuses on the second question.

What I would build next

The next version should have a visual contract editor. Writing YAML is fine for a hackathon, but a team should be able to create a release gate by choosing required spans, attributes, budgets, and scenarios in the UI.

I would also add GitHub Actions support. The natural place for TraceGate is in CI, where it can block an agent release before merge.

The final improvement would be deeper SigNoz artifacts. Each contract should generate a matching dashboard, alert, and investigation prompt so the release gate and the debugging workflow stay connected.

Final thought

TraceGate started from one uncomfortable question: if my AI agent fails later, will I have the evidence to understand it?

SigNoz already gives teams a strong place to inspect telemetry. TraceGate adds a release workflow on top of that telemetry.

The project is small, but the idea feels useful: agents should not ship only because the final answer looked good. They should ship when their behavior is traceable enough to trust.

Every AI-built site looks the same, so I built a skill that locks taste before any code is written

Rohit Purkait — Sat, 18 Jul 2026 00:40:32 +0000

I build a lot of side projects with AI coding tools. Mostly Claude Code. A few months ago I noticed something that kept bugging me. Every site I shipped looked the same. Same indigo gradient. Same default font. Same rounded cards with the same soft shadow.

Then I started noticing it on other people's projects too. Demo days, launch posts, screenshots on social media. The indigo gradient is everywhere. It is basically a uniform at this point.

This is not really the AI's fault. When you do not give a model a design direction, it picks the average of the internet. And the average of the internet is a Tailwind starter template with an indigo gradient and Inter. The model is doing exactly what it was trained to do. The problem is that nobody told it what you actually want.

So I built tastemaker. It is a skill for Claude Code, and it also works with Cursor, Windsurf, and Codex. The idea is simple: lock the design system before the AI writes a single line of UI.

Full disclosure before we go further: I built this. I am a solo builder. It is free and open source under the MIT license. I am posting it here because I want honest feedback, not because I have anything to sell you. There is nothing to buy.

Taste first, code second

A skill is just a folder of instructions the AI reads before it starts working. tastemaker forces a design decision step at the beginning, with real constraints, instead of letting the model improvise the look as it goes.

When you start a UI project with it installed, this is what gets locked before any code exists:

A palette. 5 presets, each matched to a mood. Not random hex codes. Combinations that were picked to work together.
Fonts. 24 curated Google Font pairings. A display font and a body font that actually belong on the same page.
Real assets. Illustrator-grade illustrations, recolored to your palette. No gray placeholder boxes. No generic stock photo energy.
A logo. A constructed geometric mark, plus a full favicon set, so the tab icon is not the framework default.
Motion. GSAP and ScrollTrigger wired in by default, so scroll animation is a starting point, not a TODO you never get to.

The point is not that my taste is better than yours. The point is that any taste, written down and locked, beats no taste at all.

The part where I failed

This is my favorite part of the story, mostly because it is embarrassing.

I picked the 5 palette presets by eye. They looked good to me. I was confident. Then, because I wanted to be thorough, I wrote a small Python script to check every text-on-background combination against WCAG contrast ratios.

The first run failed 2 of my 5 presets.

My eyes said the palettes were fine. The math said real people would struggle to read the text. The math was right. I went back, adjusted the failing colors, and kept running the check until everything passed. All 5 presets that ship today pass that contrast check.

That little story is the whole argument for the project. Taste feels subjective until you write it down and test it. Once it is written down, you can check it, fix it, and reuse it. My eyeballs were wrong 40 percent of the time. A short Python script was right every time.

Install

One command, then restart Claude Code:

git clone https://github.com/codeswithroh/tastemaker ~/.claude/skills/tastemaker

That is the whole setup. No API keys. No config file. No account. Restart, start a UI project, and the design system gets locked before the AI starts guessing.

More details on the site:

tastemaker-skill.online

Source code:

codeswithroh
/
tastemaker

A Claude Code skill that grounds AI-generated UI in real reference images and a persistent per-developer taste profile, instead of generic AI-slop defaults.

A skill that gives AI real design taste, so the UI it builds does not look AI-generated.

Quick start · Why · Features · Presets · How it works · Contributing

See it live and try the demo →

What this is

Tastemaker is a skill for coding agents (Claude Code, Cursor, Windsurf). You install it once and forget it. Whenever you ask your agent to build or style a UI, tastemaker steps in and gives it a real design system to work from, instead of the generic defaults every model reaches for.

It is plain Markdown and small Python scripts. Everything runs on your machine. There is no hosted backend, no account, and no API key.

Why AI UI all looks the same

Ask any model to build a UI and you tend to get the same thing: an indigo to purple gradient, a soft shadow card, a generic…

View on GitHub

What I learned

A few things, in order of how much they surprised me.

First, constraints make AI output better, not worse. I expected locking the palette and fonts to feel limiting. It did the opposite. The model stopped spending effort on design indecision and spent it on the actual product. The output got more interesting, not less.

Second, the default look is a choice. Every time you skip the design conversation, you are choosing the average of the training data. That is still a design decision. It is just a boring one you made by accident.

Third, scripts beat eyeballs. I trust my taste. My taste failed 2 out of 5 times on a basic readability check. Now I write the check first and pick the colors second, and I think that order matters more than people realize.

Fourth, design debt starts at line one. Most of us treat design as a cleanup pass at the end of a project. With AI tools, the end never arrives, because there is always one more feature to generate. Deciding first is cheaper than fixing later.

If you try tastemaker, tell me what broke. Feedback is genuinely welcome, in the comments here or as an issue on GitHub. And if it saves you a few hours, a star on the repo helps other people find it.

Understanding Flow’s Lending Protocol Architecture

Rohit Purkait — Fri, 12 Dec 2025 08:14:06 +0000

A Beginner Friendly Guide for Web3 Developers

Lending protocols are one of the most important building blocks in decentralized finance. They let users borrow, lend, and build leveraged positions without intermediaries. Protocols like Aave and Compound defined the standard for collateralized on chain lending. Flow introduces a new approach through its Flow Credit Market (FCM) and the product built on top of it, Flow Yield Vaults (FYV).

This guide explains the context behind Flow’s design, how traditional lending protocols work, and what Flow is doing differently.

1. What Is a Lending Protocol?

A lending protocol is a smart contract system where:

Users deposit assets as collateral
They borrow other assets against that collateral
A health factor keeps the position safe
Collateral is liquidated if health becomes too low

Liquidation ensures the protocol does not end up with bad debt. But liquidation risk is one of the biggest user pain points in existing systems.

2. How Existing Protocols Handle Liquidations

Example: Aave

A typical liquidation flow looks like this:

Your collateral value falls
A Keeper detects your unhealthy position
The Keeper repays some of your debt using a flashloan
The Keeper receives a large chunk of your collateral at a discount

Problems with this approach:

Liquidations are large
Keepers profit from user loss
Liquidations can happen during brief volatility
Positions can get wiped out instantly

This model works, but it is harsh and inefficient for users.

3. Flow’s Architecture: Two Layers Working Together

Flow has two related but distinct systems.

3.1 Flow Credit Market (FCM)

This is the base lending layer. It provides:

Borrowing and collateral management
Health factor logic
Liquidation rules
An automation framework for top ups and draw downs

FCM is similar to Aave in role, but with improvements in liquidation mechanics.

3.2 Flow Yield Vaults (FYV)

This is a strategy built on top of FCM. FYV uses the automation hooks inside FCM to:

Continuously monitor position health
Sell a small portion of yield tokens when collateral drops
Buy more yield tokens when collateral rises
Maintain a stable health band so liquidation never occurs

FYV behaves like an automated rebalancing engine that runs continuously.

4. How Flow Handles Liquidations Differently

Flow’s liquidation system improves upon legacy designs.

Minimal Liquidation

Flow sells only the smallest amount of collateral needed to restore health.

DEX First Execution

Liquidations are routed through a decentralized exchange:

Predictable pricing
No dependency on external bots
Best possible market rate

If a Keeper wants to liquidate, they must beat the DEX price.

Multiple Small Adjustments

If the market keeps dropping, FCM performs several small corrections instead of one destructive liquidation.

5. Why FYV’s Automation Matters

Flow Yield Vaults automate everything a user would manually do.

Example behavior:

If FLOW price drops ten percent, FYV sells ten percent of yield tokens
If FLOW price rises fifteen percent, FYV buys fifteen percent more

This keeps users:

Maximally invested when safe
Hedged when risky
Protected from liquidation

Simulations show FYV achieves higher returns than similar strategies on Aave because:

It avoids liquidation loss
It maintains safe leverage
Automation captures more upside opportunities

6. Key Takeaways for Developers

Lending protocols can be redesigned to be more user friendly

Flow reduces liquidation pain and aligns incentives between the protocol and users.

Automation is becoming essential

Instead of relying on keepers or manual adjustments, Flow builds automated risk management at the protocol layer.

Deterministic liquidation improves user trust

DEX based execution ensures transparent and predictable behavior.

7. Summary

Traditional Lending Protocols

Large liquidations
Keeper profit is user loss
Sudden position wipeouts
No built in protection

Flow Credit Market + Flow Yield Vaults

Automated health balancing
Minimal liquidation
DEX driven execution
Continuous rebalance strategy
Higher return with reduced risk

Flow builds a safer and more efficient foundation for leveraged yield strategies, especially for developers building products on top of lending primitives.

Adding Telegram Notifications to Your Application: A Step-by-Step Guide

Rohit Purkait — Tue, 07 Jan 2025 13:30:49 +0000

Telegram is a powerful and widely-used messaging platform that offers seamless integration with applications through its Bot API. Whether you’re building a monitoring service, a trading bot, or a notification system, Telegram notifications can enhance user engagement by providing instant updates.

In this blog, we’ll walk you through the process of setting up a Telegram bot and enabling it to send notifications to your desired chat.

Why Telegram for Notifications?

• Ease of Use: Telegram bots are easy to set up and integrate with your application.

• Instant Delivery: Notifications are delivered in real-time.

• Global Reach: Telegram has millions of users worldwide.

• Customizable Experience: You can tailor the bot to send messages in any format, including text, images, and even buttons.

Step 1: Create a Telegram Bot

The first step is to create a bot in Telegram using the BotFather:

Open Telegram: Log into your Telegram account.
Search for BotFather: In the search bar, type “BotFather” and select the verified bot.
Start a Chat: Send the /start command to begin interacting with BotFather.
Create a New Bot: Use the /newbot command. You’ll be prompted to:
• Choose a name: This is the display name for your bot.
• Create a username: Must end with “bot” (e.g., MyNotificationBot).
Receive Your Bot Token: Once created, BotFather will provide a token that you’ll use to authenticate API calls. Save this token securely, as it’s your bot’s access key.

Step 2: Get Your Chat ID

Telegram needs to know which chat to send notifications to. To retrieve your chat ID:
1. Start a Chat with Your Bot: Search for your bot’s username in Telegram and send a message (e.g., “Hello”).
2. Use the Bot API: Use the following API endpoint to fetch updates and find your chat ID:

https://api.telegram.org/bot/getUpdates

Replace with the token provided by BotFather.

3.  Inspect the Response: The response will include a JSON object. Look for the chat field, which contains the id. This is your chat ID.

Step 3: Understanding the Telegram Bot API

Telegram provides a simple HTTP-based API to interact with your bot. The endpoint to send a message is:

https://api.telegram.org/bot/sendMessage

Required Parameters
• chat_id: The ID of the chat where the message should be sent.
• text: The message content.

Optional Parameters
• parse_mode: Format text using Markdown or HTML.
• disable_notification: Send messages silently (without sound).
• reply_markup: Add interactive buttons or keyboards.

Step 4: Test Your Telegram Bot

Once you have the bot token and chat ID, it’s time to test. You can use a tool like curl or Postman to send a sample message:

Using curl

curl -X POST "https://api.telegram.org/bot/sendMessage" \
-H "Content-Type: application/json" \
-d '{"chat_id": "", "text": "Hello from my bot!"}'

Using Postman
1. Set the method to POST.
2. Use the URL: https://api.telegram.org/bot/sendMessage.
3. In the body, use the JSON format:

{
"chat_id": "",
"text": "Hello from my bot!"
}

Step 5: Automating Notifications

To integrate Telegram notifications into your application, you’ll need to:
1. Capture the event or payload in your app that triggers a notification.
2. Format the message content dynamically (e.g., using placeholders for data like symbols, signals, or confidence levels).
3. Use the Telegram Bot API to send the message programmatically.

Best Practices
• Secure Your Bot Token: Treat it like a password. Avoid hardcoding it in your application.
• Rate Limiting: Telegram has limits on API requests. Ensure your app respects these limits to avoid being blocked.
• Error Handling: Check the API response for errors and retry failed requests if necessary.
• Use Webhooks: For advanced integrations, consider setting up a webhook to receive real-time updates from Telegram.

Conclusion

Adding Telegram notifications to your application is a straightforward way to enhance communication with your users. By leveraging the Telegram Bot API, you can deliver real-time updates, alerts, or even automate workflows with minimal effort.

This blog covered the setup process up to testing your bot. In the next part, we’ll dive into programmatically sending notifications using a backend service. Stay tuned!

If you have any questions or need assistance, feel free to drop them in the comments below. Happy coding! 🚀

Compiling 2025: My Roadmap for the Year Ahead

Rohit Purkait — Thu, 02 Jan 2025 21:56:10 +0000

This is a submission for the 2025 New Year Writing challenge: Compiling 2025.

As we step into 2025, I’m excited to share my personal roadmap for the year—a mix of new skills, ambitious projects, and career aspirations. It’s all about diving deeper into Web3, building tools to empower developers, and evolving my professional journey.

New Skill: Embracing Web3

The buzz around Web3 continues to grow, and I believe 2025 will be its breakout year. To prepare, I’m delving headfirst into this transformative technology. My learning path includes mastering Solidity, exploring Move by Aptos, and diving into other Web3 tools and frameworks.

Web3 represents the future of decentralized applications, and I’m thrilled to align my skillset with this rapidly evolving space. The potential is limitless, and I can’t wait to see where this journey leads.

Side Projects: Building for the Community

Sepolia Faucet

One of my key projects is creating a Sepolia faucet where developers can purchase Sepolia tokens using INR. Currently, most faucets require 0.001 ETH on the mainnet—a barrier for newcomers just starting out.

By offering a more accessible solution, my goal is to fuel creativity and innovation. Developers will be able to acquire Sepolia ETH with a minimal amount of INR, allowing them to focus on building and experimenting with their dApps. This project isn’t just about simplifying access—it’s about empowering the next wave of Web3 creators.

Just a base sneak peek. Will be launching on 7th Jan, 2025.

Decentralized Identification (DeID)

Another project close to my heart is building dApps around Decentralized Identification (DeID). Our current identification systems are outdated and ill-equipped for the modern era, where data breaches are increasingly common.

Through DeID, I envision a system that allows individuals to securely verify their identity wherever they go, putting control back into the hands of the user. This project is a step toward a future where personal data is safe, accessible, and decentralized—a future I’m eager to help shape.

Career Aspirations: Shifting Focus to Smart Contracts

As a Full Stack Developer, I’ve had the opportunity to work across the technology spectrum, but this year, I’m pivoting toward a specialized path: Smart Contract Development.

My goal is to deepen my understanding of this crucial Web3 component and eventually transition into a dedicated role as a smart contract developer. This shift aligns perfectly with my passion for blockchain technology and the ever-expanding possibilities of decentralized solutions.

Looking Ahead

2025 is shaping up to be a pivotal year for me, full of learning, building, and growing. Whether it’s mastering new skills, developing impactful projects, or pursuing career aspirations, I’m excited for what lies ahead.

To all my fellow developers, dreamers, and innovators—let’s make 2025 a year to remember!

What’s on your 2025 roadmap? Share your journey and join the conversation!

DEV Community: Rohit Purkait

What If the Blockchain Could Judge Your Bluff Without Seeing Your Dice?

The problem with putting hidden-information games onchain

FHE turned out to be a very good fit for the game

The weird part: checking a bluff without revealing the dice

What stays private and what stays public

Why I didn't just use a server

I also built a completely offline practice mode

The game is still intentionally simple

What building this changed for me

Try bluffing against the blockchain

I built TraceGate because my AI agent demo passed, but the traces told a different story

The problem

What TraceGate checks

The architecture

A build issue I hit

The workbench

Judge test mode

What I learned

What I would build next

Final thought

Every AI-built site looks the same, so I built a skill that locks taste before any code is written

Taste first, code second

The part where I failed

Install

codeswithroh / tastemaker

A Claude Code skill that grounds AI-generated UI in real reference images and a persistent per-developer taste profile, instead of generic AI-slop defaults.

What this is

Why AI UI all looks the same

What I learned

Understanding Flow’s Lending Protocol Architecture

A Beginner Friendly Guide for Web3 Developers

1. What Is a Lending Protocol?

2. How Existing Protocols Handle Liquidations

Example: Aave

3. Flow’s Architecture: Two Layers Working Together

3.1 Flow Credit Market (FCM)

3.2 Flow Yield Vaults (FYV)

4. How Flow Handles Liquidations Differently

Minimal Liquidation

DEX First Execution

Multiple Small Adjustments

5. Why FYV’s Automation Matters

6. Key Takeaways for Developers

Lending protocols can be redesigned to be more user friendly

Automation is becoming essential

Deterministic liquidation improves user trust

7. Summary

Adding Telegram Notifications to Your Application: A Step-by-Step Guide

Why Telegram for Notifications?

Step 1: Create a Telegram Bot

Compiling 2025: My Roadmap for the Year Ahead

New Skill: Embracing Web3

Side Projects: Building for the Community

Sepolia Faucet

Decentralized Identification (DeID)

Career Aspirations: Shifting Focus to Smart Contracts

Looking Ahead

codeswithroh
/
tastemaker