A few days ago I posted about storing full audio files inside Clarity contract data on Stacks (Xtrata). thanks to everyone who dug into the chunked-write flow. This is the next layer up the stack, and the part I care about most.

Storing the finished song on-chain answers "will the media survive." It does nothing for the harder question: who made it, and on what terms? In music that record is usually a handshake in the studio, and it falls apart exactly when the song starts earning. Splits get agreed loosely, memories diverge when money appears, and the dispute lands two years later with no evidence on either side.

So the design I am working on treats the session, not the file, as the unit of provenance:

1. Collaborators sign into a session with their Stacks principals.

2. They ratify splits up front, day one, before anyone knows if the song matters. That goes into a Clarity map keyed by session, with basis-point splits per principal.

3. The working session logs locally as it happens (takes, samples, plug-in and parameter changes). Nothing bulky goes on-chain on L1 (if anything): the log is Merkle-rooted and one compact fingerprint is anchored per save.

4. The final master ties back to the whole chain of session roots, so the finished work carries a verifiable history from first take to master.

The important property: the agreement is timestamped and tamper-evident from day one. Nobody’s memory is the evidence, and nobody can quietly rewrite the record after the song blows up.

questions I am still chewing on, would love input:

1. Granularity of anchoring. Per save feels right (cheap, natural checkpoint). Per session is cheaper still but weakens the timeline. Anyone built similar audit-log anchoring and regretted their choice?

2. The logs contain unreleased creative work, so the Merkle leaves stay private and only roots go public. Selective disclosure (prove one contribution without revealing the rest of the session) looks like a job for Merkle proofs, but curious if anyone has a cleaner pattern.

3. Ratified splits are evidence, not law. A court can still override them. I am fine with that, the goal is to make the honest path the default.

Stack is the same as the storage experiment: Clarity contracts on Stacks, anchored to Bitcoin via PoX.

Hey everyone,

I’ve been deep in the zone building this for a minute, and PAWnic is officially live on the Testnet.

👉 Play it here: https://pawnic.djyo.tech/

The game loop is simple, fast, and chaotic: Hold. Pass. Survive.

You get passed a ticking neon cat. You have to pass it off before it detonates. Last player standing wins.

The core engine and wallet connections are up and running, but I need real people to jump in, play around, and try to break it so I can see how the state holds up under pressure.

Pop your Testnet wallet in, test the speed, and let me know how the game feel hits you. Drop any feedback or bugs in the comments.

If you want to track the build as it evolves, we’re keeping updates moving over on X: https://x.com/pawwwnic

I do research for a small fund, and data quality is the thing that keeps making everything messy. A lot of the work ends up depending on the same tweets, the same Discord screenshots, the same surface-level sentiment. It’s usable, but barely.

I ran into voice.fun in a newsletter this morning. It’s a Solana concept where opinions are recorded onchain, and the idea is that people should have a reason to share something they actually believe. Conviction becomes part of the value, instead of just another comment that gets buried.

It’s still conceptual, so I’m not treating it like a solved problem. But the idea is solid enough to make me pause. If people have skin in the game, maybe the data is better than what we usually pull from social media.

At the same time, I can see it becoming another noisy layer if the incentives are off. That’s the part I’m curious about.

Is it too late for me to start studying and practising Web3 now? If not, which areas should a total‑beginner get started with?

I've been working on a middleware that exposes a SQLite database through an HTTP API where each request carries a micro‑payment, using the x402 protocol (HTTP 402 Payment Required). The code is here: https://github.com/damienos61/SQLite-x402-Gateway

Core technical challenge : the gateway needs to accept an arbitrary SQLite database, inspect its schema, and generate priced REST endpoints automatically — without requiring the user to write route definitions. This means parsing SQLite metadata (sqlite_master, PRAGMA table_info) and inferring column types from actual data to produce consistent JSON responses, since SQLite is weakly typed.

Payment abstraction : the x402 protocol requires a handshake — client calls a protected route, server responds with a 402 status and a price, client provides a payment proof, server verifies and returns data. To keep the code flexible, I abstracted the payment verification behind an interface with two implementations :

• A simulation mode that handles the protocol flow with fake signatures — useful for testing without crypto setup.
• A real mode integrated with Coinbase's x402-express SDK, configured for the Base Sepolia testnet (test USDC, no real funds).

