DEV Community: Michael Steuer

I Gave Claude the Ability to Trade on a DEX. Here's How It Works

Michael Steuer — Tue, 24 Mar 2026 22:10:41 +0000

Here's a simple question: Can an AI agent trade on a DEX without ever touching a private key?

Not read-only. Not "here's a price feed." Actually build a swap, sign it, submit it — end to end. And the answer, until now, was no.

Every DeFi MCP server I looked at fell into one of two camps:

Read-only — your agent can look at prices, maybe get a quote, but can't actually do anything
Custodial — hand over your keys and trust the server not to drain your wallet

Neither is acceptable. Read-only is a toy. Custodial is a liability. So we built a third option.

The Hard Problem: It's Not the DEX. It's the Keys.

The hard problem of agentic DeFi isn't connecting to a DEX. Any wrapper can do that. The hard problem is: who holds the keys?

CSPR.trade MCP does neither read-only nor custody. The agent builds the transaction remotely, your machine signs it locally, and keys never move. That's not a feature. That's the architecture.

Here's the flow:

┌──────────────┐      ┌───────────────────┐      ┌──────────────┐
│  AI Agent    │─────▶│  CSPR.trade MCP   │─────▶│  Casper DEX  │
│  (Claude,    │      │  Server           │      │  (on-chain)  │
│   Cursor,    │      │                   │      │              │
│   custom)    │◀─────│  Returns UNSIGNED │      │              │
└──────┬───────┘      │  transaction JSON │      └──────────────┘
       │              └───────────────────┘
       │
       ▼
┌───────────────┐
│  LOCAL SIGNER │  ← Keys live here. Nowhere else.
│  (your        │
│   machine)    │
└──────┬────────┘
       │
       ▼
  Submit signed tx → on-chain execution

The MCP server never sees your private key. It can't. It builds an unsigned deploy, hands it back to the agent, and the agent signs locally before submitting. Zero custody. Zero trust assumptions.

Try It: Two Servers, Zero Custody

Add this to Claude Desktop, Cursor, or any MCP client:

{
  "mcpServers": {
    "cspr-trade": {
      "url": "https://mcp.cspr.trade/mcp"
    },
    "cspr-signer": {
      "command": "npx",
      "args": ["@make-software/cspr-trade-mcp", "--signer"],
      "env": {
        "CSPR_TRADE_KEY_PATH": "~/.casper/secret_key.pem"
      }
    }
  }
}

Two servers, one architecture: the remote server handles market data and builds unsigned transactions. The local signer signs them with your key. Keys never leave your machine — and the remote server doesn't even have the signing tools. It can't touch your keys, by design.

No API key. No auth. No accounts. Just add the config and your agent can trade on CSPR.trade, the leading DEX on Casper Network.

Just want to explore? The remote server works standalone — skip cspr-signer and your agent gets full market data, quotes, and can build unsigned transactions. Add the signer when you're ready to execute.

What Your Agent Can Actually Do

14 tools, three categories:

See everything (no wallet needed):

get_tokens — all tokens with live prices
get_pairs — trading pairs with liquidity depth
get_pair_details — deep stats on any pair
get_quote — "How much WETH do I get for 10,000 CSPR?"
get_currencies — supported currencies
get_swap_history — any account's trade history
get_liquidity_positions — LP positions and value
get_impermanent_loss — calculate IL for any position

Build transactions (returns unsigned JSON):

build_swap — construct a swap deploy
build_approve_token — token approval for the router
build_add_liquidity — add to a liquidity pool
build_remove_liquidity — withdraw from a pool

Sign locally:

sign_deploy — sign with a local key (signer mode only)

Submit (back to remote server):

submit_transaction — broadcast the signed deploy to the Casper network

The key insight: your agent can freely explore market data and build transactions on the remote server. When it needs to sign, it crosses to the local signer — then the signed transaction goes back to the remote server for submission. Keys never leave your machine.

Walkthrough: Swapping 1000 CSPR for WETH

Here's what actually happens when you tell Claude "Swap 1000 CSPR for WETH":

Step 1 — Agent gets a quote (remote server)

→ get_quote(tokenIn: "CSPR", tokenOut: "WETH", amountIn: "1000")
← { amountOut: "0.285", priceImpact: "0.02%", route: [...] }

Step 2 — Agent builds the swap (remote server)

→ build_swap(
    publicKey: "02036d...",
    tokenIn: "CSPR",
    tokenOut: "WETH",
    amountIn: "1000",
    slippage: 0.5
  )
← { deploy: { ... unsigned transaction JSON ... } }

Step 3 — Local signing (local signer — your machine)

→ sign_deploy(deploy_json: "...", key_source: "pem_file")
← { signedDeploy: { ... } }

Step 4 — Submit (remote server)

→ submit_transaction(signed_deploy_json: "...")
← { deployHash: "a1b2c3...", status: "submitted" }

Notice the boundary: Steps 1-2 hit the remote server, Step 3 runs on the local signer, and Step 4 goes back to the remote server to submit. The signed transaction crosses back — but the private key never does. Your agent routes each tool call to the right server automatically.

Self-Hosting and Testnet

Want to run everything locally, or develop against testnet? Run the full server on your machine:

{
  "mcpServers": {
    "cspr-trade": {
      "command": "npx",
      "args": ["@make-software/cspr-trade-mcp"],
      "env": {
        "CSPR_TRADE_NETWORK": "testnet",
        "CSPR_TRADE_KEY_PATH": "~/.casper/secret_key.pem"
      }
    }
  }
}

In stdio mode, the full server includes all tools — market data, transaction building, signing, and submission — in a single process. Your keys stay local because the server is local.

The SDK is also available separately for custom integrations:

npm install @make-software/cspr-trade-mcp-sdk

Why This Matters Beyond Casper

Every blockchain is going to face this problem. As AI agents get more capable, they'll need to interact with DeFi — and the custody question doesn't go away just because the agent is smarter.

The pattern we're using here — build remote, sign local — isn't Casper-specific. It's a design pattern for any chain where you want agents to transact without surrendering keys. We just shipped it first.

Context: Casper v2.2.0

This ships the same week Casper Network upgraded to v2.2.0 on mainnet. The v2.2.0 release marks a notable protocol upgrade, and CSPR.trade MCP is the first DeFi MCP server built for it. If you want to see what building on Casper looks like right now — this is it.

OpenClaw Skill

Using OpenClaw? Install the skill from ClawHub and your agent gets the full workflow guide — intent classification, signing flows, safety checks — baked in:

npx clawhub@latest install cspr-trade-mcp

The skill teaches your agent how to use the 14 tools: when to get a quote before building a swap, when to warn about price impact, how to handle local signing vs external wallets. It's the difference between "here are 14 tools, good luck" and "here's how a DeFi agent should behave."

Why We Built Edicts

Michael Steuer — Sun, 22 Mar 2026 23:46:19 +0000

A lot of agent failures do not come from reasoning. They come from certainty.

An agent will happily draft a convincing answer, a polished status update, or a perfectly formatted post while being wrong about the one fact that actually matters. The launch date is off by a week. The product has a feature it does not have. The company policy is described backwards. The partner name that should stay private ends up in public copy because the model found a familiar pattern in its training data and filled in the blank with confidence.

One example was painfully small: an agent prepared public copy that referenced the wrong version number. The current version was known. The team had already agreed on it. It existed in Slack, docs, release notes, and someone’s head. But “known somewhere” is not the same as “available cheaply, reliably, every time the model speaks.”

That distinction is where Edicts came from.

The problem was not memory in the broad sense

There are already good tools for memory.

If you want long-horizon conversational recall, there are products built around that. If you want graph-shaped knowledge with deeper semantic retrieval, there are products built around that too. If you want a full RAG pipeline over manuals, tickets, PDFs, and scattered internal docs, plenty of tooling already exists.

But we kept running into a narrower problem.

Agents often need a tiny set of high-value facts that should always win:

the current release number
the public launch date
a hard compliance constraint
a negative assertion like “this product does not support gas sponsorship”
a temporary operational constraint like “writes are disabled during the migration window”

Those are not documents. They are not embeddings-worthy paragraphs. They are not knowledge graphs. They are not “memory” in the warm, human, conversational sense.

They are ground truth.

And ground truth should be cheap.

The existing options were either too heavy or too sloppy

We kept seeing four unsatisfying patterns.

1. System prompt stuffing

The fastest solution is to keep appending more context to the system prompt until the prompt looks like a family garage after twenty years: technically still functional, impossible to search, and full of things nobody wants to carry every single time.

Important facts get buried. Token cost drifts upward. Temporary facts linger forever. Contradictory updates accumulate. The model receives a wall of prose instead of a disciplined set of assertions.

2. RAG for tiny facts

RAG is powerful when you genuinely need retrieval across large corpora. But if your real need is “always remind the model that feature X does not exist,” wiring a retrieval pipeline around that is like installing airport security to protect a sandwich.

It solves a bigger class of problems than the one you have, and you pay for that ambition in complexity.

3. Conversational memory systems

Conversational memory systems are designed for a different kind of job: recall from interactions, preferences, patterns, personal details, and accumulated conversational context. Useful job. Wrong tool for non-negotiable product facts.

We did not want a system inferring which launch timing statement mattered most. We wanted a place to write the launch timing statement down and make it authoritative.

4. Knowledge graphs for everything

Knowledge-graph-heavy approaches become interesting when your domain genuinely needs relationships, entities, traversals, and deeper structured reasoning. But a surprising amount of agent reality is flatter than that.

Most production-critical facts are just assertions with a few pieces of metadata:

category
confidence
source
expiration
optional supersession key

That is it. A lot of the time, that is enough.

The insight was embarrassingly simple

We did not need a grand theory of memory.

We needed a tiny layer for flat, verified assertions that could be:

stored on disk
rendered cheaply into prompts
updated safely
expired automatically
small enough to keep around all the time

That became Edicts.

An edict is just a statement plus metadata. Not a transcript. Not a vector. Not a graph node. A statement.

For example:

“Product v2.0 launches April 15, NOT before.”
“Do not name unannounced design partners publicly.”
“Enterprise plan does NOT include white-label support.”
“User-profile writes are disabled during the migration window.”

Each one can carry a category, tags, confidence, provenance, and a TTL. That is enough structure to make the facts operational without turning them into a tiny enterprise software project.

We optimized for token cost on purpose

A big part of the design came from refusing to treat every fact like a document retrieval problem.

