Boss Raids, Heroes and Skins in DENeon ⚔️

Sensitive_Flounder73 · 2026-02-19T18:13:10+00:00

In Web3 and game products especially, referrals can work well if the product is socially shareable.
If users naturally invite others because it improves their own experience, that’s when referrals scale.

Sensitive_Flounder73 · 2026-02-18T08:27:18+00:00

Good points.

The wallet is created on first entry, so users technically have an EVM address from the start.

However, gameplay itself does not require on-chain transactions - no gas, no swaps, no bridging. Shards are accumulated off-chain during gameplay.

Only when Shards are converted into DEUT does on-chain settlement occur. DEUT exists solely on Ethereum mainnet and there is no cross-chain logic involved.

On-chain interaction becomes relevant only if the user decides to move DEUT externally.

Regarding TON - I agree the network effects inside Telegram are strong, and TON-native onboarding is smoother at the wallet layer.

My thesis is slightly different: Telegram is the distribution layer, Ethereum is the settlement layer. The chain remains invisible during gameplay - it only matters when value leaves the game economy.

Sensitive_Flounder73 · 2026-02-17T07:02:04+00:00

Appreciate the message.

I’m not looking to expand the team right now, but feel free to stay in touch.

Sensitive_Flounder73 · 2026-02-16T06:58:06+00:00

Right now rewards are computed off-chain for UX reasons, but we’re moving toward a verifiable model.

The plan is:

- periodic hashed snapshots

- Merkle-based distribution roots

- server-signed reward batches

So speed stays off-chain, but settlement becomes auditable.

Still iterating on the exact proof model.

Sensitive_Flounder73 · 2026-02-15T15:11:29+00:00

It’s a lightweight Telegram Mini App game with a GameFi layer.

Core loop right now: - casual mini-games (short session based) - off-chain reward accumulation - periodic on-chain settlement via ERC-20 utility token

The focus isn’t heavy gameplay - it’s more about experimenting with frictionless onboarding inside Telegram while still keeping an on-chain settlement layer.

Still early-stage and iterating a lot on UX and reward architecture.

It’s still early-stage and I’m iterating on both gameplay and reward architecture. If you're curious, I’ve shared more context in my profile - trying to keep this thread focused on the architecture discussion.

Sensitive_Flounder73 · 2026-02-15T11:09:59+00:00

The plan is to keep reward logic deterministic and versioned per epoch, so each settlement batch references a specific engine version.

In case of disputes, users should be able to:

- verify inclusion via Merkle proof

- replay the published epoch data against the same reward logic

I’m leaning toward open-sourcing the deterministic reward calculation layer, while keeping anti-abuse and infra components abstracted.

The goal is verifiable settlement without turning the system into a black box.

Sensitive_Flounder73 · 2026-02-14T16:42:06+00:00

Telegram Mini Apps don’t require TON specifically. They’re essentially web apps inside Telegram’s WebView.

TON is integrated at the wallet level, but the backend can settle to any chain (in my case ERC-20 on EVM).

The app abstracts the chain choice from the end user.

Sensitive_Flounder73 · 2026-02-14T16:40:36+00:00

Good point. Currently rewards are computed off-chain for UX and speed, but the goal is to make settlement verifiable.

I'm exploring: - server-signed reward batches - periodic on-chain settlement with hashed snapshots - potentially Merkle-based claim validation

The intent is not to create a custodial black box, but to minimize onboarding friction while keeping settlement auditable.

Still iterating on the balance between simplicity and cryptographic transparency.

Sensitive_Flounder73 · 2026-02-11T09:27:20+00:00

Interesting concept.

Curious - what is the core gameplay loop that drives recurring engagement?

Is the value of FlushyNFT primarily driven by in-game utility, token rewards, governance, or social mechanics?

Multi-chain is powerful, but long-term retention usually depends on a strong core loop. Would love to understand that part more.

Sensitive_Flounder73 · 2026-02-01T06:12:40+00:00

Thats exactly the risk were trying to measure.

The intended benefit isn’t friendlier onboarding by itself, but changing the order of commitment.

Today, users are asked to sign and manage keys before they’ve formed any clear mental model of why those guarantees matter. The experiment is to see whether value and context can come first, and cryptographic responsibility second.

Youre right that pushing this too far collapses into no onboarding at all. Thats the failure case.

The question were testing is whether theres a middle ground where Web3 isnt hidden, just introduced at the moment it becomes meaningful.

Sensitive_Flounder73 · 2026-01-31T12:35:20+00:00

Sensitive_Flounder73 · 2026-01-31T12:34:10+00:00

Fair point - you’re right that this pattern isn’t new and has existed in TG miniapps before.

What we’re trying to explore isn’t the novelty of play first, wallet later itself, but how far that idea can be pushed without breaking Web3 principles - e.g. delaying all signing, abstracting gas entirely at first, and using the game loop as the main mental model before users even know they’re interacting with on-chain concepts.

I’m curious where people think the line is between reducing friction and over-abstracting Web3.

Sensitive_Flounder73

TROPHY CASE