We (Safe Research) just published our prototype, Safe Harbour. This R&D project offers an alternative to the offchain transaction service by moving pending transactions and signatures entirely onchain in the Harbour smart contract deployed to Gnosis Chain. As long as the chain is running and an RPC endpoint is available, transactions can be enqueued and executed for your Safe - no additional backend or offchain indexer is required. If you do not want to use Gnosis Chain, you could deploy the Harbour contract to any other EVM chain where Safe is supported.
You can read the full blog post here for details and links here -
Let us know what you think of the prototype, as we work to bring even more trustless components to the Safe stack.
For now, Safe Harbour can address the “queue” part of the Safe tx service. However, the tx service serves two core functions:
Indexing historical onchain data - “indexer”
Storing tx data and pre-confirmations before they are executed - “queue”
As the queue is more lightweight, it was simpler to put onchain using Harbour. Decentralising the indexer is a seperate topic, and we can take learnings from the likes of The Graph here.
I am trying to make sense of the typical flow to use the contract from a front-end prospective:
Allow enqueuing new transaction by calling enqueueTransaction on SafeInternationalHarbour
Retrieve events NewTransaction and SignatureStored from SafeInternationalHarbour, to have the transactions ever queued and who has already signed them
Retrieve events ExecutionSuccess and ExecutionFailure from Safe, to have the transactions executed or failed
Diff => Transactions queued but not executed, still outstanding.
List these transactions in the UI, (potentially showing the number of signatures already gathered and the corresponding owners)
For transactions whose #signatures < #owners, allow adding signatures via enqueueTransaction on SafeInternationalHarbour
For transactions whose #signatures >= threshold, allow executing the transaction
6.1 Use retrieveSignatures on SafeInternationalHarbour to get the signatures
6.2 use executeTransaction on Safe to execute the transaction with the retrieved signatures
This is a huge step forward for multisig transparency and resilience. major kudos to the Safe Research team!
Removing the offchain transaction queue and going fully onchain with Harbour isn’t just a technical upgrade, it’s a philosophical one. This aligns deeply with the ethos of trust minimization and censorship resistance we all strive for in decentralized coordination.
Curious to know:
How does Harbour handle transaction reordering or potential front-running scenarios?
Any plans for a lightweight UX wrapper to make this friendly for non-technical DAO operators?
This could be a game-changer for onchain treasury governance. Looking forward to testing it out and seeing how the community builds on top of this!
1. How does Harbour handle transaction reordering or potential front-running scenarios?
Not sure if you are talking about chain reorgs here, but in the rare event of a chain reorg, a transaction might be dropped and the corresponding metadata (like pre-confirmations or queue status) could be lost. While this is a worst-case edge case, the underlying transaction data remains onchain.
MEV is still an issue for Harbour. And it exists today also in the tx service. To mitigate this in the future, we’re currently working on an end-to-end encrypted queue, which will enhance privacy and reduce information leakage before transactions are broadcasted.
2. Any plans for a lightweight UX wrapper to make this friendly for non-technical DAO operators (e.g. with Sepolia + ERC-4337)?
Yes! There is already a UI available at safe.dev/harbour to interact with the Harbour queue. We’re actively developing UX improvements that include 4337 enabled relaying, which will enable smoother execution flows. Our goal is to make the queueing and signing experience as easy as possible seamless while still preserving decentralisation and security. Disclaimer: This is a prototype, and not audited, so use at your own risk.
Ah - ok, I think I understand now. If you have a n/m Safe, and the Harbour interface seens n signatures for a transaction, it doesn’t let you add an n+1-th.
I think it makes sense to allow in the Harbour interface (the underlying contracts do not prevent it, so I think it makes sense to include).
The R&D team is very much focusing on the research for this. There are a lot of challenges related to accessiblity, scalability and privacy related to this current prototype that we are iterating on. We will post regular updates
Harbour in itself is meant to be chain agnostic, meaning it can collect information (i.e. transaction data and signatures) for any chain id, without actually requiring that there is an active chain related to this id.
Going forward we will have to evaluate the relationship of harbour (which current lives on Gnosis Chain) and the chains where the Safe transactions are executed.
Harbour focuses on collecting partial information related to Safe transaction (often called the queue). We want to work towards a decentralized, permissionless, private, scalable and accessible queue. Indexing often refers to tracking/ storing the executed transaction (historic state). We want to clearly separate this to reduce complexity.
Posting an update regarding improving the accessibility of Harbour. We utilized ERC-4337 and Waku to reduce some of the common friction points (like having to sign twice). Read up on the details in our latest blog post and let us know your feedback
Just wanted to post another update on a new features introduced to Harbour: we just added end-to-end encryption to the decentralized queue, in order to keep unwanted eyes off of transactions while signatures are being collected. Read about how we implemented E2EE in our latest blog post and let us know what you think!
