Hi everyone,
I’m Barış, founder of Hashlock (https://hashlock.markets) — an intent protocol where every intent carries a counterparty attestation with a verification tier (NONE / BASIC / STANDARD / ENHANCED / INSTITUTIONAL). Today that tier is only checked off-chain by solvers, which leaves a gap: the Safe that actually executes the trade has no wallet-level “I will only trade with verified counterparties” lever.
I built a ~300-line reference Safe Guard that closes the gap. It reverts execTransaction whenever the attached Hashlock intent’s counterparty tier is below the owner’s policy. TypeScript first so the decision logic is obvious (two rules, ~15 lines); the port to a real BaseGuard is mechanical and the README maps it line by line.
Runs in one command, no RPC. Two scenarios, same Safe, same policy:
- STANDARD counterparty → ALLOWED
- BASIC counterparty → Guard reverts with
counterparty tier BASIC < required STANDARD
Repo: GitHub - BarisSozen/safe-hashlock-demo: Demo: a Safe-compatible policy module that gates transactions on Hashlock attestation tier · GitHub
1-page brief: safe-hashlock-demo/docs/TECHNICAL_BRIEF.md at main · BarisSozen/safe-hashlock-demo · GitHub
Full walkthrough (10 min read): safe-hashlock-demo/docs/WALKTHROUGH.md at main · BarisSozen/safe-hashlock-demo · GitHub
Three yes/no questions for whoever owns Guards — async, no call needed:
- For the production checkTransaction path, would you prefer (a) decode the intent out of
data, or (b) an oracle-style pre-committed intent hash? - Rough gas ceiling you consider acceptable for a Guard hook on mainnet?
- Any known footguns stacking this with the common spending-limit / allow-list guards?
Happy to iterate on code rather than schedule calls. If this is miscalibrated for what Safe{Core} is looking at right now, a one-line “not for us” is totally fine.
Thanks,
Barış