Johanes Antonius

Chelo Labs — Nomos & Bloc

Several people, one irreversible decision

Two products for the same hard problem: how does a group commit to something none of them can take back? Nomos handles shared custody of funds, Bloc of decisions. Archway’s DAO voted Nomos in as its official multisig.

Role
Product Designer at Favorite Medium, for Chelo Labs
Timeline
May – November 2023
Practice
0→1 product definition · High-consequence interaction design

I defined and designed two products from nothing, for the same hard problem: how a group commits to something none of them can take back. One of them became the multisig Archway’s DAO voted in as its official wallet.

1,000+

Beta users on Nomos

Round 2

Archway Grants Program recipient, September 2023

Official

Multisig for ArchwayDAO and its SubDAOs, by governance vote

The last one is a public vote, not a number I’m reporting about my own work — it’s still readable in Archway’s governance forum.

01The problem

Software for groups, not people

Most interfaces are designed for one person doing something they can undo. Both of these were the opposite: several people, one action, no undo.

Nomos is a multisig wallet — a shared account where a transaction needs approval from a set number of signers before it executes. Bloc applies the same structure to governance: a group configures the rules by which it will collectively decide things, then deploys those rules on-chain.

Different products, one design problem. When an action is irreversible and authority is distributed, the interface has to answer questions single-user software never asks. What exactly am I approving, and why? Who else has approved, and who are we waiting on? How do I understand a rule I’m setting now that will bind me later?

02Nomos

Shared custody of funds

The hardest screen in the product is the one where a signer decides. Everything else is reporting; this is the moment someone commits shared funds to something irreversible. Four decisions carry it.

The approval screen. Plain-language summary, the proposer's note, and named approvals — with Reject and Confirm as the only two exits.

A transaction explains itself in plain language

The screen leads with Transfer 1.2 ARCH to 1nzxtqc…40ltsgyar and names the destination chain. Not a hash, not a payload. The identifying data is still there underneath — it just isn’t what you read first.

The proposer writes a note to the other signers

The one on this transaction reads “Treasury management, specifically related to LSD and ETH.” This is the decision I’d defend hardest. A blockchain transaction can tell you exactly what will happen and nothing at all about why. Intent doesn’t exist on-chain, so the interface has to carry it. Without that field a co-signer has two options: approve blindly, or go and ask in a group chat.

Approvals belong to people, not addresses

The panel reads Confirmed (1 of 2) and names Andy, with his address beneath. Not a counter — a person. That’s what turns “waiting” into something you can act on, because you know who to go and ask.

The threshold follows you everywhere

The 1/2 badge appears on the dashboard, in the pending list, on the detail screen, and on mobile. Whatever surface you land on, the same question is answered: how many more people does this need?

Pending transactions sit above history, each carrying its signature count. What needs you comes before what already happened.

Two smaller decisions that remove a lot of friction

When you connect a wallet, Nomos detects the multisigs you already belong to and tells you, instead of asking you to go and find them. And the multisig switcher carries a pending count on each entry — 2 pending transactions, 3 pending transactions — so someone who signs for several treasuries can see what’s waiting on them without opening each one.

Pending work surfaced at the account-switcher level, not buried one level down inside each treasury.
03Bloc

Shared custody of decisions

Bloc turned a DAO from something you write contracts for into something you configure. The creation flow runs in four steps — Create Bloc → Module Settings → Allower Settings → Deploy — ending in an on-chain transaction and a confirmation.

That structure is the design work. A DAO’s constitution — token, quorum, voting period, who may spend what — is a genuinely complicated set of interdependent rules, and the naive version of this screen is a wall of inputs only someone who already understands DAOs could complete. Splitting it into four named stages gives people a mental model of what a DAO consists of, and means nobody faces every decision at once.

Step one. Note the “Not changeable” badge on the DAO field — permanence is marked where the decision is made, not in a warning at the end.

Permanence is labelled at the point of entry

The genuinely irreversible fields — which DAO the Bloc belongs to, and the Bloc’s lifetime — carry a Not changeable badge inline, next to the input. That’s the answer to the hardest question in this product: how do you understand a rule you’re setting now that will bind you later? You tell people while they’re deciding, not after they’ve committed.

Rules expressed the way people think about them

Quorum is a slider showing a percentage, not a raw threshold. Voting delay explains its own edge case — “can be set to zero so that the voting starts immediately”. And the payment allower assigns whitelisted addresses human roles like Developer and Marketing, with spend limits per role and token, rather than asking anyone to reason about permissions as a list of hex addresses.

Governance rules as controls people can reason about — quorum as a percentage, voting windows as durations.
Spending permissions by role rather than by address, and the lifetime field marked permanent.

The ending is the point

The deploy step opens with a full review of every setting, each section individually editable, and says plainly what happens next: after creation, changes can only be made by creating proposals on the DAO. Not frozen — but no longer yours alone to change.

Then the deployment itself is shown as what it actually is: two separate on-chain transactions, tracked individually — Approve new token: Executed, Create Bloc: Waiting… — rather than one spinner hiding a multi-step process.

And the final screen is the part I like most. “Your proposal is sent to DAO!” Creating a Bloc doesn’t create a Bloc — it submits a proposal that the DAO must pass before the Bloc activates. Setting up the container for a group’s collective decisions is itself a collective decision. Once I understood that was the actual model, the flow stopped being a form and became the first proposal a group ever votes on.

Review everything, then watch both transactions resolve separately rather than behind a single spinner.
Creating a Bloc submits a proposal. The group has to vote its own container into existence.
04Outcome

What happened

1,000+

Beta users on Nomos

Round 2

Archway Grants Program recipient

Announced September 2023.

Official

Multisig for ArchwayDAO and its SubDAOs, by governance vote

The third one is the one that matters. It isn’t a number I’m reporting about my own work — it’s a public vote by people with no reason to flatter us, recorded in Archway’s governance forum, and it’s still there to read. Nomos was also named in the Round 2 grant recipients, and has public documentation and a public codebase.

05Reflection

What I’d do differently

I tested with people one at a time, which was the wrong shape for this product. Everything interesting about a multisig happens between people — waiting on someone, chasing them, disagreeing about whether to sign at all — and none of that turns up in a solo session.

The flows I like best all assume everyone eventually signs. I gave much less attention to the awkward cases: a co-signer who’s unreachable, a lost key, a proposal nobody wants to be the one to reject. Those are the situations where shared custody actually hurts, and they deserved more of my time than they got.

I also came into web3 knowing very little, and I spent a while designing around concepts I hadn’t properly understood yet. A few redesigns would have been avoidable if I’d slowed down and got the mechanics straight first. I did that differently on the next project.