Routing

In Blackhole, transaction signing is not just a UI confirmation — it’s the point of guarantee.

Before any execution packet reaches the signer (user, wallet, agent, or relayer), Blackhole enforces a multi-layered validation pipeline to ensure that only safe, deterministic, and fallback-protected routes can be signed.

This prevents blind execution and ensures that every signed payload:

→ Is structurally sound

→ Cannot lead to unexpected asset loss

→ Contains recoverable fallback logic

→ Is contextually low-risk

→ Has deterministic execution boundaries

---

What We Check Before Signing

1. Structural Validation (via Umbra)

We screen each route for known malicious patterns:

→ Fake tokens (e.g. honeypots, taxed tokens, fee-on-transfer traps)

→ Malicious contract behaviors (proxy abuse, self-destruct, infinite approvals)

→ Reentrancy-prone steps

→ Invalid bridge-wrapped tokens

→ Missing or incorrect approval chains

→ Token incompatibilities (e.g. rebase, non-standard decimals)

If any step contains known exploit logic → route is blocked upstream.

---

2. Contextual Reputation Analysis (via Echo)

We enrich the route with metadata from offchain sources:

→ Protocol and contract exploit history

→ Admin key activity (pauses, upgrades, rug patterns)

→ Aggregated social sentiment (spam-filtered)

→ TVL volatility / instability indicators

→ Coordinated attack signals (if available)

Risk scores don’t block the route but flag it for UX display or route exclusion. Final enforcement is configurable.

---

3. Slippage Enforcement

Each route includes:

→ minExpectedOut based on market conditions at discovery time

→ maxSlippageBps (configurable)

→ Optional per-step slippage enforcement

At execution, GravCore will hard-fail the transaction if actual output < minExpectedOut. Slippage is locked in at signature time — no silent degradation.

---

4. Fallback Path Validation (via SafeSwitch)

We verify that fallback routes are:

→ Structurally valid

→ Pre-validated by Umbra

→ Matched in risk profile

→ Signed alongside the primary route

→ Contain the same or stricter slippage constraints

Fallbacks are not just "nice to have" — they are signed commitments. GravCore can trigger fallback routes without new approvals or user intervention.

---

5. Execution Preconditions

Before allowing signature, Blackhole confirms that route includes:

→ Enforced gas limits per step

→ Deadline for execution

→ Approval list scoped to necessary tokens

→ Chain ID and nonce consistency

Any missing or misaligned preconditions → route rejected.

---

6. Signer Authorization Scope

The signer only approves:

→ One route

→ One or more fallback routes

→ One gas budget

→ One set of risk boundaries

No hidden logic. No external calls outside the signed scope.

---

Summary

Blackhole routes cannot be signed unless they pass the full validation pipeline:

Layer	Check
Structure	Contract traps, token behavior, approval correctness
Reputation	Exploit history, admin key misuse, social red flags
Slippage	Boundaries enforced at runtime, defined at signing
Fallbacks	Pre-approved alternatives, embedded into execution packet
Preconditions	Gas, time, approvals, network locks
Scope	Signer only approves the visible, deterministic execution plan

Once signed, the payload becomes deterministic, auditable, and safe by design. If something breaks at runtime — fallback takes over. If even that fails — execution halts safely, with no fund loss.