DEV Community: Casper Blockchain

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."

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.

Casper CEP-78 Enhanced NFT Standard

Jonas Pauli — Fri, 21 Oct 2022 18:41:32 +0000

Introduction
Most people only have experience with NFTs in the form of JPEGs and art collections, despite the wide variety of use-cases beyond this implementation. The new enhanced NFT standard on Casper is designed to support more than ordinary NFT collections and even allows for developers to associate real world objects with digital representations in the form of NFTs on the blockchain.

There are now three different "metadata_types":

Physical: The NFT represents a real-world physical item e.g a house.
Digital: The NFT represents a digital item, e.g a unique JPEG or a digital art.
Virtual: The NFT is the virtual representation of a physical notion, e.g a patent or copyright.

This article introduces the Casper Cep-78 token standard, which is an upgrade of the deprecated Cep-47 standard. Essentially, the Cep-78 token standard is more flexible and supports “modalities”.

Casper NFT Visualizer
Thanks to the casper-signer and the casper-javascript-sdk, building Dapps on Casper is achievable. To showcase this, I built a “Casper-Sandbox” demo application using React that is open source and can be found here. If you want to install and test the react app follow the setup guide. You will need React and Node.js to run the app.

The “Casper-Sandbox” is an open-source NFT visualizer built to demonstrate some of the capabilities of the Casper Blockchain and the CEP-78 Standard. The app is still under development but already supports minting of “digital” NFTs. The readme includes the latest documentation for the project.
Metadata
The structure of an NFTs metadata is defined by a json schema. Cep-78 supports both standardized and custom json schemes. Standardized schemes are easier to integrate, whilst custom schemes can be individualized to suit a projects needs best.
An example for a standardized json schema (CEP78):

{
  "name": "Example NFT",
  "token_uri": "https://SOME_BACKEND/id",
  "checksum":
"SOME_CHECKSUM"
}

In this example the webserver at "token_uri" should return json data containing all relevant information regarding the NFT, such as a url to the image/jpg file, name and description.

Alternatively, one could define a custom metadata schema to store binary data instead of a weblink as the NFTs metadata.

An example of custom metadata:

{
   "properties":{
      "nft_name":{
         "name":"some_name",
         "description":"some_description",
         "required":true
      },
      "nft_binary_data":{
         "name":"some_binary_data",
         "description":"some_description",
         "required":true
      },
   }
}

_More examples can be found in the readme of the enhanced NFT standard.
_
Deploy the Contract
In the following, I will explain how to deploy the enhanced NFT standard on Ubuntu.

Requirements:

**Dependencies**:
- libssl-dev
- curl
- cmake
- pkg-config
$ sudo apt install libssl-dev curl cmake pkg-config
Setup:
1. install Rust and default to nightly toolchain:
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ source $HOME/.cargo/env
$ rustup toolchain install nightly
$ rustup default nightly
2. install the casper-client
$ cargo install casper-client

The next step is to compile the Rust smart contract to WebAssembly:

casper@jonas:~/Desktop/cep-78-enhanced-nft-dev$ make prepare
casper@jonas:~/Desktop/cep-78-enhanced-nft-dev$ make build-contract
the compiled contract.wasm will be in ./contract/target/wasm32-unknown-unknown/release

Deploy the compiled contract.wasm to casper testnet:

$ casper-client put-deploy --node-address <NODE_ADDRESS> --chain-name casper-test --secret-key <PATH_TO_SECRET_KEY> --payment-amount <GAS_FEE_IN_MOTE> --session-path <PATH_TO_contract.wasm> --session-arg <see below>,

Session Arguments:
A list of mandatory session arguments for an NFT contract on Casper:

"collection_name": The name of the NFT collection, passed in as a String. This parameter is required and cannot be changed post installation.
"collection_symbol": The symbol representing a given NFT collection, passed in as a String. This parameter is required and cannot be changed post installation.
"total_token_supply": The total number of NFTs that a specific instance of a contract will mint passed in as a U64 value. This parameter is required and cannot be changed post installation.
"ownership_mode": The OwnershipMode modality that dictates the ownership behavior of the NFT contract. This argument is passed in as a u8 value and is required at the time of installation.
"nft_kind": The NFTKind modality that specifies the off-chain items represented by the on-chain NFT data. This argument is passed in as a u8 value and is required at the time of installation.
"json_schema": The JSON schema for the NFT tokens that will be minted by the NFT contract passed in as a String. This parameter is required if the metadata kind is set to CustomValidated(4) and cannot be changed post installation.
"nft_metadata_kind": The metadata schema for the NFTs to be minted by the NFT contract. This argument is passed in as a u8 value and is required at the time of installation.
"identifier_mode": The NFTIdentifierMode modality dictates the primary identifier for NFTs minted by the contract. This argument is passed in as a u8 value and is required at the time of installation.
"metadata_mutability": The MetadataMutability modality dictates whether the metadata of minted NFTs can be updated. This argument is passed in as a u8 value and is required at the time of installation. More on session args Mint an NFT Before we can mint an NFT using our installed contract, we have to find the "contract_hash"of our deploy. In order to accomplish this, we will have to query the "state-root-hash" after our deploy has been successfully processed, use that "state-root-hash" to query our account and copy the "contract_hash" associated with the "contract_name". ( which in this case will be "nft_contract", as specified in constants.rs) Query your account:

$ casper-client get-state-root-hash <node-address>
-> outputs "state-root-hash"
$ casper-client get-account-state --node-address<NODE_ADDRESS> --state-root-hash <STATE_ROOT_HASH> --key <account-hash-YOUR_ACCOUNT_HASH>
-> find "contract_hash" of deploy named "nft_contract" in output and copy it.

Use the "contract_hash"of the deploy to call the mint() and deploy your first NFT to the Casper Blockchain:

A copy of the command I used to mint a Cep-78 digital NFT on Casper, using the standard metadata schema and dummy metadata from the README:
$ casper-client put-deploy \
--node-address http://136.243.187.84:7777 \
--chain-name casper-test \
--secret-key ./private.pem \
--payment-amount 1000000000 \
--session-hash hash-b4b78992e0324be09f174637c3dda2d29cc5c21c44430b72a0943d3ba6d2c827 \
--session-entry-point mint \
--session-arg "token_owner:key='account-hash-5a54f173e71d3c219940dcb9dfec222b024cd81aa7e0672de59ba5fab296448b'" \
--session-arg "token_meta_data:string='{\"name\":\"John Doe\",\"token_uri\":\"https://www.barfoo.cong\",\"checksum\":\"940bffb3f2bba35f84313aa26da09ece3ad47045c6a1292c2bbd2df4ab1a55fc\"}'"
-> outputs a deploy hash.

Get a List of all owned NFTs by Account
In order to access the Metadata of an NFT, it is necessary to know which NFTs are owned by a given account. The Cep-78 contract’s named_keys store contain a dictionary named “owned_tokens”.

Find the Ids or Hashs of NFTs owned by your account. Whether your NFT is identified by a hash identifier or numerical Id depends on the modalityNFTIdentifierModethat defaults to “Ordinal” (numerical instead of hash):