If an edict averages around a dozen useful tokens of actual semantic payload, you can afford to inject several of them into every prompt. That matters. Reliability often comes from repetition. The model should not have to go hunting for the facts that would make a public answer safe.

The goal is not to build the most sophisticated memory substrate in the world. The goal is to make the right facts cheap enough to always be present.

That changes behavior. Teams stop hoarding facts in docs nobody injects. They stop relying on the agent to “remember from last time.” They stop pretending that a compliance rule mentioned three tools ago will still be salient when the agent writes the public-facing answer.

Where Edicts sits in the memory hierarchy

We think of agent memory as a hierarchy, not a winner-take-all battle.

At the bottom, you have immediate working context: the current turn, the current task, the current prompt.

Above that, you have Edicts: compact, verified, operational truths that should travel with the agent because they are cheap and important.

Above that, you may have richer recall systems: transcripts, summaries, vector stores, graphs, document retrieval, long-term conversational memory.

Those systems are not enemies of Edicts. They solve different problems.

Edicts is the layer you use when the question is not “what might be relevant?” but “what must stay true?”

Production taught us a few lessons quickly

The first lesson was that negative assertions are gold.

People naturally document what exists. Agents hallucinate most dangerously around what does not exist. If your product does not support a feature, say that explicitly. If a name should never be used publicly, say that explicitly. If an inferred capability is false, write the counter-fact down.

The second lesson was TTL hygiene.

Temporary truths become permanent lies if you never expire them. Migration windows end. freezes end. launch embargoes end. “For the next 48 hours” is not a category; it is a lifecycle. Edicts bakes that lifecycle into the model. Ephemeral and event-based facts are not a social contract. They actually expire.

The third lesson was key-based supersession.

Facts that change over time should not pile up like geological layers in a prompt. If the current release is now v2.4.2, that should supersede v2.4.1, not sit next to it and ask the model to infer chronology from vibes. Stable keys give you clean replacement and a history trail without prompt clutter.

The fourth lesson was that simple storage wins.

YAML and JSON are boring. That is the compliment. You can read them, diff them, commit them, inspect them in production, and repair them without an archaeology team. We did not want ground truth trapped in a black box.

We also wanted framework agnosticism to be real, not marketing copy

A lot of “framework-agnostic” products are framework-agnostic in a very theoretical sense: technically possible, but not the default experience.

We wanted Edicts to be genuinely usable anywhere.

If your stack can:

load a file,
prepend text to a system prompt, and
optionally expose function calls,

then you can integrate Edicts.

That is why the core stays small and boring. OpenClaw has a first-party integration because it is useful, but the store itself does not depend on OpenClaw or any orchestration framework.

Getting started with OpenClaw

If you are running OpenClaw, Edicts has a first-party plugin that handles everything: injection, tool registration, and file bootstrapping.

Install and restart:

openclaw plugins install openclaw-plugin-edicts
openclaw gateway restart

That is it. On first load, the plugin creates an edicts.yaml file in your workspace. Every agent session — main chat, cron jobs, sub-agents, every channel — gets the edicts prepended to its system prompt automatically. No per-session wiring.

Your agents also get tools (edicts_add, edicts_list, edicts_update, edicts_remove, edicts_search, edicts_stats, edicts_review) so they can manage edicts conversationally. Say "remember that v2.2.0 launches March 23" and the agent writes it to the store.

You can also edit edicts.yaml by hand. It is a plain YAML file:

version: 1
edicts:
  - id: e_001
    text: "Product v2.2.0 launches March 23, 2026."
    category: product
    ttl: event
    key: product-launch-date

If you are not on OpenClaw, install the standalone library:

npm install edicts
edicts init        # creates starter edicts.yaml
edicts add "Feature X does NOT support gas sponsorship" --category product
edicts list

The core library has zero framework dependencies. Any agent system that can prepend text to a system prompt can use it.

What Edicts is not

Edicts is not an attempt to replace RAG.

It is not a general-purpose knowledge graph.

It is not a substitute for long-term conversational memory.

It is not trying to solve every memory problem an agent could ever have.

We wanted a tool that knows exactly which problem it is solving: compact ground truth for agents.

Why we think this matters

As agent systems become more common, a lot of reliability work will come down to memory discipline rather than model cleverness.

Most public-facing or operational mistakes are not the result of deep reasoning failure. They are the result of missing or stale facts. A model that can reason beautifully on top of bad premises is still a liability.

Edicts is our attempt to make that layer boring, explicit, and cheap.

Not glamorous. Just useful.

If you need a small set of verified truths to follow your agents around without dragging a wagon of context behind them, that is exactly what we built.

Docs: https://edicts.ai
GitHub: https://github.com/edicts-ai/edicts
License: MIT

Opening the Playbook: Why We're Open-Sourcing Casper's Core DeFi Infrastructure

Michael Steuer — Thu, 19 Mar 2026 18:30:15 +0000

Four production systems, security-audited by Halborn, open-sourced in one week. A naming service, a decentralized exchange, liquid staking, and EIP-712 typed signatures. All live on mainnet. All yours now.

Earlier this week, I open-sourced casper-eip-712, a Rust crate that brings Ethereum's typed signing standard to Casper. I wrote about why we did it, what it unlocks, and how it started with a security auditor telling us we had a gap.

That was yesterday. We weren't done.

Today I'm announcing that we've open-sourced three additional contract repositories that power core DeFi infrastructure on Casper Network:

