Multi-signature wallet.
k - num required signatures🖋, 1 <= k <= 10
n - num participants/max 🖋, 0 < k <= n <= 100

Each participant🐷 has indexed public key🔑 and sends messages📩 which contains order📦 to be sent to some destination when required number of signatures🖋 collected.

Message📩:
Signature🖋, signer index, valid until🕗, seqno, send mode, order📦 (bounce bits, etc, dest addr📪, grams 💎, body📄)

Sample state, 3 participants sent some orders:
🐷🔑0-------🐰🔑1-------🐸🔑2
📩+📦A-----📩+📦B ----📩+📦A


Storage:
🔑0🔑1🔑2..., seqno, k, n, pending orders

Pending (partially signed) order
key: hash(📦)2️⃣5️⃣6️⃣
value:
🕗expires 3️⃣2️⃣
🖋sig count 1️⃣6️⃣ (A 2, B 1)
🖋sig bitmask 1️⃣2️⃣8️⃣ (A 0101, B 0010)

✅ Fast access to 🔑 by index from 📩
✅ Cheap & fast bit mask storage for 🖋🖋🖋
✅ Expired orders garbage collection when k > 1
✅ Get all pending orders
✅ Get all signed or unsigned orders by particular 🔑
✅ No need to store orders, the one from inbound message is used when arrives with last required 🖋
✅ Easy debug via debug.fif and build_run_mltisig.sh
⚠️ Only one signature supported per 📩
⚠️ Parties have to repeat exact order📦 for each signature.
⚠️ Very first message sets 🕗, further expirations ignored.
⚠️ same order might be sent twice if o > k orders sent for the signing purpose, but they not only sent first one, but also created next one, and so on.
🐞 seqno hardcoded to 77 (forgot to fix it 😬)
💡 partially signed orders dict better to be moved to the beginning to avoid skipping bytes in get methods
😬 new wallet script not ready
😬 new and existing order scripts not ready

What is the purpose of seqno, if it is hardcoded?
Sequence number is needed to have different hashes of the same messages to avoid attacks, because these messages are "from nowhere", according to the TON documentation.

Or, did you mention this, like a bug? To be honest, it is hard to understand these emojis.

Actually you have two seqno checks. Do I read it correctly that if you can't find public key you just let it pass without signature?

Apart from this major but silly mistake I actually like it. You dropped "list of signatures" requirement and so avoided related replay issues. And although there are bunch of debug lines, it still looks clean and easy to reason about.

Only one signature at a time is supported. This incidentally makes this smart contract very safe, as accept_message is called only after all work is done.