2/3 multisig. It is small, but relatively sophisticated contract written in ASM. Original submission had one error in internal message handler. It bounced any message (except sent by contract itself) with unauthorized error.

After deadline:

Improved third key handling in external message handler.
Replaced internal message handler. Now pretending it isn't there unless message was sent by contract itself.
Replaced get methods. Now they are actually helpful.
Comments in ASM.
Simple examples.
Example bash implementation.
Detailed readme.

It is finished.

PS: I may change get methods, there is still room for improvement.

I would suggest working on user-friendly console application!

Quick question about your tests. If I understood right, you test every sequence of three consecutive queries. If some query leads to an exception, you don't print anything about it.

My question is:
why K1_MSG1 K2_MSG2 K1_MSG2 leads to error, but
K1_MSG1 K3_MSG3 K1_MSG3 leads to MSG3 being sent?

Also, where is K1_MSG1 K3_MSG1?

What happens is the first query will throw an error? Could it lead to an infinite replay of this first message?

UPD:
My bad. No problems with your contract.
I was worried by some reason about <{ SETCP0 ACCEPT nonce INT "code.fif" include PUSHREF SETCODE }>c but it is ok.

Another interesting fact is that the first message (if included both code and query) will be applied twice (the first time to update the code, and the second time to actually handle this message) and this is correct behavior.

It is an excellent short, but a fully functional smart contract.
It solves all known problems of a multisig wallet.

Some interesting ideas about its usage are also presented.
E.g. "third party protection service" looks quite promising to me.

It is quite hard to reason confidently about the correctness of raw TVM ASM code.
But the code is kept very clean and straightforward and looks good in general.
And it has a quite extensive testing suit.

I also like the idea of having a "fast path" for cases when two of the three keys are used interchangeably.

Internal commands are implemented as internal messages sent by smart-contracts to themselves.
It is an excellent idea, but I should note that this will lead to an unnecessary commission for message forwarding.
It doesn't look like a problem to me, as it is quite a rare operation, and such a decision simplifies the code.