Frictionless Queues: Decentralized Signature Collection with ERC-4337

In our vision for the future of self-custody wallets, we outlined a clear goal: build an accessible, permissionless, private, scalable, and decentralized queue for transactions. Our first iteration, Harbour, laid the groundwork for a permissionless and decentralized queue. Today, we're excited to introduce the next evolution of Harbour, which focuses on a critical piece of our vision: accessibility.

What is accessibility?

In our manifesto we define accessibility as making a system usable and safe for as many people as possible, including those with no prior knowledge or technical literacy. Our target user experience matches the simplicity of Safe{Wallet}: sign once, and have the signature stored for free - no juggling chains, RPCs, or gas.

Where are we at?

In the current Harbour flow, users face several hurdles we’re eliminating:

• Funded Wallet Required. Users needs funds on Gnosis Chain just to interact with Harbour.

• Multiple Signatures. Today, users sign both the Safe transaction and again for Harbour.

• Multiple RPCs. Users must manage RPC access to two chains simultaneously: the target chain for their transaction and the chain where Harbour is deployed.

The Challenge: Onchain Fee Payments

Achieving a seamless experience requires a resilient and user-friendly way to handle onchain transaction fees. We've turned to ERC-4337 to solve this by fundamentally changing how Harbour processes transactions.

Instead of creating a separate "relaying account" for each signer, we have extended Harbour to be a native ERC-4337 account. It is possible for multiple signers to submit signatures to Harbour in parallel due to two key properties:

1. Minimal state coupling. The only invariant is that no signature can be stored twice.

2. Independent replay protection. Each signer uses the EntryPoint's nonce functionality with the signer's address as the key, so parallel submissions don’t collide.

As with any other ERC-4337 account, the EntryPoint first calls the validateUserOp function on the Harbour contract before performing the execution. In the validateUserOp function, Harbour validates the input (i.e., the signature for the Safe Transaction and that the signature is not already stored), while during the execution phase, the data is stored onchain. Crucially, Harbour's design delegates all fee logic to a Paymaster contract which is enforced for every transaction. This keeps Harbour focused on signature validity, while the Paymaster handles sponsorship, quotas, and anti-abuse.

With this architecture in place, we explored several Paymaster models:

• Sponsor Everything: The simplest method is a paymaster contract that covers all interactions. While incredibly user-friendly, this approach is highly vulnerable to spam.

• Signer-Based Quotas: To counter spam, we considered a system where signers stake tokens to get a daily quota of free signature submissions. Think of it like a club membership where you get five free drinks every day. This adds spam mitigation but requires extra steps from the user to acquire and stake tokens.

• Validator Networks (chosen): Keep UX simple for signers while pushing economic accountability to professional actors.

Introducing Harbour Validator Networks

Instead of requiring every user to stake tokens, we introduce validators.

Validators are entities that lock tokens to get the right to approve a certain number of signature submissions each day. The interface submits the user's signature to a validator, who then sends it onchain. This means signers don't require any additional interactions; they just sign the transaction as intended.

Think of validators as club members who can share their “daily free drinks” with friends: if those drinks are misused, the member (validator) is penalized. Validators must follow protocol rules and any additional policy they choose to enforce. Misbehavior leads to slashing (loss of stake), providing strong incentives without burdening end-users.

Decentralizing Communication with Waku

Signers and validators need a communication channel. Direct communication introduces a potential point of failure. While a misbehaving validator could be easily replaced (much like an RPC node), a decentralized network is a far more resilient solution. For this, we use Waku for secure and private peer-to-peer (p2p) communication:

• Resilient. No trusted relay to censor or fail.

• Light-node friendly. Easy to run in end-user clients (e.g., our web interface).

• Simple to integrate. Streamlined setup for both validators and frontends.

The initial implementation is fully based on Waku Light Push. While this is acceptable for the interface, it put some limitation on the validator worker. As a follow up to this first implementation the validator code will be improved to utilize native Waku nodes to increase the reliability.

Latest Progress

Experimental support is now live at safe.dev/harbour.

To try it out, you'll need to explicitly enable the feature in the settings. Once enabled, the web interface will run a Waku light node to connect to the validator network.

Anyone can run the validator worker prototype. The only requirement is to stake tokens on the Paymaster, and everything is open source:

• Run the Validator: Instructions can be found here

• Stake Tokens: Use top-up form in the settings of the Harbour web app or the deposit-validator-tokens task for staking token

What's next

• Privacy for Harbour: Encrypt transaction and signature storage.

• Scalable storage: Cost analysis and evaluation of alternatives beyond pure onchain methods.

• Smarter validators: Introduce additional conditions, policies and capabilities for validators.

About Safe Research

Safe Research is the applied R&D arm of Safe, dedicated to advancing the self custody stack. Our work is grounded in the cypherpunk principles of security, censorship resistance, and privacy, and we focus on building trustless, user centric infrastructure for smart accounts and wallets.

• Discuss Harbour in our forum

• Learn more about Safe Research

• Read our manifesto

Let’s make Ethereum’s original cypherpunk vision real, one commit at a time.