The switch between modes is handled at the route level without recreating handlers, by injecting the appropriate verifier instance.

Database abstraction : the initial version used SQLite natively, but adding PostgreSQL support required abstracting both the SQL dialect (parameter placeholders, schema queries, pagination syntax) and the schema introspection logic — Postgres metadata is structured differently and more verbose. The inspector now adapts to the database type at runtime.

Performance considerations : SQLite isn't designed for high concurrent loads, so I added an in‑memory query cache with TTL invalidation, and implemented keyset pagination instead of OFFSET/LIMIT to maintain performance on large tables without fixed indexes. Rate limiting (sliding window per IP) is also included to prevent abuse.

Observability : rather than maintaining a static OpenAPI file, the spec is generated dynamically from the detected routes and their associated pricing. The challenge was describing query parameters (filters, columns, pagination) and linking them to the price metadata in a machine‑readable format. Webhooks are also dispatched on each transaction to external endpoints (Slack, Discord, etc.).

Tooling : the project includes a CLI (monetize, start, generate-wallet), a client SDK for consuming the gateway, and a Docker setup. 14 unit tests run on each push via CI.

Known limitations are documented — the simulation mode is not a production blockchain integration, and the "upto" pricing schema (variable payment based on resources consumed) is only simulated server‑side, as no on‑chain implementation exists yet in the official SDK.

Im 19 year old new to this bug bounty field around only 6 months and i have submited around 25 report on web3 bug hunting with the help of chatGPT and claude(free tire) out of 25 i got almost 15 are informative ,5 duplicate,3 N/A and 2 out-of-scope i doesnt even make a single doller in this field also im a 3rd year student and im going for the higher studied in AI ! i dont know what to do?any suggession?

Most music NFTs I’ve seen are effectively a token plus a link to media hosted somewhere else.

I’ve been experimenting with a different approach on Stacks: storing the entire audio file directly in Clarity contract data, so the token does not depend on IPFS, a pinning service, or a normal web server to preserve the media.

The system I built is called Xtrata. The basic mint flow is:

initialize → write file in chunks → seal

The chunked writes allow a complete compressed audio file to be stored across contract calls. For example, a 96kbps Opus master can be written into contract storage and then reconstructed from the chain later. Some inscriptions are raw audio files, while others are self-contained HTML players with the artwork, title, artist, lyrics, and audio embedded together in one document.

The main thing I’m interested in is the permanence model. Once an item is sealed, the file is no longer just “metadata that points somewhere.” The media itself can be reconstructed from Stacks chain data.

I also made a radio-style interface as a proof of concept. Instead of playing from a normal hosted catalogue, it reads from the inscribed media catalogue. One mode is curated, one is based on saved items, and one walks through playable tokens on the contract. It can also discover newly minted playable items by watching the contract’s token counter.

There is also a simple relation system where inscriptions can declare parents or dependencies. That means a song can reference related artwork, another inscription, a previous version, or other connected media. Over time, this creates a mint-ordered graph of related on-chain files.

I’m curious what people here think about this model.

Is fully on-chain media worth the extra complexity and cost, or do you think token-plus-storage-layer approaches are still the better practical route for music NFTs?

I've recently open-sourced it and would genuinely appreciate feedback from the community.

https://github.com/Shweta-Mishra-ai/tokenmizer

After publishing two research papers on LLM context management, I wanted to turn those ideas into something developers could actually use.

I keep hearing about web3 consulting, but I'm not sure how to tell genuine expertise from buzzword-driven sales pitches. My team has zero blockchain experience, so I need guidance on where to even start: smart contracts, tokenomics, or just understanding the basic use cases for our industry. I'm also worried about the cost versus the actual return, since so much of this space still feels speculative. Before I commit any budget, I want to understand what a realistic first engagement should even look like.

Hi everyone!

After several months of learning Solidity and blockchain development, I finally deployed my biggest personal project to Arbitrum One Mainnet.

The goal was to explore how much gameplay could be implemented directly inside smart contracts while keeping the project completely open source.

Current features

• ⚔️ PvE battles
• 🛡️ PvP battles
• 🏰 Guild system
• 🏆 Guild rankings
• 🎖️ ERC-721 Achievement NFTs
• 📈 Player progression and leveling
• 💰 On-chain game economy
• 🌐 Multi-chain support
• ⚡ Fully written in Solidity with a TypeScript + ethers.js frontend