A copy of the command I used to query the NFTs owned by my Account:
$ casper-client get-dictionary-item \
-n http://136.243.187.84:7777 \
-s 256d0445121f1144a09394c739c9baf82b5624b66dced181a0c1c8b8e936652b \
--account-hash hash-b4b78992e0324be09f174637c3dda2d29cc5c21c44430b72a0943d3ba6d2c827 \
--dictionary-name owned_tokens \
--dictionary-item-key 5a54f173e71d3c219940dcb9dfec222b024cd81aa7e0672de59ba5fab296448b
where --dictionary-item-key is set to my account-hash and -s is a new state-root-hash.
A copy of the output:
{
  "id": 6249115604543280689,
  "jsonrpc": "2.0",
  "result": {
    "api_version": "1.4.6",
    "dictionary_key": "dictionary-6bded5cf061dd95463e0064996f24cb88d19a6a7b24962a1347a5392356a35a0",
    "merkle_proof": "[38054 hex chars]",
    "stored_value": {
      "CLValue": {
        "bytes": "[280 hex chars]",
        "cl_type": {
          "List": "String"
        },
        "parsed": [
          "8bc73bf6cfdb48d0e88f16e0c02d5adff6c60a61a4b6bd65349d75fcb7b500d8",
          "0e557acd2b5a43a91c23c2f0e01687cc8a5342e105be22777b7bf97daf757c4f"
        ]
      }
    }
  }
}

The parsed value is a list of hash identifiers representing NFTs owned by the account:

"8bc73bf6cfdb48d0e88f16e0c02d5adff6c60a61a4b6bd65349d75fcb7b500d8",
          "0e557acd2b5a43a91c23c2f0e01687cc8a5342e105be22777b7bf97daf757c4f"

Read NFT Metadata
The metadata that is passed as an argument when minting an NFT using CEP-78 is saved in a hashmap on the blockchain, where the key is the hash or numeric identifier, depending on theidentifier_mode modality. The name of the dictionary depends on the metadata_kind modality.
The NFT metadata can be found in the related dictionary:

1. "metadata_custom_validated"
2. "metadata_cep78"
3. "metadata_nft721"
4. "metadata_raw"

  const client = await new CasperClient(node_addr);
  var product_contract = new Contracts.Contract(client);
  product_contract.setContractHash(cep78_contract_hash);
  const list = [YOUR_NFT_HASH_IDs];
  let meta = [];
  for (item in list) {
    console.log("Item is: ", list[item].toString());
    await product_contract.queryContractDictionary(
      "metadata_custom_validated",
      list[item]
    ).then(response => {
      meta.push(response.data);
    }).catch(error => {
      console.log(error);
    })
  }

This example shows how a javascript application can query a deployed cep-78 instance with custom validated metadata as metadata_kind.

Youtube Workshop

Learn to configure and install the CEP-78 smart contract here.
Learn to use the Sandbox application here.

Summary
Minting NFTs on Casper is a straight forward process and the enhanced Token standard is a major improvement over the CEP47 Token standard. It’s a more flexible and future proof implementation, setting a metadata standard which allows for the integration of Casper NFTs in both on- and off-chain applications.

Tip: When passing metadata or json schemes using the casper-client, the json strings need to be escaped. When deploying a Cep-78 instance, I use this tool to escape my json schema.

a16z "Can't be Evil" licenses - a practical guide

Jonas Pauli — Fri, 21 Oct 2022 18:19:22 +0000

This guide provides detailed documentation on how to install and use a16z “Can’t be Evil” licenses on Casper.

Introduction
There are many uncertainties regarding copyright and ownership in the NFT space. Users purchase tokenized avatars and artworks, whilst unaware of the legal situation. Resarachers at the venture capital firm “a16z” have made an effort to solve these issues with their “Can’t be evil” NFT licenses. According to a16z, NFTs need to be licensed, as owning the token Id on the blockchain may not be enough to legally reproduce or display an artwork.

The a16z “Can’t be evil” NFT licenses include sets of rules regarding ownership and copyright. Rights and permissions granted through the license only apply to the owner of the NFT. Licenses make it easier to clearly communicate which rights are or are not granted to the customer.

Read more on a16z “Can’t be Evil” licenses.

Smart Contracts
a16z has already published their licenses on Arweave. Additionally, a16z released this Solidity smart contract:

// SPDX-License-Identifier: MIT
// a16z Contracts v0.0.1 (CantBeEvil.sol)
pragma solidity ^0.8.13;

import "@openzeppelin/contracts/utils/Strings.sol";
import "@openzeppelin/contracts/utils/introspection/ERC165.sol";
import "./ICantBeEvil.sol";

