Ocnarb Here could be another potential version complementing your idea.
On-chain escrow use-case has been quite popular and there are many good enough solutions (ranging from simple two-sided simple trade, multisig to more complex ones). So the most basic one would be a smart contract that allows each side to deposit their amount of tokens, only when both sides are happy with the deposits, they can both trigger exchange, otherwise any of them can trigger a refund. Also we have pretty good DEXs that allows non-custodial wallet-to-wallet trades. So I think on the smart contract side, it probably makes sense to leverage existing solutions instead of creating a new one from scratch.
I think an interesting part where Streamr Network could come into play would be price discovery and aggregated trade book. Liquidity is probably one of the biggest challenges for any centralized and DEX exchanges. We are already seeing many platforms trying to combine or build on top of other liquidity pools. Because broadcasting all bid/asks on-chain would be too expensive, we need an off-chain solution that could be easily integrated into any system. One important thing to note is that good order books are composed of committed trades (until cancelled), so there is certain level of expectation that if you see X amount of tokens at Y price on the highest bid side, if you are the only one triggering a trade of an amount less than X, you could get at that price most of times.
An initial iteration on top of Streamr Network could be a simple broadcasting mechanism, without committing trades. Because streams in the Network will be quite cheap to create, there could be a stream dedicated to any pair combination of crypto coins/ERC-20 tokens/stable coin. So if I'm interested in DATA/USDT or DATA/BTC, I would list to those streams. The advantage is that you don't need to have enough demand or volume to create these pairs, differently from how normal exchanges and pools work. Let's take example of a non-custodial mobile wallet integrating this functionality. Ofc they would be subscribing to most of the streams on the backend to collect bid/ask data, so when an user searches for DATA/BTC, they can show something like last 7 days broadcasted bid/asks + incoming real-time ones. You cannot trigger a trade against any of those since they are not real committed trades. However, we could take a Tinder type approach. Once you see a bid that you are interested in, for example, you could broadcast a message back to the owner of that message (personal stream that the user on the other side is subscribed to). So similar to the swipe left of Tinder, the user who proposed the initial bid will be notified that someone was interested in their offer. If that person wants to still proceed, then the mobile app could trigger an escrow smart contract for the two parties and things would go on as usual on-chain escrow flow.
Ofc the above simple gossiping type broadcasting is not efficient and quite noisy, thought still no much different from LocalBitcoin solution used across the globe (peer-to-peer discovery and trading). Later iterations could be about automated order matching that wallet providers or third party engine could offer. When subscribing to all these streams, a third party could automatically match orders via many algorithms (first come first serve, lowest slippage, fill-or-kill 😃 etc.). Again these might be still not committed trades, but instead of someone going through the offers, there could be automated matching and alerting interested parties. So both bid and ask sides could simply broadcast what they would like and wait for the Tinder match notification -> enter into escrow or DEX trade if both agree. An even more advanced iteration would look like payment channel receipt commitment with signatures and Streamr Network for orderbook aggregation, so orders broadcasted are actually committed orders and trades could be triggered automatically if criteria match.
So those are just some ideas on the initial proposal, take it with a pinch of salt 😃