# Safe Guard demo: gating execTransaction on a Hashlock counterparty attestation tier

**URL:** <https://forum.safefoundation.org/t/safe-guard-demo-gating-exectransaction-on-a-hashlock-counterparty-attestation-tier/6978>\
**Category:** Contracts\
**Created:** [April 13, 2026, 6:42am UTC](https://forum.safefoundation.org/t/safe-guard-demo-gating-exectransaction-on-a-hashlock-counterparty-attestation-tier/6978 "2026-04-13T06:42:47Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Baris\_Sozen](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.safefoundation.org/baris_sozen/32/4814_2.png) [@Baris\_Sozen](https://forum.safefoundation.org/u/Baris_Sozen)\
**Post date:** [April 13, 2026, 6:42am UTC](https://forum.safefoundation.org/t/safe-guard-demo-gating-exectransaction-on-a-hashlock-counterparty-attestation-tier/6978/1 "2026-04-13T06:42:47Z")

</div>

Hi everyone,

I’m Barış, founder of Hashlock ([https://hashlock.markets](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](https://github.com/BarisSozen/safe-hashlock-demo)  
1-page brief: [safe-hashlock-demo/docs/TECHNICAL\_BRIEF.md at main · BarisSozen/safe-hashlock-demo · GitHub](https://github.com/BarisSozen/safe-hashlock-demo/blob/main/docs/TECHNICAL_BRIEF.md)  
Full walkthrough (10 min read): [safe-hashlock-demo/docs/WALKTHROUGH.md at main · BarisSozen/safe-hashlock-demo · GitHub](https://github.com/BarisSozen/safe-hashlock-demo/blob/main/docs/WALKTHROUGH.md)

Three yes/no questions for whoever owns Guards — async, no call needed:

1. For the production checkTransaction path, would you prefer (a) decode the intent out of `data`, or (b) an oracle-style pre-committed intent hash?
2. Rough gas ceiling you consider acceptable for a Guard hook on mainnet?
3. 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ış