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.