cspr-name-contracts: the smart contracts behind CSPR.name, Casper's decentralized naming service
casper-trade: the DEX contracts powering CSPR.trade, a Uniswap V2-style automated market maker
liquid-staking-contracts: the liquid staking protocol behind casper.wiselending.com, enabling staked CSPR to remain liquid as sCSPR

These aren't proofs of concept. They're not hackathon projects gathering dust. Each of these repositories powers a live product with real users on Casper mainnet right now. And critically, each has been independently security-audited by Halborn, one of the leading blockchain security firms in the industry:

Production-deployed, battle-tested, and security-audited. That's the bar we're setting for what "open source" means on Casper.

Why Open-Source, Why Now

Let me be direct about the motivation. Casper Network is an open-source Layer 1 blockchain with decentralized community governance. The protocol is open. The node software is open. The SDK is open. But until now, the production-grade application contracts, the ones that actually demonstrate how to build real things on Casper, weren't.

That's a gap. And it's the kind of gap that makes life harder for builders.

If you wanted to build a naming service on Casper, you'd start from scratch. If you wanted to build a DEX, you'd reverse-engineer how AMMs work on EVM chains and figure out how to translate that to Casper's architecture. If you wanted to implement liquid staking, you'd be pioneering patterns that someone had already solved, just behind closed doors.

We're opening those doors.

The timing matters, too. Casper's v2.2.0 mainnet upgrade launches on March 23rd. Validators are already staging, with 83% of stake staged and climbing. The protocol is evolving. Upgradeable smart contracts, improved developer ergonomics, a maturing DeFi stack. But none of that matters if builders don't have the reference material, the production-tested patterns, and the working code to build on.

Open-sourcing these repositories isn't an act of charity. It's infrastructure investment. It's saying: "Here's how we solved naming, liquidity, staking, and typed signatures on Casper. Take it. Learn from it. Build on it. Make it better."

Three Teams, One Commons

One thing worth highlighting: these four repositories come from three different organizations.

make-software (MAKE) hosts the CSPR.name contracts
odradev (Odra) built the CSPR.trade DEX
casper-ecosystem hosts the liquid staking contracts and casper-eip-712

This is how we operate. The Casper Association doesn't build everything in-house. It functions as an ecosystem orchestrator, ensuring that different teams across the ecosystem contribute to, collaborate on, and benefit from shared infrastructure. MAKE, Odra, WiseLending: each team brings deep expertise in their domain. The Association's job is to make sure that expertise compounds instead of staying siloed.

Open-sourcing these repositories is a concrete expression of that philosophy. Three teams, four repos, one ecosystem commons.

The Framework That Runs the Stack

Three of the four repositories are built entirely with Odra, the Rust-native smart contract framework for Casper. The fourth, casper-eip-712, is a vanilla Rust crate by design (it needs to work in any environment, including no_std). But we built its demo project, a full CEP-18 token with gasless permit/approve, in Odra specifically to demonstrate how the vanilla crate integrates with the framework.

If you're not familiar with Odra: think of it as what OpenZeppelin provides for the EVM ecosystem, but more comprehensive and designed from the ground up for Casper's architecture. Odra handles the contract lifecycle, testing infrastructure, deployment tooling, and factory patterns, so you can focus on your application logic rather than blockchain plumbing.

The fact that three production DeFi systems were built with Odra, and the fourth integrates seamlessly, is itself a strong signal. A naming protocol, a full Uniswap V2 port, and a liquid staking system with protocol-level integration, all built, tested, audited, deployed, and running in production using the same framework.

For developers considering Casper, these repos serve as a real-world Odra curriculum:

cspr-name-contracts demonstrates domain registration, resolution, and the tradable NFT-like ownership model
casper-trade shows how to port a battle-tested EVM design (Uniswap V2) to Casper, including Odra's factory pattern for runtime contract deployment, which is a genuinely different approach from EVM's create2
liquid-staking-contracts illustrates protocol-level integration, the sCSPR liquid token pattern, and Gherkin-style BDD tests
casper-eip-712 demonstrates how standalone Rust crates integrate with Odra contracts in production

Under the Hood

CSPR.name: Decentralized Naming for Casper

Repository: make-software/cspr-name-contracts | Halborn audit
Live product: CSPR.name

14c8b2f09ad2ef34c23bff91d52e6f48cbd714ea1fa8b3e71d26547ebfd1229c

That's a Casper account hash. Try sending tokens to it from memory. Now try sending tokens to michael.cspr. That's the problem CSPR.name solves.

CSPR.name is Casper's official naming service. It replaces cryptographic account hashes with human-readable .cspr names, making the entire ecosystem more navigable. Register a name, and it becomes your on-chain identity, recognized across CSPR.live, Casper Wallet, dApps, and the broader ecosystem.

But CSPR.name goes beyond simple name-to-address resolution. As of the latest release, names are fully tradable on CSPR.market. You can buy, sell, and make purchase offers for names. Your .cspr name isn't just a convenience. It's a digital asset.

What developers can learn from this repo:

Name registration and resolution contract architecture using Odra
Tradable naming rights: turning registered names into transferable assets
Integration with marketplace contracts
Using cargo odra build and cargo odra test for the full development lifecycle

