TapRay

@TapRayFi vs @tap_protocol TAP is closer to an asset protocol and programmable execution environment, while TapRay is a market-making and liquidity coordination layer built on top of Bitcoin asset protocols. TAP is an Ordinals metaprotocol for issuing and managing Bitcoin-native assets through inscriptions and indexers. It supports transfers, authorities, locks, sales, AMMs, staking, and other programmable actions. NAT is one ecosystem built around that stack. TapRay solves a different problem. We are building an RFQ liquidity network for Bitcoin assets, starting with RGB. Market makers quote directly from their own inventory, retain custody of their keys and funds, and compete to offer users the best price. TapRay coordinates quote discovery, inventory reservation, signing, and non-custodial settlement. This fits naturally with RGB, where asset state and transfer history are exchanged only between the relevant parties rather than published and globally indexed. Bitcoin sees the commitment, not the full asset data. This makes the system private by default at the protocol-data layer and reduces the amount of data the wider network must store and process. TAP vs TapRay - TAP defines asset and account state - TapRay coordinates liquidity, quoting, and trade execution - TAP uses inscription-based state reconstructed by indexers - TapRay currently settles RGB assets using client-side validation -TAP includes native trading primitives such as sales and AMMs - TapRay focuses on RFQs, competitive quoting, inventory-aware market making, and minimizing unnecessary information exposure Supporting TAP assets on TapRay could make sense later if there is enough user and market-maker demand. For now, we are starting with RGB because that is where we see the clearest liquidity infrastructure gap.