enum LicenseVersion {
    CBE_CC0,
    CBE_ECR,
    CBE_NECR,
    CBE_NECR_HS,
    CBE_PR,
    CBE_PR_HS
}

contract CantBeEvil is ERC165, ICantBeEvil {
    using Strings for uint;
    string internal constant _BASE_LICENSE_URI = "ar://_D9kN1WrNWbCq55BSAGRbTB4bS3v8QAPTYmBThSbX3A/";
    LicenseVersion public licenseVersion; // return string
    constructor(LicenseVersion _licenseVersion) {
        licenseVersion = _licenseVersion;
    }

    function getLicenseURI() public view returns (string memory) {
        return string.concat(_BASE_LICENSE_URI, uint(licenseVersion).toString());
    }

    function getLicenseName() public view returns (string memory) {
        return _getLicenseVersionKeyByValue(licenseVersion);
    }

    function supportsInterface(bytes4 interfaceId) public view virtual override(ERC165) returns (bool) {
        return
            interfaceId == type(ICantBeEvil).interfaceId ||
            super.supportsInterface(interfaceId);
    }

    function _getLicenseVersionKeyByValue(LicenseVersion _licenseVersion) internal pure returns (string memory) {
        require(uint8(_licenseVersion) <= 6);
        if (LicenseVersion.CBE_CC0 == _licenseVersion) return "CBE_CC0";
        if (LicenseVersion.CBE_ECR == _licenseVersion) return "CBE_ECR";
        if (LicenseVersion.CBE_NECR == _licenseVersion) return "CBE_NECR";
        if (LicenseVersion.CBE_NECR_HS == _licenseVersion) return "CBE_NECR_HS";
        if (LicenseVersion.CBE_PR == _licenseVersion) return "CBE_PR";
        else return "CBE_PR_HS";
    }
}

In order to support “Can’t be Evil” licenses in Casper smart contracts, the above contract has been translated to Rust:

#![no_std]
#![no_main]

#[cfg(not(target_arch = "wasm32"))]
compile_error!("target arch should be wasm32: compile with '--target wasm32-unknown-unknown'");
extern crate alloc;

use alloc::{
    string::{String, ToString},
    vec,
};

use casper_types::{
    contracts::NamedKeys, runtime_args, ApiError, CLType, CLValue, ContractHash, EntryPoint,
    EntryPointAccess, EntryPointType, EntryPoints, Parameter, RuntimeArgs, URef,
};

use casper_contract::{
    contract_api::{
        runtime,
        storage::{self},
    },
    unwrap_or_revert::UnwrapOrRevert,
};

#[repr(u16)]
enum A16ZError {
    InvalidLicenseVersion = 0,
}
impl From<A16ZError> for ApiError {
    fn from(e: A16ZError) -> Self {
        ApiError::User(e as u16)
    }
}

const _BASE_LICENSE_URI: &str = "ar://_D9kN1WrNWbCq55BSAGRbTB4bS3v8QAPTYmBThSbX3A/";
const CONTRACT_PACKAGE_HASH: &str = "a16z-contract-hash";
const CONTRACT_HASH_KEY_NAME: &str = "contract_hash";

#[no_mangle]
pub extern "C" fn getLicenseURI() {
    let licenseVersion: u64 = runtime::get_named_arg("_licenseVersion");
    match licenseVersion {
        0 => licenseVersion,
        1 => licenseVersion,
        2 => licenseVersion,
        3 => licenseVersion,
        4 => licenseVersion,
        5 => licenseVersion,
        _ => runtime::revert(A16ZError::InvalidLicenseVersion),
    };

    let licenseURI: String = String::from(_BASE_LICENSE_URI) + &licenseVersion.to_string();
    let licenseUriCLValue: CLValue = CLValue::from_t(licenseURI).unwrap_or_revert();
    runtime::ret(licenseUriCLValue);
}

