Ya, I see this making sense because of the public key in the Stacks address that could be used in a Bitcoin address (I believe for P2PKH, but I wonder if it’s possible to wrap into a Taproot compatible one). A lot of the heavy work would be on the side of the wallet and make sure they’re aware of it I believe.
3 Likes
Concept ACK (in the Bitcoin core repo, to ACK is to agree with the proposal), from users perspective.
If a user only needs to interact with a BTC address, will reduce massive frictions. Cannot see much downside tbh.
2 Likes
Thanks for writing this up! This is a great proposal. It would improve wallet and onboarding UX a lot.
I think this would require some changes to the Clarity side of things. The principal type will need to support Bitcoin addresses as well. Maybe one of the core devs can chime in on this.
5 Likes
Having the same address type for different asset types prevents accidentally losing assets. This removes friction, “merges” ecosystems, and potentially equips Bitcoin addresses with BNS?
I personally really like this idea very much, but what happens to Stacks in that case? Can the asset be used for gas fees? Or only sBTC be used?
Apologies if this second part doesn’t quite fit here, but it’s on my mind.
I see the benefit unlocking the Bitcoin Economy, perhaps this is due to my limited understanding sBTC will be used for DeFI not so much for purchases as many view it as NGU tech/asset. I can certainly see STX being the spendable asset though, how do we promote this part of the offering?
1 Like
I made a prototype wallet app that allows you to use sBTC with native segwit bitcoin addresses instead of Stacks addresses. I posted a video demonstrating its usage on X:
https://x.com/larrysalibra/status/1895787738877841638 (or alternatively on youtube)
Source code is available on github
You can try out the app here (desktop chrome with xverse or leather extensions only): https://sbtc-with-btc-addresses.vercel.app/
One way to approach this in the short term is to make stacks addresses an implementation detail. Show users native segwit bitcoin addresses and convert them to stacks addresses “under the hood” when making layer 2 transactions.
Exactly. The world we want to end up in is that every bitcoin wallet checks addresses in its wallet for assets on both layer 1 and layer 2.
Yes! The bitcoin ecosystem is one of layers.
There’s a more detailed thread about this. Personally I think fees will need to be paid in sBTC to make the user experience ideal. There are a number of ways to do this. One way is to transparently convert the sBTC to STX “under the hood” in some form seems to be the way to do it.
1 Like
Think we can add this proposal to the product roadmap
so if i understand the intent here - rather than ask wallet (etc) maintainers to provide this address translation, you’re suggesting this be a native feature of the stacks blockchain?
it’s an interesting idea to be sure, but the devil is in the details - there are a lot of codepaths/rpc endpoints that are predicated on the current stx address format (i remember the original suggestion, so lol that we’re here now!).
from a code standpoint, i don’t see this as something difficult to achieve - but it might break existing third party applications that rely on the rpc responding specifically.
maybe the code changes could determine first if the address format is stx or btc, and then respond accordingly?
i’m thinking of something like this specifically: stacks-core/docs/rpc/openapi.yaml at master · stacks-network/stacks-core · GitHub
where if you want the balance of stx tokens, but you supply a btc address it may not return the value you’re expecting.
i like the idea though - i’d be in favor of starting a SIP sooner rather than later, particularly since it’s not consensus breaking.
3 Likes
This is a fantastic initiative from Larry.
From a user’s perspective, the fewer steps I need to take and understand, the easier it is for me to use a product—Larry’s proposal directly addresses this. Everyone already has a Bitcoin address, so let’s look at some key facts:
Bitcoin Owners: 106 million
Daily Bitcoin Users: 400,000
Bitcoin Wallets: 200 million
Bitcoin Traders: 53 million
Daily Bitcoin Transactions: 270,000
Americans aware of Bitcoin: 89%
Americans who own Bitcoin: 22%
Now, imagine the impact if we enable Bitcoin-native SegWit addresses (bc1) for sBTC—transactions would feel seamless and familiar.
And if we talk about market potential for STX… well, I’ll leave that to your imagination.
Great proposal @larry, efforts working towards better interoperability are important.
I am concerned about the non-standard derivation path usage this would entail, though. These bitcoin addresses belong to the m/44'/5757' chain.
Hardware wallets—at least Ledger—lock down their apps to only sign on the respective SLIP-0044 defined paths. This proposal would either need to accept that limitation, or find ways around it. Whether that’s lobbying hw wallet manufacturers to make exceptions, or publishing new apps that handle multi-chain concerns etc
2 Likes
Technically, it is just a different encoding. We don’t need the public key. All addresses can be converted. However, stacks only has two types singlesig and multisig. While bitcoin has legacy, segwit, etc . So we need to agree whichbbitcoin address type should be map to the single sig stacks address.
With stacking pool, we had the confusing that some pools used legacy, some used segwit.
Currently, it makes sense to use native segwit. However, bitcoin users with legacy addresses are left out.
With the mapping, we are loosing a portion of the verifiability of the transactions and smart contracts if we rely on tools that transcode addresses in transactions and contracts for us. Next step from transcoding would be compilers.
We are also creating some confusion about utxo models and account models. While my bitcoin address has been replaced by a change address on bitcoin, my bitcoin address on stacks is still the same. A solution could be to use smart wallets/account abstraction on stacks (some WIP here Add sponsored sbtc transfer by friedger · Pull Request #25 · friedger/Smart-Wallet · GitHub).
Users would need to learn what bc1234.. .amm-dao mean, what smart contracts on bitcoin L2 are.
2 Likes
I think it should be a native feature of the stacks blockchain. That seems like a big political process and involves a lot of implementation details I’m not familiar with, so in the meantime wallet providers (or dev tools) could handle the translation.
I assume there’s a this could be done in a backwards compatible way. Like having a new version of the RPC endpoints that use bitcoin addresses.
Imagine deploying smart contracts to bitcoin addresses.
We used to use 0 cointype and only changed to 5757 “relatively” recently.
This is a great point. We can probably get Ryder on board with whatever we decide since 3 of the founders are posting on this thread already, so that’s one hardware wallet. As is @yukan from Xverse.
Just thinking outloud here: another ID is to stick with 5757 and “designate” it as the path for multi-layer bitcoin support.
Do you think it would make sense to separate the discussion of the derivation path from the address format?
Every stacks (single sig) address has 1 legacy bitcoin address and 1 native segwit address. How legacy addresses are left out?
I think that ship has already sailed. Correct me if i’m wrong (@yukan) but I think Xverse reuses the same bitcoin address. Ordinals and runes strongly encouraged that behavior.
And to be clear, your bitcoin address isn’t replaced by a change address, it’s replaced by a new unused address. The change address holds the change utxo, but the next address you see when you click receive in a bitcoin wallet that “properly” implements the utxo model is a new, unused address. While I fully support the privacy improvement of this model, it is convention, not consensus in Bitcoin.
You want wallets to support both addresses as one account? I am Alice and use a legacy address, I share it with Bob. Bob enters the legacy address, the wallet converts to STX address, and then what is displayed to Alice? The legacy address or segwit? Users would need to make a choice if both are supported. For simplicity, I suggest to use just one.
I want wallets to support only one type of address. You said:
I was responding to that - someone that wanted to use a legacy bitcoin address to receive sbtc could (though I can’t think of an example of why they’d want to). So they aren’t “left out.” I might have misunderstood you
If Alice wants Bob to send her money and use a legacy address (for whatever reason), she gives Bob the legacy address, the wallet converts it to the STX address (we’re assuming the current state of no stacks core support for bitcoin addresses) and makes the transfer. Alice’s wallet wouldn’t be able to tell which one of the 3 possible addresses (legacy, segwit, stx) were used to send the SBTC to so it’s up to the wallet how to display it.
Until which time stacks core internally supports btc addresses, a wallet might have an edge for sbtc transfers and (for example) display the native segwit address and then have a popover info box that shows the equivalent stx and legacy btc addresses. I don’t think it’s very important to expose the legacy btc address option or to really encourage it though.
I agree it is something that requires careful consideration so as not to confuse users.
This proposal has strong marketing and financial potential. While technical feasibility requires further analysis, the perceived tax advantage for U.S. users could be a key differentiator.
The Lightning Network (LN) is often viewed as non-taxable when moving BTC from L1 to L2, as users retain control (lnBTC = BTC). A taxable event occurs only when lnBTC is spent. Similarly, moving BTC to Stacks’ sBTC (and back) likely has identical tax treatment. However, user perception matters: if L1↔L2 transfers appear seamless (e.g., same wallet address), it reinforces the idea of a non-taxable event, even if UTXO/accounting models differ technically. For most users, the wallet is the accounting system.
Most chains (e.g., Ethereum’s custodial wrapped BTC) convert BTC into a new token, triggering a taxable event. By contrast, Stacks’ non-custodial sBTC could appeal to long-term Bitcoin holders seeking yield without an initial tax liability. (They still have to pay tax on income). This proposal aligns with that demand, blending perception and reality to position Stacks as a tax-efficient L2 for Bitcoin.
1 Like
If that’s the case then converting BTC to sBTC (a different token on a different chain) would also be a taxable event.
Obviously, “taxable events” depend on the tax laws within your own country, but I’m of a mind that moving bitcoin to a L2 token that’s represents bitcoin should not be a taxable event.
1 Like
Perhaps there could be more tax clarity if Stacks went further then what LN does: instead of sBTC having a separate Stacks address, it is has native segwit bitcoin addresses (per L Salibra) and keeps the symbol BTC when bridged. sBTC is not needed and just makes it look like wBTC, cbBTC et al.
LN does a good job of keeping BTC looking like BTC even though it is lnBTC. The wallet would handle the logistics out of sight of the user and also show this BTC as another address alongside their L1 BTC. The wallet would block L2 BTC from being sent accidently to an L1 address without including the peg out to L1 as part of the process.
I think LN would have been better off not having a separate address system. Maybe segwit was not available in the early design stage?
Would change of the symbol sBTC to BTC make favorable tax treatment more likely? Probably.
The IRS is clear that wrapping taxable. Here’s a pretty good AI breakdown of current understanding.
Thought Process from AI
Answer:
The tax treatment of moving BTC to Stacks’ Layer 2 (sBTC) is not definitively settled by the IRS, but based on current guidance and technical details from the search results, here’s the analysis:
Key Factors
- sBTC’s Design:
- sBTC is a 1:1 Bitcoin-backed asset on Stacks, designed to enable decentralized movement of BTC between Bitcoin L1 and Stacks L2 (Stacks FAQ).
- Unlike custodial wrapped BTC (e.g., wBTC on Ethereum), sBTC is non-custodial, meaning users retain control of their BTC during the process (sBTC.tech).
- IRS Guidance:
- The IRS generally treats crypto transactions as taxable if they involve a disposition (e.g., selling, exchanging, or transferring to a new asset).
- Custodial wrapping (e.g., BTC → wBTC) is widely considered taxable because it creates a new token. However, non-custodial bridging (like sBTC) is less clear.
- Perception vs. Reality:
- Perception: If sBTC is viewed as a “representation” of BTC (similar to Lightning Network’s lnBTC), users may assume no taxable event occurs (Stacks FAQ).
- Reality: The IRS has not explicitly ruled on non-custodial L1→L2 transfers. However, because sBTC exists on a separate blockchain (Stacks), the IRS could argue that minting sBTC constitutes a disposition of BTC, triggering a taxable event.
Comparison to Other Solutions
- Lightning Network (LN): Moving BTC to LN is often seen as non-taxable because LN operates as a payment channel (not a new token).
- Ethereum’s wBTC: Custodial wrapping is taxable because it involves surrendering BTC for a new ERC-20 token.
I don’t believe this is doable. As a L2 token it runs on a different chain and calling it BTC would be a misrepresentation. Not only that, it would cause massive confusion.
As for the Lightning Network, it operates with native Bitcoin. It’s not a new token. Native Bitcoin is locked into the network which enables the opening of peer-to-peer channels to facilitate transactions between parties.
100% agree here.
BTC on the stacks network
BTC on the lightning network
BTC on the L1 bitcoin network
they are all BTC.
No it wouldn’t. This is already how the existing financial system works. Your USD in paypal has entirely different risk characteristics than USD in a federal reserve account. They’re different tokens. But we generally call them the same thing. (People sometimes talk about “eurodollars” for USD held in non-US banks…they have different risk characteristics.
There’s already precedent for this in crypto. We called USDT “USDT” no matter which L1 or L2 it is on. USDT on tron is an entirely different token than USDT on etheureum.
1 Like
I get your point, but there’s a reason other Bitcoin L2s like Liquid (LBTC) and Rootstock (RBTC) - not to mention wrapped Bitcoin (WBTC) - use identifiers with their token tickers, and that’s to prevent confusion when looking at coins on exchanges or apps like CoinMarketCap etc.
Beyond just the label, at the root of such confusion would be the address system itself. Each chain uses completely different addressing systems. Now, if Stacks was able to somehow enable Segwit Bitcoin address format - for funds both in and out - then that would certainly help.