← Back to blog

Published on Fri Sep 12 2025 00:00:00 GMT+0000 (Coordinated Universal Time) by Orkid Labs

It’s Friday. The inbox is full, investors are texting, and the demo needs to be both dazzling and safe. This week was about protecting users and our IP while keeping velocity high — a story about purpose-built constraints, not just features.

Why demo-only matters (and why “just pause it” wasn’t enough)

We needed to prove — on-chain and off — that the system is in a read-only state for investor demos. The easy pitch is to “pause” contracts. The real world reply: legacy contracts weren’t pausable and weren’t upgradeable proxies. So we did what disciplined teams do: we created ABI-preserving guarded contracts that revert all writes with “demo-only,” and we re-point the app to those addresses. Investors can verify this directly on-chain.

Highlights:

  • ABI preserved; state-changing calls revert with “demo-only”
  • Reads are safe (zeroed or guarded)
  • New addresses published and linked in the docs

CI/CD: when org migrations break your deploys

We moved registries (repo migration), and the deploys silently pulled from the wrong Docker image paths. CI was pushing to the right org; the server was still pulling from the old one. Fixes:

  • Updated workflows to tag/pull from the new org registry paths
  • Taught the deploy workflow to handle manual triggers cleanly and to fall back to latest if a SHA tag isn’t present
  • Added an org-level token fallback for GHCR pulls
  • Health checks plus guarded rollback logic

Lesson: org moves break the invisible glue first. Automate the boring parts; make fallbacks explicit.

WebSockets, auth, and demo-friendly UX

A demo that requires an API key to even connect isn’t a demo — so we:

  • Allowed anonymous WS connections when DISABLE_AUTH=true
  • Ensured the frontend connects to the correct backend domain in prod (no stray subdomains)
  • Always create the WS worker; don’t require an apiKey just to show data in demo mode

The on-chain path we took

  • Confirmed legacy contracts were not proxies (no “Read/Write as Proxy” tabs)
  • Wrote a lockdown script for best-effort Pausable/AccessControl cases, plus source deactivation hooks
  • Deployed two new contracts on Polygon mainnet:
    • GuardedArbitrageExecutor: 0xB4a4355a62dbbB8E67DaC455C321890Eea22654a
      • Tx: 0x84d1b374dcf4d5c1e3deca17cda63865659f536ed026c4d74cf9c9a173cf2cbd
    • GuardedEventStreamReconciler: 0xbAE395a77dad3D0e34127F7ae270042cb33cD632
      • Tx: 0xee9c5d17748e41d2b102b76da2d663938e0bcc687a02c649899befd4a1a1870e
  • Verified behavior:
    • executeTwoHopArb → reverts “demo-only”
    • getReconciledPrices → zeroed or guarded

Tooling choices (and why)

Hardhat v3 is ESM-only, and we didn’t want to flip the repo’s module type for a quick ship. We added a tiny, isolated subpackage for deployment, and a solc-based fallback deployer to bypass local Hardhat bootstrap quirks. Principle: keep the blast radius small; ship the outcome.

Principles we leaned on

  • Private by default for MEV-sensitive flows (simulate → private → controlled fallback)
  • One provider/client per network; reuse connections; backoff + jitter
  • Rate limit and cache hot reads; batch, don’t N+1
  • Observability beats ceremony: structured logs; health checks; measurable rollbacks
  • Demo mode must be obvious to users and provable to auditors (on-chain + app guards)

What we shipped (user-facing)

  • Demo-only enforcement (backend + frontend flags)
  • ABI-preserving guarded contracts deployed on Polygon
  • Updated docs with addresses and verification steps
  • Deploy pipeline that works after an org migration
  • Anonymous WebSocket demo capability

Lessons learned (for founders and teams)

  • “Just flip the switch” isn’t a strategy — it’s a hope. Design the off-ramp on day one.
  • Your riskiest failure modes hide in wiring: registries, tokens, and envs — not glamorous, but existential.
  • If your demo is slow to set up or finicky about keys, you’ll miss the moment. Remove drag.
  • Be generous with your safety rails. You’ll never regret a guard that prevented a bad day.

Whats next

  • Surface more telemetry on chain conditions and route selection (without leaking details)
  • Expand demo-only analytics with clear disclaimers (simulate ≠ guarantee)
  • Continue the TypeScript porting plan for the physics engine integration

If youre evaluating MEV products, ask for realism: real gas, realistic execution constraints, and the courage to disable trading in a demo without losing insight. Thats what were building.


Editor’s note: This post was updated on September 19, 2025 to include a custom Open Graph image for improved social media sharing. No content changes were made.

Written by Orkid Labs

← Back to blog

Research to next step

Turn this research into a usable next move

Reading the post is only step one. The stronger move is to route it into the asset or commercial lane that matches what your team needs next.

Try it now

Swap on Orkid

9 bps flat fee, gasless, MEV-protected. Live on Base, Ethereum, and Unichain. No ETH needed — the solver pays gas.

Open swap →

Launch overview

Read the launch brief

Start with the launch brief when the team needs the fastest summary of fit, trust, and the right next route through the site.

Read launch brief →

Technical packet

Review the Protocol Packet

If the post raised technical questions, move into the packet for the forwardable version of the core framework.

Review packet →

Shortlist and fit

Use comparisons or alternatives

When the question is no longer category education but shortlist fit, use the comparison surfaces to support an honest vendor evaluation.

See comparisons →
  • ZK Proving Systems Compared: Halo2, SP1, Plonky2, and STARKs

    ZK Proving Systems Compared: Halo2, SP1, Plonky2, and STARKs

    Eight zero-knowledge proving systems compared across proving time, proof size, verification, trusted setup, and ecosystem. A developer's guide to choosing a ZK system.

  • What Is Tokenized Credit Infrastructure?

    What Is Tokenized Credit Infrastructure?

    Tokenized credit is more than putting a loan on-chain. It is a full stack: SPV, token registry, compliance layer, and distribution. Here is how it works and why ERC-6909 matters.

  • What Is Surplus in DEX Aggregation?

    What Is Surplus in DEX Aggregation?

    When an aggregator routes your swap better than the quoted price, the difference is surplus. Some aggregators keep it. Some return it. Here is why that matters for your total cost.

  • What Is MEV and How to Protect Against It

    What Is MEV and How to Protect Against It

    Maximal extractable value costs DEX users millions. Here is what MEV is, how sandwich attacks work, and the four approaches to protection — private mempools, batch auctions, intent-based execution, and threshold encryption.

  • What Is ISO 20022 and Why It Matters for Blockchain

    What Is ISO 20022 and Why It Matters for Blockchain

    ISO 20022 is the global messaging standard for payments. Here is what it is, how it works, why banks are migrating to it, and what it means for blockchain settlement.

  • What Is Intent-Based Swap Execution?

    What Is Intent-Based Swap Execution?

    Intent-based execution lets users sign a message describing what they want, and solvers compete to fill it. Here is how the model works and why it's different from traditional DEX trading.

LLM Resource Index llms.txt