# Clone and run tests locally
git clone https://github.com/make-software/cspr-name-contracts
cd cspr-name-contracts
cp .env.example .env
cargo odra test

CSPR.trade: Native Decentralized Exchange

Repository: odradev/casper-trade | Halborn audit
Live product: CSPR.trade

CSPR.trade is Casper's native DEX, a Uniswap V2-style automated market maker built specifically for Casper's architecture. It provides token swaps, liquidity pools, and yield farming. With deterministic finality and non-custodial execution, every swap, pool rebalance, and fee distribution is verifiable on-chain.

What makes this repo particularly interesting for developers is how faithfully it ports the Uniswap V2 architecture while handling the fundamental differences between EVM and Casper:

The factory pattern: On Ethereum, Uniswap's factory deploys Pair contracts using create2 with the Pair bytecode stored in the Factory. Casper doesn't have create2. Instead, Odra provides a factory=on directive that auto-generates a PairFactory contract. The PairFactory's sole purpose is managing deployments and upgrades of Pair contracts. Factory calls factory() on PairFactory, which deploys a new Pair and returns its address.

This is one of those architectural differences that would take a team weeks to figure out from scratch. Now it's documented, tested, audited, and open.

Test parity: The tests are based directly on the original Uniswap V2 test suites (UniswapV2Router01.spec.ts, UniswapV2Router02.spec.ts, UniswapV2Factory.spec.ts, and UniswapV2Pair.spec.ts). This isn't a loose reimplementation; it's a faithful port with behavioral verification against the original.

Contract architecture:

Pair: The AMM pair contract (deployed by PairFactory, not directly). Corresponds to UniswapV2Pair.
PairFactory: Auto-generated by Odra. Responsible for deploying and upgrading Pair contracts.
Router: Corresponds to UniswapV2Router. Entry point for swaps and liquidity operations.
Factory: Pair management. Corresponds to UniswapV2Factory.
WrappedNativeToken: From Odra modules, wraps native CSPR for use in AMM pools.

# Clone, install, and test
git clone https://github.com/odradev/casper-trade
cd casper-trade
cargo install cargo-odra
just test

Liquid Staking: The StakedCSPR Protocol

Repository: casper-ecosystem/liquid-staking-contracts | Halborn audit
Live product: casper.wiselending.com

Here's the staking dilemma every Proof-of-Stake network faces: users who stake their tokens to secure the network get their capital locked up. They earn rewards, but they lose liquidity. They can't use those tokens in DeFi. They can't respond to market conditions without waiting through unbonding periods. So they face a choice: security or liquidity.

Liquid staking removes that choice.

When you stake CSPR through the liquid staking protocol, you receive sCSPR, a liquid token that represents your staked position. Your original CSPR stays staked and continues earning network rewards. Meanwhile, sCSPR is freely transferable. You can use it in CSPR.trade pools. You can use it as collateral. Your capital works in two places at once.

On Casper, this isn't a third-party bolt-on. It's built with protocol-level awareness, in collaboration with WiseLending. No custodians, no synthetic wrappers, no workarounds that bypass the base layer.

What makes this repo especially valuable for developers:

The StakedCSPR token contract implementation, a real-world example of a liquid representation token
Gherkin-style BDD test specifications in the tests/features folder, showing how to write readable, verifiable test suites for complex DeFi logic
Full CLI tooling for deployment and interaction
Protocol-level staking integration patterns

# Clone and test
git clone https://github.com/casper-ecosystem/liquid-staking-contracts
cd liquid-staking-contracts
just test

# Deploy to testnet (configure .env first)
just build-contracts
just cli deploy

What This Means for Builders

Let me be concrete about what you can do with these repositories today:

If you want to build a naming service on another domain, fork cspr-name-contracts. The architecture handles registration, resolution, renewal, and marketplace integration. Adapt the domain logic to your use case.

If you want to build a DEX or AMM on Casper, casper-trade gives you a production-tested, Halborn-audited Uniswap V2 implementation. Add new pool types, modify fee structures, build a frontend. The hard contract work is done.

If you want to incorporate liquid staking functionality in your dApp, liquid-staking-contracts shows you the pattern. Whether you're building a lending protocol, a yield optimizer, or anything that benefits from compounding staking rewards alongside your application's native functionality, the sCSPR token design, the staking/unstaking flow, and the reward distribution logic are all there.

If you need typed signatures for any cross-chain, gasless, or multi-party signing use case, casper-eip-712 handles encoding, hashing, domain separation, and verification. Drop it in as a crate dependency.

If you're learning Odra, these repos are your graduate-level coursework. Registration systems, AMMs, staking protocols, cryptographic primitives. Each demonstrates different Odra patterns in production context, with Halborn audits that serve as implicit code quality benchmarks.

The Broader Picture

When I wrote about building CSPR.guru a few months ago, I made the case that Casper's developer experience, powered by Odra, CSPR.click, CSPR.cloud, and the rest of MAKE's toolchain, is genuinely best-in-class. I built a full prediction market, solo, in my spare evenings, using only Casper ecosystem tools.

But I also know that "best-in-class tools" means nothing if builders can't see what production-grade code looks like on your platform. Documentation gets you started. Tutorials teach you patterns. But nothing replaces reading real code that runs in production, serving real users, handling real money, and surviving a Halborn audit.

That's what these repositories provide. Not examples. Not templates. Production systems with the security receipts to prove it.

