Boundary_Labs

Pre-launch smart contract failure detection.

ERC-4337 • Exploit simulation
Griefing & DoS analysis

We find how protocols break before users do.
DMs open.

[Boundary_Labs @boundary_labs]

Most smart contracts don’t get hacked first — they fail themselves.

Common pre-launch failures:
• execution assumptions breaking
• validation ≠ execution
• griefable callbacks
• passes tests, fails in production

What issues have you hit before deployment?

[Boundary_Labs @boundary_labs]

When your logic depends on time, what threat model are you using?

What happens if an attacker compresses actions into the same block?

Or exploits ordering within that window?

Have you seen time-based assumptions break under adversarial conditions?

[Boundary_Labs @boundary_labs]

When upgrading or interacting across contracts, what do you assume about storage?

That layout stays aligned?

What happens if a slot shifts or is reused differently?

Would your reads still point to the same data?

The input isn’t just calldata.
It’s how storage is interpreted.

[Boundary_Labs @boundary_labs]

When reviewing a transfer:

Do you treat it as a simple state change?

Or as a point where control leaves your contract?

If execution re-enters during that call, what breaks?

Most issues don’t come from the amount sent.
They come from the interaction surface.

[Boundary_Labs @boundary_labs]

A function does:

validate → update state → external call → finalize

Tests assume it either succeeds or reverts.

But under gas pressure or external behavior, it can stop mid-flow.

State updated. Finalization skipped.

Not a bad input.
A broken execution path.

[Boundary_Labs @boundary_labs]

Two-step flows assume continuity:

deposit → withdraw

Each step is safe in isolation.

But users control what happens between them.

Insert a state-changing call, and the second step runs on a different state.

The bug isn’t in either function.
It’s in the gap.

[Boundary_Labs @boundary_labs]

When a bug won’t reproduce, it’s usually not the code.

It’s the inputs you didn’t model.

Not calldata —
but ordering, gas, intermediate state, external behavior.
Same call, different conditions → different result.

[Boundary_Labs @boundary_labs]

User input isn’t just data , it's also gas.

A contract updates state, then does an external call assuming enough gas remains.

A user can deliberately constrain gas so the call behaves differently or fails mid-flow.

The value passed was valid.
The execution conditions weren’t.

[Boundary_Labs @boundary_labs]

@Hydrogen_04 'read-only' calls are devastating for cross-chain protocols.

What other user inputs do you usually see that can bypass sanitization measures?

[Boundary_Labs @boundary_labs]

A common blind spot in reviews:

A contract validates inputs, then calls an external contract expecting a specific return.

But users control which contract responds.

The parameter looked safe.
The external behavior wasn’t.

User input often enters through interaction surfaces.

[Boundary_Labs @boundary_labs]

When reviewing contracts, one question matters more than most:

“What can a user control here?”

Inputs aren’t just parameters.

Users control:
• timing
• call sequencing
• gas pressure
• interaction surfaces
Every controllable variable is a potential failure path.

[Boundary_Labs @boundary_labs]

ZK verification failures aren’t always cryptographic mistakes.

Sometimes:
• the proof is valid
• the circuit is correct
• the versions match
But the verifier expects a different transcript or proof layout.

Failures hide in integration mismatches.

[Boundary_Labs @boundary_labs]

@alaskanking19 Storage layout discipline + invariant testing.

Most governance exploits aren’t logic bugs.
They’re assumption shifts after an upgrade.
If an upgrade can silently widen privilege or alter economic guarantees, you don’t have upgradeability — you have deferred risk.

[Boundary_Labs @boundary_labs]

@Hydrogen_04 Yes.

Auditing code answers: “Is this written correctly?”

Auditing execution answers:
“What happens when this interacts with a hostile environment?”
Mainnet evaluates state machines, not intentions.

That distinction matters.

[Boundary_Labs @boundary_labs]

You can reason correctly at the Solidity layer and still be wrong.

Because the system that runs on mainnet is:

-IR-optimized
-gas-constrained
-order-dependent
-stateful across calls

Security assumptions must survive the full execution pipeline not just the source.

[Boundary_Labs @boundary_labs]

@georgeh0x @savio_sou @NoirLang Good deal. If the issue still persist, let me know and we can continue troubleshooting.

[Boundary_Labs @boundary_labs]

@georgeh0x @savio_sou @NoirLang Would be interesting to see which step causes it to diverge.

[Boundary_Labs @boundary_labs]

@georgeh0x @savio_sou @NoirLang Since versions match, I’d try isolating it:

• Fresh install, regenerate both proof + optimized verifier
• Make sure SRS/setup is identical
• Generate proof with bb cli instead of bb.js and test that
• Compare proof lengths between the two

[Boundary_Labs @boundary_labs]

@georgeh0x @savio_sou @NoirLang Gotcha, so if the artifact matches, then it’s probably not a pure circuit size issue.

I’d suspect some drift between bb.js/noirjs and the bb cli optimized verifier. Small transcript or layout differences can cause that revert.

Are you running the same bb version across both?

[Boundary_Labs @boundary_labs]

@georgeh0x @savio_sou @NoirLang If bb.js and bb cli aren’t using identical circuit parameters (logN / transcript settings), the optimized verifier will revert even for valid proofs.

Are they built from the same artifact?

[Boundary_Labs @boundary_labs]

@TammyBuilds This one hurts because it feels so correct at first glance 😄

User had ETH., everything looks fine.

But once an intermediary contract gets involved, the economic assumptions change completely.

Execution context sneaks up fast.