#[no_mangle]
pub extern "C" fn getLicenseName() {
    let licenseVersion: u64 = runtime::get_named_arg("_licenseVersion");
    match licenseVersion {
        0 => runtime::ret(CLValue::from_t(String::from("CBE_CC0")).unwrap_or_revert()),
        1 => runtime::ret(CLValue::from_t(String::from("CBE_ECR")).unwrap_or_revert()),
        2 => runtime::ret(CLValue::from_t(String::from("CBE_NECR")).unwrap_or_revert()),
        3 => runtime::ret(CLValue::from_t(String::from("CBE_NECR_HS")).unwrap_or_revert()),
        4 => runtime::ret(CLValue::from_t(String::from("CBE_PR")).unwrap_or_revert()),
        5 => runtime::ret(CLValue::from_t(String::from("CBE_PR_HS")).unwrap_or_revert()),
        _ => runtime::revert(A16ZError::InvalidLicenseVersion),
    };
}

#[no_mangle]
pub extern "C" fn call() {
    let entry_points = {
        let mut entry_points = EntryPoints::new();
        let getLicenseURI = EntryPoint::new(
            "getLicenseURI",
            vec![Parameter::new("_licenseVersion", CLType::U64)],
            CLType::String,
            EntryPointAccess::Public,
            EntryPointType::Contract,
        );
        let getLicenseName = EntryPoint::new(
            "getLicenseName",
            vec![Parameter::new("_licenseVersion", CLType::U64)],
            CLType::String,
            EntryPointAccess::Public,
            EntryPointType::Contract,
        );
        entry_points.add_entry_point(getLicenseURI);
        entry_points.add_entry_point(getLicenseName);
        entry_points
    };
    let named_keys = {
        let mut named_keys = NamedKeys::new();
        named_keys
    };
    storage::new_contract(
        entry_points,
        Some(named_keys),
        Some(String::from(CONTRACT_PACKAGE_HASH)),
        Some(String::from(CONTRACT_HASH_KEY_NAME)),
    );
}

a16z license URIs ( for NFT-developers )
Platforms like Opensea comply with the eip-721 metadata standard. Learn more here .

Where the “Can’t be Evil” license URI is stored depends on which metadata schema or standard makes the most sense for a project to follow. Most NFT platforms on Casper will likely comply with the CEP-78 metadata standard. As a metadata URI is a link to a server that returns JSON data, it makes the most sense to include the license in the data returned by the backend.

Important: The NFT metadata URI is not the same as the License URI. The License URI is an arweave link to a .doc file, whilst the NFT URI fetches JSON, such as the name, description and image URL from a backend.

As a16z licenses are quite novel, there is not yet a standardized schema to follow. Depending on the legal situation, it might be appropriate to include a license URI or URL in an NFT’s “description”. Casper supports custom metadata schemata, therefore the license URI could be included in the NFT metadata on mint. However, when using custom metadata, other platforms may not be able to integrate the NFTs without manually adding support for a collection / metadata schema.

Read more about metadata on Casper here.
Casper a16z Installation guide
Follow the steps below to compile, and deploy the a16z “Can’t be Evil” contract on casper.

Clone the git repository

chef@jonas:~/Desktop$ git clone https://github.com/jonas089/a16z-casper
chef@jonas:~/Desktop$ cd a16z-casper/contract

Compile the a16z contract

chef@jonas:~/Desktop/a16z-casper/contract$ cargo build --release --target wasm32-unknown-unknown

=> compiles contract.wasm to ./target/wasm32-unknown-unknown/release

Deploy the a16z contract ( to Casper Testnet )

chef@jonas:~/Desktop/a16z-casper/contract/target/wasm32-unknown-unknown/release$ casper-client put-deploy --node-address NODE_ADDRESS --secret-key PRIVATE_KEY_PATH --payment-amount GAS --chain-name casper-test --session-path contract.wasm

Example:

Verify the deploy was successful using the explorer:

Query the contract hash of the installed contract