Four repos. Three teams. Three Halborn audits. One ecosystem.

As we approach the v2.2.0 mainnet upgrade on March 23rd, with 83% of stake already staged, we're not just upgrading the protocol. We're opening the entire application layer. The code that powers Casper's DeFi infrastructure is now the same code you can fork, study, extend, and deploy.

Build something.

Repositories:

casper-eip-712: EIP-712 typed signatures for Casper
cspr-name-contracts: CSPR.name decentralized naming protocol
casper-trade: Uniswap V2-style DEX for Casper
liquid-staking-contracts: Liquid staking with StakedCSPR

Security audits:

Live products:

CSPR.name | CSPR.trade | Liquid Staking | CSPRbridge

Learn more:

Why We Brought Ethereum's Most Important Signing Standard to Casper

Michael Steuer — Tue, 17 Mar 2026 19:20:41 +0000

Every blockchain that wants to play in the big leagues (cross-chain bridges, gasless transactions, AI agents moving money on your behalf) needs EIP-712. It's the standard that makes typed, domain-separated signatures possible. Ethereum figured this out years ago. Uniswap uses it. Aave uses it. OpenSea uses it. It's the plumbing behind every "approve without paying gas" interaction you've ever done on an EVM chain.

Casper has it now.

This isn't something we planned on a roadmap six months ago. It started the way the best infrastructure usually starts: with a security auditor telling us we had a gap. During the Halborn security audit of CSPRbridge.com, our cross-chain bridge connecting Casper to EVM networks, the auditors flagged that our attestation verification was using ad-hoc signature encoding. Custom encodePacked-style hashing, hand-rolled for each message type. It worked, but it was brittle, non-standard, and the kind of thing that keeps security engineers up at night.

We could have patched the finding and moved on. That's what most teams do: fix the specific issue, close the ticket, ship the update. Instead, we asked ourselves: "If this is a gap in the bridge, isn't it a gap in the entire ecosystem?" The answer was yes. So we built infrastructure.

Why Roll-Your-Own Signatures Fail

Here's a scenario that plays out more often than anyone in crypto likes to admit. A team builds a bridge, or a cross-chain messaging protocol, or a multi-chain dApp. They need signatures: attestations that something happened on Chain A, verified on Chain B. So they roll their own encoding. They pick a hash function, concatenate some fields, maybe add a prefix. Ship it.

Then someone replays a signature from testnet on mainnet. Or submits an attestation meant for the ERC-20 locker contract against the NFT bridge. Or finds that the "domain" is just the contract name hard-coded as a string, with nothing tying the signature to a specific deployment.

This is what domain separation solves, and it's what the ad-hoc approach almost always gets wrong. When every project invents its own encoding, you get inconsistency, incompatibility between systems, and attack surfaces that are invisible until someone exploits them.

Security auditors don't tell you what's nice to have. They tell you what will get you exploited.

That Halborn audit was the catalyst. The bridge's attestation verification was using raw keccak256 with encodePacked-style concatenation: four different hash functions, each assembling bytes manually for different message types. Functional? Yes. Standardized? No. Upgradeable without breaking every deployed relayer? Absolutely not.

We decided that if we were going to fix the bridge, we'd fix it for the whole ecosystem.

What EIP-712 Is and Why Ethereum Got It Right

If you've been building on Ethereum, you've already used EIP-712, even if you didn't know it by name. Every time you've signed a "permit" in MetaMask and seen a nicely formatted breakdown of what you're approving (the token, the spender, the amount), that's EIP-712 at work.

Before EIP-712, signing on Ethereum meant signing opaque byte blobs. Your wallet would show you a hex string and essentially ask: "Do you trust this?" The answer should always have been "no," but people clicked "sign" anyway. EIP-712 changed this by introducing typed structured data hashing:

Human-readable in wallets. Instead of a hex blob, users see the actual fields they're signing: token name, amount, recipient, deadline. The wallet can display this because the data has a schema.

Domain-separated. Every signature is bound to a specific domain: a contract address, a chain ID, a protocol version. A signature for Uniswap on Ethereum mainnet cannot be replayed against a copycat contract on Arbitrum. The domain is baked into the hash.

Machine-verifiable. Smart contracts can reconstruct the exact hash from the typed data, recover the signer, and verify the authorization on-chain. No ambiguity, no parsing, no custom deserialization logic.

This combination is why EIP-712 became the backbone of gasless approvals (ERC-2612), meta-transactions, and most of modern DeFi's authorization infrastructure. Uniswap's Permit2 uses it to let users approve token spending with a signature instead of a transaction. Aave uses it for credit delegation. OpenSea used it for gasless NFT listings. The pattern is always the same: user signs structured data off-chain, contract verifies on-chain, and the domain separator ensures that signature can't be replayed anywhere it wasn't intended.

It's not just a convenience. It's a security primitive. And it's the kind of standard that separates blockchains that are ready for real-world financial applications from those that aren't.

If you're building on Casper, you're about to start using it too.

How We Brought EIP-712 to Casper

casper-eip-712 is a no_std-compatible Rust crate that brings the full EIP-712 toolkit to Casper. It gives you domain construction, typed struct hashing, encoding helpers, and optional secp256k1 signer recovery. Everything you need to implement the same signature patterns that power the EVM ecosystem.

Building a Domain

