Stacks Forum forum

quick update on privara: the product has moved quite a bit since the original post. we now support private payments to bns names, usdcx transfers, improved stealth-address flows, sponsored spending, and a much cleaner receiving experience around private identities and recovery. i’ve also moved privara to a new home at useprivara.xyz , which is now the main place to try the product and follow the project as it develops. still building, testing, and tightening the privacy model, but the experience is starting to feel much closer to what i originally wanted: share a normal stacks identity, receive through fresh private destinations.

Reviving this thread because I’m building exactly this gap. @raphasierra.id.block , thanks for documenting it so clearly, and @PeaceLoveMusic.btc for the USDC → USDCx route. What I’ve found so far: the sbtc SDK’s buildSbtcDepositAddress returns a plain P2TR address with the deposit and reclaim scripts baked in. Anything that can send BTC to a bc1p address can fund an sBTC mint. Exchange withdrawals already work (as Pillar described), and Transak’s widget accepts a custom walletAddress on the Bitcoin network. What’s missing is the glue: generating the address just-in-time, watching it for the incoming tx, calling Emily automatically, and showing a live paid → confirmed → minted status. I’m building that as an open-source embeddable React component plus a small backend (card → BTC → sBTC), with an all-in cost comparison across routes. I’m testing Transak staging this weekend and will post what I find, including whether bc1p destinations are accepted. Two questions: Pillar team: did you settle on a flow since January? Would you be open to trying this as a design partner? Has anyone run Transak, Ramp or Banxa to a bc1p sBTC deposit address in production? Any minimums, fees or gotchas? I’m also planning to apply to this quarter’s Endowment grants with this, so feedback on what would make it useful for your apps is very welcome. Repo (WIP)

This Week’s News & Stories - Fri, 18 Sep 2026 View this on stackssnacks.com and subscribe to receive updates via email. Gm 👋 A week after launch, the Genesis Bond is doing exactly what it was built to do. Twitter tweet 😋 Stacks Snacks The first BTC yield from Bitcoin Staking is starting to trickle in . Bitcoin earning Bitcoin, powered by Stacks. The Genesis Bond marks Phase 1 of the Stacks Roadmap : bringing more BTC into the ecosystem. The next phases encourage Bitcoin to flow into apps and become liquidity for users across Bitcoin-native finance. As Alex Miller puts it: Bitcoin Staking is how people find Stacks, and Bitcoin-native finance is why they stay. Stack Sats is live: 3 BTC in rewards over the next 90 days for borrowing and providing liquidity with USDCx through Zest and Bitflow on Stacks. Curious how people are running the Stack Sats loops? Here are a few breakdowns from DeFi Warhol , Stacy Muur and Nick Research . 👀 Other Tasty Content Xverse Explore just leveled up : trade trending BTCFi tokens, catch Ordinals drops early, and discover Bitcoin utility, all in one place. Zest's Stacks Market just passed $13M in outstanding borrows , with sBTC, stablecoins, and STX all being borrowed. Bitcoin-native finance isn't one app, it's a whole stack : vaults, lending, market making, AI infrastructure, and stablecoins, all settling on Bitcoin. Happy staking 🟠 Stacks is a Bitcoin layer for smart contracts. It enables decentralized applications to use Bitcoin as an asset and s

Clarity WG notes, 2026-09-15 I missed this morning’s call (my apologies friens), so these are written after the fact from the async threads with Friedger and Ryan, who were both in it. Brice and Hugo, please add your updates in the thread. Clarity Node-level events (Ryan, SecondLayer) Working on new events emitted by the node itself: Clarity state changes (map and var writes) and contract-to-contract calls. Today indexers only see print events and post-hoc traces; this would make state and inner calls first-class. Not yet a grant, probably should be. A local prototype for indexing maps exists. Why it matters: indexing today has holes whenever a contract does not print faithfully. A function can print an event yet never actually write the map or var, or write without printing, and the indexer believes the print. The only fix today is fallbacks that re-read state over RPC, which gets expensive over time, and worse if you want full history and lifecycle. Node-level events remove the guesswork: the indexer sees what was written and who called what, not what the contract chose to say. The inner-call events are the bigger unlock. Several hacks already traced back to this blind spot: a transaction calls one contract, which calls another, and explorers and indexers only show the outer call. The inner call is invisible unless someone pulls a debug trace afterwards. Node-emitted contract-to-contract call events would make every hop visible as it happens, for explorers, monitoring and i

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

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.