I once witnessed a company using a document approval process via email. At first, a document only needed three people to review before being sent out. The first person edited it, the second checked it, and the last one approved it. Everything happened within a few hours. But as the process scaled and more parties became involved—legal, finance, operations—a document could take many days just to collect enough feedback. Someone was on vacation, someone missed the email, someone replied on an older version. Approval itself isn’t hard. It’s the coordination of many people that becomes the bottleneck. Approval by itself was never the problem. The problem was the coordination around collecting twelve individual signatures.
That memory keeps coming back to me when I think about multisig wallets. Gnosis Safe, the standard for on-chain multisig, works exactly like that paper. Each signer creates their own ECDSA signature. Those signatures are collected off-chain, aggregated into a single transaction, and sent. The contract verifies each signature against its list of owners. With a 3-of-5, that’s three calls to ecrecover; the calldata data is equivalent to three signatures, and gas cost increases linearly with the threshold. It works well with small groups. Two founders, three board members—maybe a DAO with five signers. But as the group grows, friction increases. A 15-of-20 multisig means verifying fifteen distinct signatures on-chain. That’s fifteen ecrecover operations, costing about 45,000 gas just for signature verification. Even the calldata for fifteen 65-byte signatures plus the corresponding addresses adds overhead to the transaction. And off-chain, someone still has to collect those ten signatures before the transaction can even be sent. The coordination cost doesn’t just affect the blockchain. It affects people first.
Newton approaches signature aggregation differently, aggregating BLS signatures on the BN254 curve. When AVS operators evaluate an intent and agree on the result, each one signs with their own individual BLS key. But instead of attaching all those signatures to the attestation, an aggregator combines them into a single fixed-size aggregate signature. The PolicyClient contract verifies that signature using the aggregate public key of the set of operators. Whether the quorum is 3-of-5 or 100-of-200, the verification cost stays the same: one pairing check. Fixed gas. That’s the technical difference: one ecrecover per signer versus a single BLS pairing check for the entire set.
But what I find more interesting is how that changes the off-chain coordination model. In a traditional multisig, you need to keep track of collecting each individual signature from each individual person. People can go offline. They miss messages. They sign the wrong nonce. The transaction gets stuck until the threshold is manually collected. Newton’s operators are online by design. They’re running infrastructure, not checking a wallet app between meetings. Aggregation happens automatically as part of the consensus process. No one has to go hunting for each person to request a signature. The tradeoff is transparency. With Gnosis Safe, you can inspect the calldata and know exactly which owners signed. The contract emits an event for each signature—there’s an audit trail. With BLS aggregation, the final signature is a single blob. You can mathematically prove that the threshold was met, but you can’t easily extract which specific operators signed. The aggregate becomes a black box to the casual observer.
That’s fine for a policy engine where you trust quorum or you don’t. But for organizational governance, where knowing who voted in which direction matters, the traditional multisig model still has an advantage.
I keep thinking about where the real bottleneck actually is. For a small group managing a shared treasury, Gnosis Safe is more than sufficient. The gas cost for five signers is negligible. Coordination cost is minimal. But for a protocol like Newton, where dozens of operators need to verify policy evaluations at high frequency, the multisig model collapses under the weight of its own coordination costs. Aggregation isn’t just a small optimization. It’s what makes the whole system able to operate at large scale. I’m still not entirely sure how the aggregator is selected or rotated. The docs mention that it collects individual BLS signatures into a single proof once quorum is reached, but I haven’t found details on whether any operator can act as the aggregator, or whether that’s a role that’s assigned.
Maybe there is a mechanism to elect a leader, or it could be deterministically defined based on the block. If the aggregator has malicious behavior, in theory they can delay everything, but they can’t forge a valid aggregate without enough individual signature thresholds. The security assumption remains the same. Only liveness is affected. What’s left in my mind is the image of an important project decision being delayed on-screen, while everyone waits for each remaining member to provide confirmation. The technical issue and the social issue turn out to be the same thing. Newton’s BLS aggregation solves both. But I wonder whether there’s some threshold—maybe on the order of twenty or thirty signers—where even human coordination around key management becomes the next bottleneck, and no signature scheme can fix that. Maybe that’s the next problem.