Proposing Bitcoin Addresses for Stacks

Community
#22

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

  1. 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).
  1. 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.
  1. 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.
#23

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.

#24

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.

3 Likes
#25

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.

#26

Join us on this week’s SIP call with special guest @larry, as we discuss this proposal.

Date: Fri. 2nd May 2025

Time: 9am ET / 13:00 UTC

Where: Live on X - @DeOrganizedBTC

1 Like
#27

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.

2 Likes
#28

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.

#29

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.

For video playback via DeOrganized: https://x.com/DeOrganizedBTC/status/1918281886473896106
For the SIP Call Segment Starting from 00:30 mins ~ 1:50:00
image

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.

Video Demo of sBTC transfer using BTC address: https://x.com/larrysalibra/status/1895787738877841638
Screenshot 2025-05-02 at 16.40.49

1 Like
#30

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!

8 Likes
#31

Thank you @larry

I am very excited about your proposal and to be able assist you.

Team work makes the dream work🙌

4 Likes
#32

Will be glad to get this SIP out

4 Likes
#33
#34

good…!

1 Like
#35

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.

2 Likes
#36

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

3 Likes
#37

Hi Larry, got some questions from today’s SIP call as we were talking about your SIP proposal, would you be able to share with the community some thoughts around this?
image

1 Like
#38

Sounds like the address is swapped client side and from the mempool back through the chain and infrastructure the change won’t even be visible.

Will need every wallet on board for this and coordinated for sure.

It seems like the big challenge here will be product change coordination, not a huge technical hurdle. Correct?

1 Like
#39

It seems a little more participation from the wallet providers would help this move along more quickly.

2 Likes
#40

Hi Larry,

I totally support this proposal, however, I am wondering if there is an even lower hanging fruit which could pay some dividends immediately.

Based on your proof of concept, can I get the Stacks address that will be used in the same account for Xverse/Leather for an existing bc1p or bc1q address?

I see that we can go from STX to Segwit, but I am not sure if 1) can do the reverse and 2) if we do will they actually match in the current wallets.

Could you clarify this?

Goal is to identify most active Ordinals Enjoyoors through on-chain data then airdrop them an Ordinal that tells them they have a claim on STX. Or otherwise just airdrop them something on STX they will see in the same account on those wallets.

#41

We can convert in both directions: Stacks address to Native Segwit address and Native Segwit to Stacks address.

If you take a bitcoin address from leather or xverse and convert it to a stacks address, it will only match the stacks address in current wallets if the wallets used the same derivation path to derive the stacks address as it used to derive the bitcoin address.

I believe that both xverse and leather use the bitcoin cointype derivation path for bitcoin addresses and the stacks cointype derivation path for stacks address.

If this is still the case, then without changes to the wallets, users won’t be able to automatically access them.

With small software changes, wallets could access such an airdrop. The main challenge (from what I’ve heard from wallet makers) is that Ledger prevents Ledger apps from accessing derivation paths for other coins. If one had such a wallet secured by ledger, the stacks ledger update would need to be updated so that it access the bitcoin coin type derivation path.

Correct.

Coordination is challenging but I don’t think we need every wallet onboard at all. I suspect many of the challenges can be mitigated unilaterally through wallet-side UI/UX. Working on a prototype that I hope will demonstrate this. Looking to have something to share around Bitcoin Asia (this coming week).

Initially not at all. Even if stacks were to totally switch to bitcoin address across the stack (ha!) and ecosystem including stacks-core, data aggregators and indexers could still get the same information separately for the stacks ecosystem by only including data collected from stacks nodes and apis. This data wouldn’t have any information about activity using the same bitcoin address on different layers or networks.

tripnmonkey: “How will impact backend infrastructure like Chainhooks?”

The initally wallet-only shouldn’t affect chainhooks, those such services could choose to also accept bitcoin addresses in their apis anywhere they accept stacks addresses. If that would lead to any confusion as to which layer (BTC L1 or STX L2) they should be interacting with, they could add a parameter to clarify that.

tripnmonkey: “How will this change impact existing apps that may be built around STX Addresses? Sites like Bitflow, Velar, Hiro Explorer,
Hermetica, Zest, etc?”

It depends on how they interact with users and addresses. If all of their addresses come via programmatic wallet interactions, wallets could automatically provide them with legacy stx addresses so that no changes are need. If they are asking for users to manually input addresses by typing or copy and pasting, they could either do nothing and expect users to continue to provide stx addresses or they could update their input fields to accept both and translate back to stx address under the hood.

1 Like