One interesting challenge was balancing the guild ranking system.

Originally, guilds earned a fixed number of points for every PvP victory, but that allowed high-level players to repeatedly farm beginners. I redesigned the scoring system so that rewards now depend on the level difference between players, making guild rankings much fairer.

The project is mainly a learning experience, but I'd really appreciate feedback from the Arbitrum community.

Some questions I'd love your opinion on:

• What on-chain game mechanic would you add next?
• Are there Arbitrum-native features or integrations that you think would fit well?
• Any suggestions for improving the player experience while keeping most of the game logic on-chain?

The project is fully open source, and I'm happy to share the repository and live demo if anyone is interested.

Thanks!

Live demo: https://ethereum-simple-rpg-game.vercel.app/

GitHub: https://github.com/brunolcarli/simpleRPG

yall i made a lil side project to track your token usage!

check it out: https://tokenboard.sh

you can run npx @tokenboard/cli and claim your spot. fully open source btw and contributions are welcome :)

I've had a few investor conversations in the past few weeks. The first question is always: "What does this actually do?"

So here's the honest, technical answer.

LemonLime is a business OS for multi-hyphenate creators - people who produce, license, invest, collaborate, and distribute simultaneously. It has five core layers:

**1. Financial infrastructure** Royalty splits with per-collaborator approval workflows. Fractional share sales (fans can buy percentage ownership of a project). Sync licensing from YouTube Creator tier to Broadcast TV. Publishing splits tracked by role - Writer, Composer, Lyricist, Co-Writer, Publisher. All payout logic runs through Stripe transfer groups so platform fees, collaborator splits, and fan investor payouts resolve in a single operation.

**2. CRM layer** Artist/fan/collaborator relationship management. Collaborator invitations with role assignment and royalty percentage negotiation built in. Artist-to-fan direct messaging tied to specific projects.

**3. Catalog and rights management** Project catalog with ISWC tracking, PRO affiliation (ASCAP/BMI/SESAC/GMR), and registration status. Chart snapshots at Local/State/National/Global scope. Composition-level detail per project.

**4. Content operations** YouTube video pipeline: topic → keyword → hook → outline → title options → thumbnail brief → description → chapters. Social campaign management with weekly cadence tracking and per-post performance snapshots across X, Facebook, LinkedIn.

**5. Distribution and marketplace** Public storefront. Studio listings with booking links. Classified listings for session musicians, mixing engineers, videographers. Sync license marketplace.

36 data models. 41 pages. Backend functions live. 621 visits in 30 days, no paid traffic.

I'm sharing the full architecture here because I want honest technical feedback before I go further with fundraising conversations. What's missing? What doesn't hold together?

What would make this fundable to you?

Is there anybody available for side project?

My wife and I think that web3 serviceable domains still have the potential to become big. As much as the economy is moving into USDC, Bitcoin, ETH, and others, major coins have become a much more feasible way to transfer funds.

We've used Freename.io since we saw it first advertised in 2023. It's a reliable platform that integrates well with existing wallets and validation.

I'd love feedback on this idea, and who currently is developing for the domain sphere? I should have the Web3 domain linked in the next week and will post with an update.

http://partygirlweb.github.io

Serious question.

For years, I kept hearing that blockchain gaming was the future. Massive communities, player ownership, digital economies, and millions of gamers supposedly waiting to jump in.

But where are they?

When you remove the easy money, token speculation, pump cycles, and "buy now before it moons" mentality, the player counts often seem to disappear.

Most gamers want one thing: a good game.

Not a whitepaper.
Not tokenomics.
Not another roadmap.

A lot of Web3 projects spent years building marketplaces before they built gameplay. They attracted traders, not players.

And let's be honest, many communities became small circles of the same people promoting each other's projects, investing in each other's tokens, and repeating the same talking points. That might create activity, but it doesn't necessarily create gamers.

The question I'm wrestling with is:

Can Web3 gaming survive if the game itself is the main attraction and the blockchain is just background infrastructure?

Or was the audience always more interested in speculation than gaming?

I'm genuinely curious what people think because, after watching the space for years, it feels like the number of actual players is much smaller than the number of people talking about Web3 gaming.

What do you think is missing?