The DomainBuilder supports both standard EVM fields and Casper-native extensions:

use casper_eip_712::prelude::*;

// EVM-compatible domain, interoperable with ethers.js and MetaMask
let domain = DomainBuilder::new()
    .name("MyToken")
    .version("1")
    .chain_id(1)
    .verifying_contract([0x11; 20])
    .build();

// Casper-native domain: uses chain_name and contract_package_hash
let domain = DomainBuilder::new()
    .name("Bridge")
    .version("1")
    .custom_field("chain_name", DomainFieldValue::String("casper-test".into()))
    .custom_field("contract_package_hash", DomainFieldValue::Bytes32([0x99; 32]))
    .build();

That dual-domain support is intentional. If you're building a bridge that verifies Ethereum-origin signatures, use the EVM-compatible domain. If you're building a Casper-native dApp and want domain fields that make sense for Casper (like chain_name and contract_package_hash instead of integer chain IDs and 20-byte addresses), use the custom fields. Same hashing algorithm, same security properties, native semantics for each chain.

Defining Custom Typed Structs

Any struct can be EIP-712 hashable by implementing the Eip712Struct trait:

struct Attestation {
    subject: [u8; 20],
    claim_hash: [u8; 32],
}

impl Eip712Struct for Attestation {
    fn type_string() -> &'static str {
        "Attestation(address subject,bytes32 claim_hash)"
    }

    fn type_hash() -> [u8; 32] {
        keccak256(Self::type_string().as_bytes())
    }

    fn encode_data(&self) -> Vec<u8> {
        let mut out = Vec::with_capacity(64);
        out.extend_from_slice(&encode_address(self.subject));
        out.extend_from_slice(&encode_bytes32(self.claim_hash));
        out
    }
}

Then hashing is one line:

let digest = hash_typed_data(&domain, &attestation);

The crate ships with prebuilt Permit, Approval, and Transfer structs for common patterns, so you don't have to implement these yourself for standard use cases.

Design Decisions

A few things worth noting:

no_std + alloc: The crate is designed for WASM-based contract targets. It works inside Casper smart contracts without pulling in std.
Optional verify feature: Enable verify in your Cargo.toml to get secp256k1 signer recovery via k256. Leave it off if you only need hashing.
Framework-agnostic: We built casper-eip-712 as a standalone Rust crate, not as a module for any specific framework. This was intentional: any Casper contract can use it, regardless of tooling. But since most contracts on Casper today are developed using Odra, the rapid-development smart contracting framework, we made sure it integrates seamlessly. Add it to your Cargo.toml, import the prelude, and you're signing.

Real-World Usage: The Bridge

Remember that Halborn audit? Here's the payoff.

The CSPRbridge.com cross-chain bridge connects Casper to EVM networks. Its core security mechanism is multi-relayer attestation: when tokens move between chains, a threshold of relayers must sign an attestation confirming the transaction. The Casper-side contract then verifies these signatures before minting or releasing tokens.

Before casper-eip-712, this verification used hand-rolled encoding: four separate hash functions in crypto.rs, each manually assembling bytes with keccak256 and encodePacked-style concatenation. Each one was correct for its specific message type, but each was also bespoke. No shared schema. No domain binding per deployment. No way for a wallet or monitoring tool to introspect what was being signed.

The audit identified the gap: signatures weren't bound to a specific contract deployment. An attestation for one bridge instance could theoretically be replayed against another. It also flagged the lack of a standardized encoding scheme, which made the system harder to audit, harder to extend, and harder to reason about.

We didn't just patch the finding. We built infrastructure so that every project on Casper gets this right by default. The bridge is migrating its attestation verification to casper-eip-712, binding every signature to a specific chain, contract, and protocol version. What used to be four custom hash functions becomes one standard pattern. And critically, any new message type the bridge needs to support (new token standards, new cross-chain operations) follows the same trait implementation. Add your struct, implement Eip712Struct, and the hashing, encoding, and verification are handled.

This is what I mean when I say we built infrastructure, not a patch. The next team that builds a bridge, an oracle, or any system that needs cross-chain attestations on Casper doesn't have to solve this problem again.

The TypeScript Companion

Smart contracts verify signatures. But someone has to create them first, and that someone is usually a frontend developer writing TypeScript.

@casper-ecosystem/casper-eip-712 is the TypeScript mirror of the Rust crate. It provides the same domain construction, type hashing, and encoding functions, plus signer recovery for client-side verification:

import {
  hashTypedData,
  recoverTypedDataSigner,
  PermitTypes,
  type EIP712Domain,
  type PermitMessage,
} from "@casper-ecosystem/casper-eip-712";

const domain: EIP712Domain = {
  name: "PermitToken",
  version: "1",
  chainId: 1314614895,
  verifyingContract: contractAddress,
};

const permit: PermitMessage = {
  owner: wallet.address,
  spender: spenderAddress,
  value: "0x" + (1000n).toString(16).padStart(64, "0"),
  nonce: "0x" + "0".padStart(64, "0"),
  deadline: "0x" + (0xffffffffn).toString(16).padStart(64, "0"),
};

// Sign with ethers.js, standard Ethereum tooling
const signature = await wallet.signTypedData(domain, PermitTypes, permitPayload);

