The reason why @Coinbase Commerce doesn’t support self-custody $BTC baselayer payments is simple UXTO chains like Bitcoin lack the programmability necessary to meet the requirements of most merchants 1) Merchants don’t want to be exposed to crypto price volatility risk Ethereum and EVM chains solve this by being able to programmatically covert whatever crypto token is used as payment into a stablecoin like $USDC, when can then be optionally redeemed for $USD and sent to the merchant’s bank account UXTO-based chains like $BTC lack the native programmability to convert their native asset into stablecoins onchain, so a custodial solution is required 2) Merchants don’t want to deal with manual burden of resolving incorrect payments (eg: underpayment) Ethereum and EVM chains solve this by being to programmatically reject payment with incorrect payment amounts This is literally a single line of code in a smart contract (require payment amount == invoice amount, otherwise revert) UXTO-based chains like $BTC lack the native programmability to revert payments based on amount, so a custodial solution is required — Net result is that Coinbase made a calculated decision that the overhead/friction/cost of supporting baselayer $BTC payments was simply not worth it Payment processing for self-custodial wallets is challenging, it’s not nearly as a simple as just giving a customer an address to pay into, they will fuck it up, it needs to be idiot-proofed Can lightning fix this for $BTC? Possibility, but there’s a great deal of friction today in terms of managing inbound/outbound liquidity and channel rebalancing Lightning also means you can support one additional asset, $BTC, while integrating with EVM chains means you can accept hundreds to thousands of crypto-assets (including stablecoins and $WBTC) and get paid directly into your bank account programmatically if you desire That said, I hope Lightning improves enough to make it a realistic option for merchants to leverage