Demetrium RPC Firewall

Firewall on-chain transactions before they cost you.

Define policy, evaluate outcomes, and block irreversible mistakes before broadcast.

SIGNED_TX
Wallet
Network
Founding Story

Built to prevent a mistake that should never happen twice.

It is 10 PM after a long day. A one-of-a-kind airdrop notification appears. You verify the source, it looks legitimate, and you claim it.

Nothing happens. No warning. You check the claim again, then open your wallet and realize it is already drained. The source still looks legitimate, but it was compromised and users were served the same scam flow.

You fell for it.

You are technical, so you trace the execution path and confirm the destination contract has been known as malicious for years.

Why was this ever allowed to execute? Why was there no guard?

Demetrium answers that by preventing irreversible mistakes.

Deterministic Pre-Broadcast Enforcement

Proof: One Transaction, Two Outcomes

Same signed payload. Other RPC Providers broadcast it. Demetrium blocks it.

SIGNED_TX0x8f...2a3
Same payload routed to two infrastructures
Other RPC Providers
IN FLIGHT
Signed Transaction received0%
Broadcasting to NetworkPENDING
Execution Final Outcome
Decision latency: N/A
Risk class: Unchecked
No security enforcement
Demetrium
EVALUATING
Signed Transaction received0%
Transaction EvaluationSCANNING
Broadcast AuthorizationPENDING
Execution Final Outcome
Decision latency: 148ms
Risk class: High-risk contract
Transaction Evaluation before Broadcast
Execution sequence
1. Signed transaction received.
2. Path diverges by infrastructure policy model.
3. Other RPC Providers: COMPROMISED | Demetrium: BLOCKED.
Verdict
Same signed payload. Other RPC Providers end in COMPROMISED / FUNDS LOST. Demetrium blocks the transaction.

Non-Custodial Guarantees.

Your wallet still signs locally. Demetrium never holds keys, seed phrases, or signing authority.

Demetrium evaluates transactions at the RPC boundary and blocks unsafe execution before broadcast.

What stays in wallet
Private keys: never leave wallet
Seed phrase: never requested, never transmitted
Signing authority: never delegated
What Demetrium enforces
Policy evaluation at RPC boundary
Unsafe execution blocked before broadcast
Deterministic decision reason returned
No key custody
No seed phrase exposure
No signature delegation
Policy enforcement at RPC boundary

Enforcement Capabilities

Controls that enforce policy at execution time, not after loss.

Pre-Broadcast Transaction Evaluation

Evaluates every signed transaction before network submission.

Allow/block decision before submission.

Chain-Aware Policy Enforcement

Applies deterministic policy enforcement across supported chains.

Chain-scoped rule application.

Deterministic Rule Engine

Enforces allow/deny rules, spend limits, and interaction thresholds at RPC time.

Machine-readable rule trigger.

Forensic Audit Trail

Logs every allow/block decision with reason and timing.

Immutable decision trace.

FAQ

Will Demetrium slow down normal wallet activity?

Demetrium adds a policy-evaluation step before broadcast. In normal operation this is low-latency and deterministic, so transaction flow stays responsive.

What happens if a legitimate transaction is blocked?

Blocked transactions are surfaced with machine-readable reasons. Teams can adjust policy or use explicit override flows when they intentionally accept risk.

Do we need to modify contracts, wallet code, or dApp logic?

No contract changes are required. Demetrium enforces policy at the RPC boundary, so existing contract logic remains unchanged.

Can this run in dedicated infrastructure with strict control boundaries?

Yes. Dedicated deployments can be scoped with isolated operational boundaries and support terms for enterprise environments.