// Verify locally before submitting to chain
const digest = hashTypedData(domain, PermitTypes, "Permit", permit);
const recovered = recoverTypedDataSigner(domain, PermitTypes, "Permit", permit, sigBytes);

Frontend devs don't need to touch Rust. The TypeScript package produces the exact same hashes and digests as the Rust crate, verified by shared test vectors generated from a single source of truth. Sign in the browser, verify on Casper.

Demo: The Permit/Approve Pattern in Action

Talk is cheap. Let me show you.

The examples/permit-token directory contains a complete working CEP-18 token with gasless permit/approve, the same pattern that powers Uniswap's token approvals, now running on Casper.

Here's what happens:

A user signs a Permit off-chain using standard Ethereum tooling (ethers.js signTypedData). Zero cost. No transaction.
A relayer submits the signature to the Casper contract, paying the deploy cost on the user's behalf.
The contract verifies the EIP-712 signature, recovers the signer's Ethereum address, checks the nonce and deadline, and writes the token allowance. All without the token owner ever submitting a transaction.

The demo is a CEP-18 token built with Odra. The EIP-712 permit pattern drops in as a regular crate dependency. No special adapters, no glue code. Odra handles the smart contract scaffolding; casper-eip-712 handles the cryptographic verification.

Run the Rust tests:

cd examples/permit-token
cargo odra test

Run the TypeScript demo:

cd js && npm install && npm run build && cd ..
cd examples/permit-token/demo
npm install
npx tsx demo.ts

You can run this demo without a Casper node. Right now. Go.

The TypeScript demo generates a keypair, signs a permit using ethers.js, verifies it client-side with our TypeScript package, and shows you exactly what the on-chain contract call would look like: the 65-byte signature, the reconstructed digest, and the recovered signer address. The Rust integration tests do the full round-trip inside an Odra test environment: deploy the contract, sign a permit, submit it, verify the allowance was set, and confirm that invalid signatures, expired deadlines, and replayed nonces are rejected.

What This Unlocks for Casper

I didn't write a Rust crate because I was bored on a Saturday night. (Well, partially. But mostly for what it enables.)

Gasless Transactions and Relayer Services

The number one UX barrier in crypto is "buy gas first." A new user wants to use your dApp. They don't own CSPR. Under the current model, they bounce. With EIP-712 permits and a relayer service, that user signs an authorization off-chain (free) and the relayer submits it on their behalf, paying the deploy cost. The user interacts with Casper without ever acquiring CSPR upfront. This is how you onboard the next million users. By not asking them to figure out gas fees before they can do anything useful.

Agentic Commerce via x402

The x402 protocol is enabling AI agents to pay for API access and services using HTTP 402 payment flows with stablecoins. Think about that for a second. Autonomous agents, making purchasing decisions, signing payment authorizations. EIP-712 is the natural signing layer for this: structured, domain-separated, human-auditable authorizations that smart contracts can verify. As x402 comes to Casper, casper-eip-712 provides the cryptographic foundation for agents to sign verifiable, scoped authorizations. Not opaque byte blobs. Typed, structured data with clear semantics that a compliance system, a monitoring tool, or a human can read and understand.

Cross-Chain Interoperability

In a multi-chain world, domain separation isn't a nice-to-have. It's a security requirement. A signature for your mainnet bridge deployment must not be valid against your testnet deployment. An attestation for the ERC-20 locker must not work against the NFT bridge. casper-eip-712's DomainBuilder supports hybrid environments natively: EVM-standard fields for Ethereum-origin signatures, Casper-native fields for Casper-native protocols, and the flexibility to mix custom fields for whatever your architecture needs.

Batch Authorization

A relayer collects signed permits from multiple users and submits them in a single deploy. Users get instant, gasless interactions. The relayer amortizes deploy costs. Smart contracts verify each signature independently. This pattern is already standard on Ethereum (Uniswap's Permit2, for example). Now it works on Casper.

Non-Crypto-Native Onboarding

Let's be blunt: the current onboarding flow for most blockchain applications is terrible. I wrote about this extensively: the "connect your wallet" gauntlet, the gas token requirement, the 24-word seed phrase anxiety. EIP-712 is a key piece of the puzzle for fixing this. Combined with a relayer architecture, you can build Casper dApps where the user never sees a wallet popup, never buys gas, and never knows they're interacting with a blockchain. They sign a message, a message they can actually read and understand, and the relayer handles the rest. That's the user experience that gets us from 420 million crypto users to a billion.

The Big Picture

This isn't just a library. It's a building block that positions Casper to compete for the next wave of adoption, the wave where users don't know they're using a blockchain, and AI agents transact on their behalf. Gasless UX, agentic commerce, cross-chain interop, batch transactions: these are the patterns that the most successful chains will support natively. casper-eip-712 gives Casper that foundation.

When I look at where crypto is headed (account abstraction, intent-based architectures, agent-driven commerce), every one of those paths runs through structured, domain-separated signing. We're not building for where blockchain is today. We're building for where it's going.

Build With Us

The crate is open source, published, and ready to use:

GitHub: casper-ecosystem/casper-eip-712
Rust Crate: crates.io/crates/casper-eip-712
NPM Package: @casper-ecosystem/casper-eip-712
Rust Docs: docs.rs/casper-eip-712
Working Demo: examples/permit-token

If you're building on Casper, use it. If you're building on Ethereum and wondering what else is out there, try it. The signatures are the same.