chef@jonas:~/Desktop$ casper-client get-state-root-hash -n NODE_ADDRESS

=> outputs a state root hash.

chef@jonas:~/Desktop$ casper-client query-global-state -n NODE_ADDRESS -s STATE_ROOT_HASH --key YOUR_ACCOUNT_HASH

=> outputs account information, including the contract hash.

Call the a16z Contract to get a License URI
Query the URI for a “Can’t be Evil” license by calling the “getLicenseURI” endpoint, passing the a16z contract hash and the license version as runtime arguments:

...
#[no_mangle]
pub extern "C" fn simulateThirdParty(){
    let _licenseVersion:u64 = 0;
    let contract_hash:ContractHash = runtime::get_named_arg("CONTRACT_HASH");
    let licenseURI:String = runtime::call_contract::<String>(
        contract_hash,
        "getLicenseURI",
        runtime_args!{
            "_licenseVersion" => _licenseVersion
        }
    );
    // do something with licenseURI
}
...

runtime::call_contract takes in the contract hashto call the “getLicenseURI” entry point of the a16z contract.
The “getLicenseURI”entry point will return a URI for the “CBE_CC0” license ( licenseVersion 0 ).

list of all a16z license versions

0 => CBE_CC0
1 => CBE_ECR
2 => CBE_NECR
3 => CBE_NECR_HS
4 => CBE_PR
5 => CBE_PR_HS

Summary
Thanks to a16z, licensing NFTs is simple and straightforward. Both a Solidity and Rust smart contract is available today and users can start using “Can’t be Evil” licenses on various blockchains now. Licenses are relevant, as the current legal situation regarding NFT copyrights is unclear and users should have an interest in knowing which data they actually own and to what extent they can use it.

Casper Kafka Event Store Pt 2

Mark A. Greenslade — Fri, 21 Oct 2022 10:58:46 +0000

Building a Kafka Cluster in a Kubernetes Cluster

Carl Sagan quoted that If you wish to make an apple pie from scratch, you must first invent the universe.

Luckily the universe has already been invented, but we still need to build our Kubernetes cluster to host our Kafka cluster.

For this POC I chose GCP. They’ve done some good work in minimising the UI. Plus the networking works seamlessly behind the scenes.

Install gcloud and kubectl and run the following command to create the cluster:

gcloud beta container \
 clusters create "[CLUSTER_NAME]" \
 --project "[PROJECT_NAME]"  \
 --zone "[ZONE]" \
 --machine-type "e2-medium" \
 --num-nodes 9 \
 --disk-size "100"

After about 5 minutes we should have a cluster.

Now we can add Zookeeper and Kafka.

Use the installation guide from this GitHub link

As we have no Producers or Consumers configured yet, Kafka will be in a waiting state. No leader has been elected yet. This all happens when topics and partitions are created. More on that later.

Things to note in this cluster

Zookeeper is a StatefulSet of three replicas. We need consistently named pods in the cluster. If we used a Deployment, every time a new pod was instantiated, it would be randomly name with a deployment hash suffix.

With StatefulSets you get consistent pod names. In this case zookeeper-0, zookeeper-1 and zookeeper-2

Likewise with the Kafka brokers.

The Kafka broker StatefulSet starts Kafka.

Lines 2–4 define the Dockerfile, source can be viewed here

I chose to roll my own Dockerfile to allow more control. There are many Kafka Docker images in the hub, but for this project I needed to be able start Kafka with overridden options.

Lines 5–8 are allocated resources per pod. I used Kenneth Owens excellent templates here to configure this POC.

Lines 12–20 are environment variables. Line 13 sets the internal IP of the newly created pod. Lines 17–20 are standard java options.

Lines 21 onward are Kafka start up options.

Line 24 starts Kafka with the default server properties files, we then override these properties in the following lines with a mix of Kubernetes and custom env vars

Line 25 sets the broker id from the pod hostname, eg pod kafka-broker-1 is assigned broker number 1 (StatefulSets give us this naming convention as discussed above)