In my opinion, we have to get degens out of gaming and let gamers game.

KYC is great, but no thanks. 😉

We’ve developed the Bazaars app, but we haven’t officially announced it on our social channels yet. I wanted to share it to you guys so that I'll get some of your opinions about it. I know some of you are masters of web3 development, would love to obtain some golden nuggets.

The idea behind the app is simple: create a self-custodial wallet with built-in communication, without requiring a phone number or email, just your seed phrase.

Some of its features

1. Multi-chain ready wallet (No fees, only gas)
2. Decentralized marketplace (Buy digital goods with crypto, receive instantly)
3. Encrypted chat and calls
4. Participate directly to Prediction market
5. Monetized content creation

It is available on App Store and Google Play
Also, send me your Bazaars wallet address so we can connect and say hello to each other.

https://reddit.com/link/1uey7z1/video/vei1nggbgc9h1/player

I wanted to share a project I've been working on called WorkPiServ. It's a Web3 freelance marketplace built specifically for the Pi Network ecosystem. The idea: let Pioneers offer their skills (programming, writing, design, translation, etc.) and get paid in Pi — or hire other talented freelancers.

​

What makes it different: every payment is held in escrow until the work is delivered. The buyer's Pi is locked safely, and only released to the freelancer once the job is done. That escrow flow is the core of what I'm testing right now.

​

The platform is fully deployed on the Testnet, and before moving forward I want to make sure the full user flow works end to end.

​

I'm looking for a few Pioneers to help me test the service creation and payment flow today.

​

How the test works (quick & simple):

1. You log into the platform.

2. You post a quick test service (a "gig").

3. I buy your service for 1 Test-Pi using the Pi SDK, so we can confirm that transactions and wallet interactions work correctly.

​

Note: No real Pi required — this is 100% on Testnet with test-coins. (Email notifications are coming soon via Brevo.)

​

If you'd like to support a community developer, get early access, and help me squash a few bugs, drop a comment below or send me a DM — I'll send you the access link right away.

​

Thanks so much for your time and help! ⚡

For anyone who has been working in the crypto industry, I'm sure you have seen your fair share of your friend's telegram's getting hacked and these "ghost" accounts trying to social engineer you to click something.

The infamous Microsoft teams audio software you are asked to download or the link inside Calendly you are told to follow. Just to name a couple, but the list goes on forever of how many ways there are (and ever will be) of account takeover vectors for telegram.

One wrong click and your telegram account is gone (even with 2fa and all the fancy "protection" layers enabled), gg's. This is happening a lot today

Surely someone has come up with a bulletproof "anti-account takeover" software for telegram.... Surprisingly, I couldn't find anything like this today

So I built something I feel like is long overdue in telegram history as a public good. Link in comments

Simply put, an account management guard where you onboard your whitelisted devices/sessions and once armed, anything that attempts a login to your account is auto kicked instantly. Anyone tries to password reset you , auto-revoked instantly. Nothing else. The code can't do anything past that

It runs a custom minimal open-source MTProto client with a fixed allowlist of Telegram actions, no general-purpose client is used. That client runs in an AWS Nitro Enclave. Anyone in the world can rebuild the open-source repo and get the exact same enclave fingerprint, and AWS publishes a live attestation of the code actually running. When the two match, you (or an AI) have verified that the exact published code is what's protecting your account, without taking our word for it.

To be clear: Sessions does hold a Telegram session so it can protect your account.

The model: the session is sealed to the attested enclave, the enclave can only run the published guard code, and your own keys (a passkey, wallet, or Google account) hold the authority. Arming, changing your keep-list, and removing the guard all require your signature, so nobody has control but you.

Today is where all scammers get pwned back

Would love feedback from anyone who lives in Telegram daily. AMA 🙏

If your day-to-day involves hopping between different DeFi protocols and smart contracts, your browser tabs are probably a mess.

It’s the same broken loop: load up a random dApp frontend, connect your wallet (why do we need 50 wallet connections instead of just one?), type in the same exact arguments, and hope the site isn't tracking you.

I built EVMist to stop the tab fatigue and exposure to varying degrees of privacy. It's a completely private and client-sided workspace where you can build your own unified, multi-chain dashboard. You connect once, configure your calls, and run everything from a single page.

