At first glance, it looks like it's vulnerable to transaction malleability, though. Do you have a way to defend against the following attack?
That's a reasonable concern. It will be completely solved once OP_CHECKLOCKTIMEVERIFY is implemented in Bitcoin Core (refunds can then come from a timelocked output, instead of a pre-signed timelocked refund transaction). Until then, changes in Bitcoin Core 0.9 have made mutating transactions expensive enough that this should not be a huge issue (the attacker would need to mine the mutated transaction in a block). The alpha version of Mercury only allows trading with the Bitcoin Testnet, and before I open it up to real trading I'll have to be sure this attack is not viable.