More from the Serai developer:
The main issue is pipelining of the slatepack which needs signing to all validators. That should be done by placing it on the Tributary.
So we’d have to publish an unsigned TX to the Tributary with the slatepack, ideally with a small proof it isn’t spam.
The question becomes what proof to use for anti-spam (Tor PoW?) and adding a validator RPC to even receive such slatepacks.
Is this where Bisq required the collateral?
They go on:
The much easier, but also likely improper, solution would be to place the slatepacks on Grin itself.
If a user could publish the slatepack on Grin, the Serai flow would be trivial. My question would be how damaging it is to Grin (1 and 2) can a slatepack be sent to the receiver, the receiver signs, and the receiver publishes the TX?
I believe at least the original format required a round trip.
If there is such a one way format, and we can associate arbitrary data with an output, this likely becomes sufficiently trivial.