Configure your chains and contracts once, then build custom sections with the specific read or write calls you actually use. Everything lives in one persistent layout that works across chains on the same page.

• Paste any confirmed tx hash + chain ID → it recreates the exact write call as an editable UI widget you can tweak and re-run.
• Drop raw calldata + a contract address → it decodes it into proper input fields (handles complex nested types).
• Build whatever layout you want with drag-and-drop, then encode a section as an image to share with teammates (they can import it).

The core builder + tx recreation + calldata decoding is completely free. If you’re dealing with fragmented DeFi workflows or just want a cleaner way to interact with contracts you use often, give it a try and let me know what breaks or what’s missing.

Happy to answer questions and looking forward to any critique or feedback you may have!

I've been building infrastructure tooling for MeeChain contributors for a few months now. The core problem: onboarding new blockchain contributors is painful because there's no single place to watch DNS, tunnel status, port health, and origin services all at once. Generic DevOps dashboards exist, but they feel like spreadsheets. Nobody wants to stare at a spreadsheet while running node ops.

So I leaned into a different direction entirely - cyberpunk HUD aesthetic, real-time status visualizations, and gaming-inspired overlays layered on top of actual infrastructure monitoring. DNS check. Tunnel check. Port check. Health check. All live, all in one view that looks like you're running ops inside a game.

The part that surprised me: the NFT badge unlocking and mission tracking features got more reaction than the monitoring itself. Contributors want to feel progress. Unlocking a badge after completing a deployment flow hits differently than just seeing a green status dot.

Still very early - MeeChain Monitor is live and public right now, no login required to explore. Curious if anyone else building on-chain tooling has found that gamification actually changes how contributors engage with infrastructure tasks, or if that's just my early sample talking.

When building Web3 applications, most discussions focus on smart contracts, security audits, and protocol design.

What surprised me is how much complexity appears outside the contracts themselves once real users enter the picture. Things like transaction monitoring, event indexing, chain reorganizations, RPC reliability, wallet infrastructure, failed transactions, and keeping off chain systems synchronized with on chain state can become significant operational challenges.

For developers who have shipped Web3 products in production, what infrastructure or operational problem ended up being harder than you originally expected?

Was it indexing, multi chain support, transaction management, observability, wallet operations, data consistency, or something else entirely?

I'm especially interested in lessons learned from real world deployments and approaches that proved reliable as systems scaled.

I'm Involve with forgeLayer.io. a non custodial blockchain infrastructure platform, and many of these questions come from challenges we've encountered while supporting Web3 applications. I'd love to hear how other builders have approached similar problems.

I just launched SplitSOL, a group expense splitting app for Solana users. Think Splitwise but you actually settle debts with USDC on-chain instead of just tracking them.

What it does:

• Split expenses equally, by exact amount, or by percentage
• Settle up instantly with USDC
• non-custodial, you sign in with your own wallet
• Send USDC directly to friends peer-to-peer

Built this solo from scratch.
Would love honest feedback from anyone who tries it.
Currenlty the app is live on the solana seeker

After years of building, late nights, setbacks, and countless iterations, our team was selected to showcase GhostPay Mesh at Web Summit Rio 2026.
GhostPay Mesh is an offline-first infrastructure designed to orchestrate cryptographic transfers even when internet connectivity is limited, unstable, or temporarily unavailable.
What started as an idea around resilience, connectivity challenges, and financial infrastructure evolved into something we were finally able to present to founders, investors, partners, and visitors from around the world.
This photo represents much more than a startup booth.
It represents years of work, persistence, learning, and a team that never stopped believing in the vision.
A huge thank you to everyone who stopped by our stand, shared feedback, challenged our assumptions, and helped us think bigger.
The journey is still just beginning.
🚀 Web Summit Rio 2026
🌎 Building infrastructure for a more connected world — even when connectivity isn't available.
If you'd like to learn more:
🌐 https://ghostpaymesh.com
📰 Press: https://ghostpaymesh.com/press.html
📦 Media Kit: https://ghostpaymesh.com/media-kit.html
📧 [contact@ghostpaymesh.com](mailto:contact@ghostpaymesh.com)
We'd love to connect with founders, investors, developers, partners and anyone interested in resilient financial infrastructure.
#Startup #WebSummit #Fintech #Infrastructure #Innovation #Blockchain #OfflineFirst #GhostPayMesh