Two versions of MultiSig, one is bitcoin-style for external messages, another one works with internal messages sent through participants simple wallets, automatic DNS with pay-per use and possibility of changing storage fee, and a draft of simple asynchronous Payment channel.

The main aim of making those solutions was not exactly match the task but find the different, and probably better way to solve the problem. Feel free to comment, give a critics, I will be happy to discuss.

Semi-automatic DNS:
+ Manual deletion of expired domains.
+ Support for storing of a domain and its subdomains.
+ Arbitrary domain expiration time.
+ Support for error responses.
+ Ability to receive donations.
+ Ability to withdraw earnings.
- Manual cleaning via full scan is too expensive, this is not a suitable way to implement it.
- Owner check doesn't compare workchain_id.
- Lack of automatic partial resolving on function level.
- All dictionary keys are 256-bit, so there could be high storage costs.
- In set_records difference is substracted from storage, but it needs to be added.
- No update_time change in set_records and topup_domain.
- In some places udict_get? can be used instead of udict_delete_get?.
- Number of cells used by domain doesn't affect price.
- owners dictionary is stored, but not used.

> ACCEPT, sets current gas limit to its maximal allowed value, and resets the gas credit to zero. In other words, the current smart contract agrees to buy some gas to finish the current transaction.

You are definitely using accept_message for some other purpose (like 'I will not throw processing it').

You are counting confirmations wrong. I cannot understand yet what exactly that function will produce. But expression updating counter within loop remain constant.

I wonder how I did miss this interesting DNS resolver before. While not conforming to specifications, the fee algorithm is very interesting. However, some issues arise due to very advanced magical witchcraft going on in this contract:
- there is no required resolver dns_resolve method in the contract, it cannot be used as contest-standartized dns resolver
- udict is used for domain category instead of idict, owner stored in category 1 instead of -2 (blocking: may prevent expected usage of resolver)
- fee calculation does not account at all for cell references: neither the magic udict_merge function does ensure that there are zero references neither it accounts their size: it is possible to put tons of data in referenced cell and drain contract balance fairly quickly
- add_domain is not resistant to dust attacks - there is no initial fee except for gas charges for domain registration
Continued in #issue8900

Continuation of #issue8899
- no gc at all unless owner asks - involves fairly crucial external dependency for contract health
- comments in the code are mess and are entirely misleading
- error replies do not have high order bit set (which is required as per smc guidelines)

Yeah, i find it respectable that you managed to work out 3 different non-related contract times in time, and multisig actually looks way more well-groomed.
Excuse me for a little bitsy of misleading, the should be dns_resolve, not dnsresolve.
Considering this, looking at all found bits about DNS resolver in TON at all, the dnsresolve is reasonably standartized resolver function that provides resolution of domain name for any particular DNS resolver in blockchain. It is noticable that resolution shall be provided by the requirements as a get function. This way, get function is executed by client, and result address should be used by it before any transaction using that result is actually sent to network. This is more supported by fact, that contract cant call get function by itself by any means atm.
[ Continued in #issue8905 ]

[ Continuation of #issue8904 ]
However, this is even more important in chain of resolvers: if, for example, you want to find org\0telegram\0 entry, and root resolver tells that org\0 is delegated to your resolver, client will say "okay, now lets ask your resolver" and attempt to resolve this entry using dnsresolve(name, cat) with your resolver. This way, I see three problems here (mentioned in #issue8899): your resolver cannot perform forwarding to another chain (because there is no special -1 next entry), category #1 is clobbered by owner address (i believe that category 1 may be "primary" in future, like A or AAAA in normal DNS), and most importantly, not having standartized dnsresolve will trash the resolution when client attempts to find and call dnsresolve at your contract. This way, it should be implemented inside your contract because it is not possible to "proxy" dnsresolve through another contract (remember, no ways to call another SC get-methods).

#issue9062
It is really dangerous to not compare workchain_id, because it is very easy to register a contract in another workchain with the same address. Usually there will be no way to send messages from the contract, but that's not always the case.