Fórum Stacks Forum

Good read!! Looking forward to integrate this into Stackstream as we have earlier discussed please everyone should check what we are building follow on X @Stackstream0X

Hi Stackers! A space was hosted today for the upcoming TC Meeting. Adding the notes here. If you weren’t able to join, please reply here with your thoughts so I can add them to the agenda for discussion. Thanks! Spaces Notes below Q3 TC Presentation Preview Macro markets : Crypto had a difficult quarter — Bitcoin ETF net outflows in July led to a major downturn, with slow recovery since; the Clarity Act vote impacted markets on the day of the call Endowment planning : The Q2 report had planned for a Stacks bear case of 10 cents — the price came close, validating conservative treasury management STX/BTC markets : Covers the Nakamoto hard fork launch enabling Bitcoin staking, leading to the Genesis Bond Bitcoin bonds lock STX for 6 months, reducing circulating supply and restricting net selling — a positive structural signal Genesis Bond retro : Covers Bond 1 results, lessons learned, and what Bonds 2–4 will look like Future initiatives : Privacy, agentic, and other ecosystem directions Community Feedback Shared DeFi growth incentives : Community is looking for more DeFi incentives to put capital to work Content creation grants : Requests for grants specifically targeting creatives and content creators More individual Highlights: Requested more frequent IRL events and meetups to help onboard new users, provide networking opportunities, and increase Stacks visibility internationally Called for a dedicated focus on retail engagement, beyond the institutional track; highlighted ga

For most of Bitcoin’s life, the story has been simple: Buy it. Hold it. Wait. But what if Bitcoin could actually work? Not just in DeFi loops. Not just in yield farms. But in the real economy — funding real businesses, moving real invoices, solving real cashflow problems. That’s the experiment I’m running with FlowFi-BTC. What is FlowFi-BTC? FlowFi is a tightly scoped pilot exploring how sBTC can be used for short-term real-world business financing (invoices, receivables, and similar needs), with transparency and on-chain tracking. This is not a massive protocol launch. This is not vaporware. This is a small, intentional experiment to answer a simple question: Can sBTC move from being productive in DeFi… to being productive in real life? Who I’m Looking For I’m currently looking for two kinds of people: 1. sBTC Capital Providers If you hold sBTC and you’re curious about putting a small amount of it to work in a real-world pilot (with clear terms and transparency), I want to hear from you. 2. Real Businesses If you run a registered business and have genuine short-term financing needs (invoices, school fees cycles, inventory, receivables, etc.), and you’re open to being part of an early pilot, let’s talk. This is intentionally small. The goal is learning, transparency, and proof — not hype. Why This Matters Stacks is building the rails for Bitcoin-native finance. sBTC gives us programmable Bitcoin. But rails mean nothing if we don’t test them in the real world. Someone has to r

This is really interesting, especially the onchain STARK verification and the numbers you shared. We’re actually already building a STARK based version of Stacks Shield to compare the tradeoffs against our current zkSNARK approach, particularly proof cost, verification cost, security assumptions, and post-quantum resistance. The fact that you’re already getting a STARK verified directly in Clarity makes this especially relevant. I’ll definitely try out the testnet and share some feedback. I’d also be happy to connect and compare the implementations and test what you’ve built around STARK verification on Clarity.

(post deleted by author)

Really appreciate this, Sam. I think the approaches could complement each other really well. The idea of Privara using Stacks Shield as an optional private settlement layer is especially interesting. I’d definitely be up for comparing the architectures and exploring how private intents could interact with shielded settlement. Also interested in the ZK direction around proving intent properties without exposing the underlying instruction. Would be great to connect and experiment together.

Hi folks, new member here, looking forward to the discussions. Thanks for having me!

