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.
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.
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.
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.
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.
That doesn’t prevent confusion, it increases it by increasing cognitive load.
Users have to know what these different tokens are. If they all are 100% interchangable/swappable assets then it would be more simple to call them all the same thing (same name). All exchanges and apps should endeavor to hide complexities that do not matter to users.
BTC on the Rootstock network (RBTC) and BTC on the Ethereum network (WBTC) or BTC on the Stacks network (sBTC)… they are all BTC and only the network where they reside is the difference. It would be easier for users to only have to understand and distiguish WHERE the BTC is going-to/came-from/resides-on… which network/blockchain. This is how USDT is handled and it seems it could be a good way to handle BTC “flavors” as well.
I see your point. So I guess the difference between these versions of bitcoin would be obvious when you came to deposit or withdraw, and were asked to choose which blockchain you want or need to use - as it is with USDt.
Thanks to everyone who joined the panel to discuss, give feedback, ask questions, and learn more about this SIP proposal.
-Thanks Haddy for being the coordinator “SIP Deputy” to help make it happen.
-Thanks Larry for taking his valuable time to creating this proposal to make Stacks even better, and feels more like operating on Bitcoin.
Next Step:
-Please continue to feedback & discuss about this proposal.
-Haddy will work with SIP author Larry to understand how he’d like to move the idea forward and provide support where possible.
Just wanted to post a quick status update for the community.
I’ve reached out to the wallets and some of the core team to directly gauge their interest, support and initial thoughts on this proposal. Everyone is generally interested in at least exploring this change. Directionally, it seems that it makes sense start with a initial proposal that is limited in scope such that it is something can be shipped without depending on getting changing into stacks-core.
As a next step, I’ll put together a draft SIP and then loop in authors from the ecosystem wallets and anyone else who is interested in contributing. I’ll post more in this thread when we have something.
Thanks so much for @Haddy for his support in moving this initiative forward!
Awesome! Excited to see this develop. I think it makes a LOT of sense to utilize Bitcoin addresses for Stacks. It aligns Stacks more directly with Bitcoin and helps abstract away the perception of being on different chains.
This seems like a step in the right direction, reminds me of a recent experience getting sBTC via bitflow in which the whole transaction and experience were neither straightforward or simple, it felt a bit misleading actually, nothing like using btc, and if regular users such as myself are to feel excited about sBTC and use it frequently then we definitely need smooth, effortless transactions that give a native-like feeling