Lines 26–29 set the listeners. The brokers need to know how to communicate with each other internally and with external clients. This is difficult to get right. These settings work and will save a lot of pain. Line 26 tells Kafka to use the default 0.0.0.0 which means listen on all interfaces. Line 27 uses the pod ip env var, KAFKA_POD_IP for the advertised listener. Confluent have a good article on listeners here.

Line 28 tells Kafka to use the text string ‘INSIDE’ as the inter broker listener name. I assumed that when it sees this string it knows that this is an internal listener.

Line 29 as this POC is an internal Kafka ensemble we can use PLAINTEXT for the security protocol. This is setting it to no encryption or authourisation. This will be changed to SSL for any production cluster.

Line 30 uses Kubernetes env vars to point to our zookeeper pods. The zookeeper deployment uses a Kubernetes service for gateway access. This is all we need to configure the broker. This gives us the option of *n *zookeepers. We’re just using 3 in this POC

After running the steps in on the GitHub page we will have a sucesfully running Kafka/Zookeeper ensemble within a Kubernetes cluster. The ensemble will be in a waiting state. Part 3 of these articles will discuss and demonstrate how to use the cluster, with Casper node events.

Casper Kafka Event Store Pt 1

Mark A. Greenslade — Thu, 20 Oct 2022 15:58:11 +0000

The Description

Casper nodes emit events on state changes. These events in the platform are categorised into three event stream types:

Deploy Events
Finality Signature Event
Main Events

Within each stream type there are multiple event types such as DeployAccepted or BlockAdded

See the Casper documentation for a full description.

The Problem

As can be seen from the diagram below, there will be n nodes emitting 3 event stream types.

This is a lot of events.

Even if the event stream is restricted to one or a group of nodes we are still seeing many events.

Casper clients use these events to build up a picture of state changes in the node and smart contracts.

These state changes can notify audit tools of any discrepancies, such as suspicious transactions, asset mutation or chain failure.

The Solution

How can we handle so many events?

To reliably consume these event streams we need a high throughput, highly available messaging service.

We need to differentiate the event types.
We need to load balance the event stream types into separate silos (Finality Signature events are the majority of events by many multiples)
We need to be able to replay the events in the case of any data loss or DR
We need confidence in our architecture

Enter Kafka, which will satisfy the concerns above.

Kafka has concepts such as Brokers, Partitions, Replicas, Topics which will all be discussed in details in later sections.

For now we just need to know that Kafka will be running n brokers acting as a cluster. The Kafka cluster will use Zookeeper to orchestrate the brokers.

Kafka uses the leader/follower pattern where it will decide amongst itself who is the leader and who follows. If the leader is lost, a new leader will be elected. An odd number is preferred as is always the case with clusters.

Like all messaging systems, we need to produce and consume messages, Kafka like RabbitMQ handily names these as Producers and Consumers. Lets look into how these fit into our architecture:

A simple and clean architecture.

The event streams are read by the producer, any transformations are made, eg text to json, and the event is added to a Kafka topic.

The consumer will then retrieve this event via its topic and process it accordingly.

Where can we host this architecture?

Kubernetes. Whatever the question in DevOps, Kubernetes is usually the answer.

For all it’s minor annoyances (looking at you YAML), what other system can give us guaranteed uptime, replicated apps, ease of deployment/updates etc etc. What else are we going to use? Docker Swarm….

So that being said, with K8s we can run multiple instances of the producer and consumer. We can also run the Kafka cluster within the K8s cluster to further guarantee its availability. Here’s what the final architecture diagram looks like:

Consumer groups are a very useful concept added to our solution. They each read a message from a topic once, so both Consumer Group A and B will both read the same message exactly once. Any other consumers can also read the message (Kafka has a time to live on messages)

As can be seen, we are writing to both an Audit and UI document store. Audit will be used to replay the event history in case of DR, UI will be a structured store which can be used by any UI or reporting tools.

Implementation details will follow in the coming articles