@deweller Do you prefer unbridled open discussion on this here… or in the Github as issues. Telegraphing where I am heading with this… As an asset owner, my preference is to be able to not be forced to adopt Segwit transactions. If other asset holder’s and CP users (not me) want it - let 1000 flowers bloom. But I have unresolved issues with the topology of Segwit TX’s such that as an issuer and a Bitcoin user - they don’t notionally hold fungibility for me. So in short… I advocate any Segwit implementation be opt-in and refutable by issuer. A will-not-accept flag or explicit delineation be provided for. I don’t want that Counterparty at the protocol level imposes it wholesale on all users and token holders irrespective of any objections they may hold. That enforcement would be commercially incompatible with our own project’s use case of CP and a really frustrating and undesirable choice between two or three equally bad outcomes if CP protocol moves to a place I’m reticent to go to and follow. By two or three equally bad outcomes - Counterparty Classic (Pre-Segwit) forking or ERC-20 as a replacement… neither pathway is FTW as far as I can see.