Same-block execution, on a trigger you control.
This is speed and reliability for actions on what's yours: watch a condition you define, and the instant it's true, act in the same block. Defend a position before a liquidation, execute a pre-committed entry, claim at a known unlock. We're direct about the line, though: we build the version that acts on your own position, not the one that makes someone else the mark.
The trigger, in real code.
No black box, and no ambiguity about what it touches. You define a condition on state you own, a health factor here, and the action that should follow. When the condition is true, it builds, simulates, and submits in the same block. That's the whole tool.
1# defense.py — watch YOUR position, top up before liquidation2from burneh.exec import Trigger, same_block, repay34class LiquidationGuard(Trigger):5 watch = "your borrow position" # a condition on state you own6 arm_at = 1.50 # health-factor buffer, above 1.0078 def condition(self, position):9 # only ever reads and defends what is yours10 return position.health_factor <= self.arm_at1112 def action(self, position):13 # build, simulate, and submit in the SAME block it fired14 topup = position.collateral_to_reach(1.85)15 return same_block(repay(position, add_collateral=topup))The market moves against you at 3am.
Your health factor is sliding toward liquidation. Armed, the bot tops up collateral the instant it hits your trigger, in the same block, every time. Unarmed, you have to be awake to catch it. Toggle the trigger and watch.
This is the whole reframe. The speed is pointed at defending what's yours, watching a condition you set and acting the instant it's true, not at beating someone else to a trade.
A trigger you define, run the instant it's true.
The whole point is removing the human delay between a condition becoming true and the action that should follow. You decide the rule. The bot is just faster and more reliable than you can be at 3am.
A condition on state you can read: a price level, a health factor, a known unlock, your own contract's event.
No discretion, no hesitation, no fat-finger. When the condition is true, it acts, and only then.
The action is built, simulated, and submitted with a priority fee, fast enough to land in the block that triggered it.
What we'll build, and what we won't.
“Sniper” gets used for a lot of predatory things. We're direct about the line: we build speed and reliability for actions on what's yours. We don't build tools whose only purpose is to make someone else the victim.
- React to a condition on your own account or position
- Defend a position, like topping up before a liquidation
- Execute a pre-committed entry or exit at block speed
- Act on a known, public event: an unlock, your own contract
- Front-run other people's launches or transactions
- Snipe a fair mint to dump the supply on buyers
- Grief a public sale or defeat per-wallet limits
- Anything that works by making someone else the mark
It's the same stance as the mint and launch contracts we build, which exist to stop exactly that predatory behaviour. We're not going to sell the attack on one page and the defense on another.
Fast, and honest about the limits of fast.
Speed is a tool, not an edge. Being first to a bad trade is still a bad trade. So the controls are about not overpaying, not sending garbage, and knowing when you lost the race.
Same-block landing is a race. You can lose it to a faster player, and the bot tells you when it did.
The action is dry-run first, so it doesn't fire a transaction that would only revert and burn gas.
You set the ceiling on what a fill is worth paying for. It won't overpay to win a race that isn't worth it.
One command disarms every trigger at once, for when the assumptions behind them stop holding.
Same-block execution, on a trigger you control.
Speed and reliability for actions on what's yours: watch a condition you define, and the instant it's true, act in the same block. Scoped, not predatory.