Hi, jumping in because we’ve been working on the same problem from a different angle. zkStacks is a shielded pool for sBTC. Notes, commitments, nullifiers, same general shape as yours. The difference is where the proof gets checked: ours is a STARK verified in Clarity, on chain, in one block. No external verification layer, no aggregation root. Testnet is live if you want to poke at it: testnet.zkstacks[dot]com The reason it’s possible is the proof system. STARKs are hash-based, FRI and Merkle openings, so the pairing primitives Clarity doesn’t have aren’t ones we need. Current costs: 306 KB proof ~53% of the tx runtime budget 29% read count, 27% read length SIP-034 mattered a lot here. Per-dimension resets mean eating one dimension is much less antisocial than it was when we first measured. One thing that we already checked: we tried Poseidon2 in Clarity and it came out around 9,300x keccak256. Transcript hash is keccak now, Poseidon stays in the circuit. Proving runs in the user’s browser. We don’t host a prover, since whoever runs one can spend the notes that pass through it. Currently we developed it with a mocked sBTC token, but it supports any SIP-010 tokens. Code isn’t public, so the testnet app is where we’re after feedback. Open to connecting either way.

Privara is a privacy-aware payment protocol for SIP-010 assets on Stacks. The present goal is intentionally narrow: allow someone to receive a payment without exposing their normal Stacks wallet as the onchain settlement destination. A sender can still pay using the recipient’s normal Stacks address. Privara resolves that recipient’s registered privacy keys and derives a fresh one-time address for the actual payment. The deployed system is live on Stacks mainnet and currently supports sBTC. Why Privara? Suppose Alice regularly pays Bob in sBTC. Without Privara: Alice → Bob's known wallet Alice → Bob's known wallet Alice → Bob's known wallet Anyone inspecting the chain can trivially associate those payments with the same recipient. With Privara: Alice → fresh address S1 Alice → fresh address S2 Alice → fresh address S3 Bob controls all three addresses, but his normal wallet is never used as the settlement destination. The sender still knows they are paying Bob. The blockchain still exposes amounts and transaction timing. Privara M2 is specifically about reducing recipient-address linkage at settlement , not providing full transaction anonymity. How it works 1. The recipient creates a Privara privacy identity The recipient generates an independent random privacy seed locally. From that seed, Privara derives two secp256k1 keypairs: a spending keypair p / P a viewing keypair v / V Only the public keys P and V are registered onchain against the recipient’s normal Stacks address. T

Privara is a privacy-preserving intent routing protocol for Stacks. The goal is to make it possible for users and applications to execute SIP-010 token transfers without requiring the initiating wallet to directly submit the final transfer transaction itself. Over the past several weeks, I’ve taken Privara from its initial testnet protocol implementation to a working mainnet protocol with an SDK, relayer infrastructure, developer documentation, a reference application, and real-user testing. This post covers the completed work, how the protocol currently works, its privacy assumptions, early mainnet validation, and how developers can begin integrating it. What Privara does In a normal token transfer, the sender directly submits a transaction that transfers an asset to a recipient. That creates an obvious relationship between the wallet initiating the transaction and the resulting onchain action. Privara introduces an intent and relayer layer between those two actions. Instead of directly submitting the final token transfer, the user creates an authorization describing what should happen. Privara then uses commitments, encrypted intent data, nullifiers, and a relayer to execute the authorized action onchain. At a high level, the flow is: The user creates a private transfer intent. A commitment representing that intent is generated. The commitment is submitted onchain. The encrypted intent information is delivered to the relayer. The intent is revealed and validated. A nullifie

Privara is a privacy-preserving intent routing protocol for Stacks. The goal is to make it possible for users and applications to execute SIP-010 token transfers without requiring the initiating wallet to directly submit the final transfer transaction itself. Over the past several weeks, I’ve taken Privara from its initial testnet protocol implementation to a working mainnet protocol with an SDK, relayer infrastructure, developer documentation, a reference application, and real-user testing. This post covers the completed work, how the protocol currently works, its privacy assumptions, early mainnet validation, and how developers can begin integrating it. What Privara does In a normal token transfer, the sender directly submits a transaction that transfers an asset to a recipient. That creates an obvious relationship between the wallet initiating the transaction and the resulting onchain action. Privara introduces an intent and relayer layer between those two actions. Instead of directly submitting the final token transfer, the user creates an authorization describing what should happen. Privara then uses commitments, encrypted intent data, nullifiers, and a relayer to execute the authorized action onchain. At a high level, the flow is: The user creates a private transfer intent. A commitment representing that intent is generated. The commitment is submitted onchain. The encrypted intent information is delivered to the relayer. The intent is revealed and validated. A nullifie