It is multi-sig wallet that uses merkle proofs to authenticate public keys instead of storing them on chain. Clients are required to send public key along with list of hashes proving that it is present in a set described by hash stored in contract permanent storage. To authenticate the key contract has to chain-hash the list provided by client.

The main issue is that it consumes more gas validating proofs than it might save by not storing the keys. It can only pass 10k threshold after a couple of optimizations and gas workaround involving sending proofs with pairs of hashes already in cell, so builder creation is avoided.

Gas required to validate proof far exceeds gas spent on storage and lookup of the key in a dictionary. Sufficiently large number of keys, along with low number of confirmations is needed to make this method viable. I wish TVM had a cheap way to hash numbers from stack.

But gas consumption isn't the only problem...

There was no reason to accept list of signatures, because there is no seqno congestion. Accepting the list created small replay issue instead.

I mixed concepts of order expiration, and message expiration. User is forced to sign messages with long expiration times.

I also have not included contract address in signature. If one of the members is using the same key for personal wallet attacker may simply replay messages cross-contract.

But later I discovered a serious design flaw...

User needs to protect not only his private key, but he has to be sure that everyone else does too.

I did not started with assumption that one of the keys is stolen and is attempting to inflict damage. Increased number of keys that are authorized to execute contract actions makes it only more likely. Preventing such damage is one of the key reasons to use multi-sig. Without sufficient protections what's the point of using it at all?

External message handler, or rather letting contract to pay for processing the message creates unique challenge. Stolen key is indistinguishable from legit one until it launches at least a gas consuming attack. It is difficult to prevent it and to contain it the key has to be banned until its actions are confirmed. I made no attempts to limit resources that can be consumed by authorized key.

Due to all of this, I consider my submission rather useless.

But every other submission that I reviewed has exact same flaw. I guess no useful multi-sig was made.

Exploring the problem of collecting signatures on-chain I made another contract, way after contest. It's a personal 2/3 wallet. It blocks the key after accepting the message and waits for confirmation (or cancellation) from second key to send message out. Additional third key should be stored offline in case one is lost. It's in a way similar to password/OTP/backup MFA. This one at least can be used by a sane person.

Extending this technique it's possible to make personal multi-sig. One where person controls all of the keys, but attacker gained access to only some of those keys.

Consensus multi-sig, where person controls only a single key, and where attacker is just a minority of contract members remains unsolved.

I am do not have some production work experience with assembler, so I can't estimate a true quality of your asm code, but I think it's a really hard task to write assembler code by hand, so I want to express my respect for the work done ;)

If your implementation will become the fastest in this contest, then you are very cool hard developer at all!

Hello Chic, why haven't you provided fc code?
It's not possible to read assembler code for an application. As I see it wasn't written by hand but compiled from FunC, you just needed to provide the file, or reading is painful for me (maybe it's a personal thing, I'm not experienced in reading asm code)