[Discussion] Introducing Safe Harbour R&D

gm Forum,

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.

John

6 Likes

I’m wondering if Safe Harbour can be used to build both the convenience and distribution of a Safe tx service outlined by @DennisonBertram.

1 Like

For now, Safe Harbour can address the “queue” part of the Safe tx service. However, the tx service serves two core functions:

  1. Indexing historical onchain data - “indexer”
  2. 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.

2 Likes

Just deployed it on Sepolia at SafeInternationalHarbour | Address 0xe737c09F268B07a1a2C523dCA378B69820A9624B | Etherscan if anyone else wants to play with it

I am trying to make sense of the typical flow to use the contract from a front-end prospective:

  1. Allow enqueuing new transaction by calling enqueueTransaction on SafeInternationalHarbour
  2. Retrieve events NewTransaction and SignatureStored from SafeInternationalHarbour, to have the transactions ever queued and who has already signed them
  3. Retrieve events ExecutionSuccess and ExecutionFailure from Safe, to have the transactions executed or failed
  4. Diff => Transactions queued but not executed, still outstanding.
  5. List these transactions in the UI, (potentially showing the number of signatures already gathered and the corresponding owners)
  6. For transactions whose #signatures < #owners, allow adding signatures via enqueueTransaction on SafeInternationalHarbour
  7. 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

Does this make sense?

1 Like

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!