DEV Community: Haruki Kondo

Mathematically Prohibiting 'Cheating' in On-Chain RPS: A Midnight ZK dApp Case Study

Haruki Kondo — Sun, 03 May 2026 23:31:12 +0000

Introduction

Implementing Rock-Paper-Scissors (RPS) on-chain is surprisingly tricky.

The moment you choose "Rock" and send a transaction, your opponent can read your move from the public ledger. The game is over before it even starts.

I tried implementing a commit-reveal pattern manually, but managing salts, preventing front-running, and ensuring fair judging logic... it quickly became a rabbit hole.

That's when I turned to Midnight. I built a full-stack RPS dApp where "cheating" (looking at the opponent's move before playing) is mathematically impossible!

In this article, I'll share the ZK circuit design using Midnight's smart contract language, Compact, and the hurdles I faced during development.

Note
What ZK protects: The ZK proof ensures "confidentiality of the move during the commit phase" (fairness). After the reveal, both moves are recorded on the public ledger.

Here is what the dApp looks like:

What You'll Learn

Designing the "Hidden" vs. "Visible" split in Midnight.
Mastering the commit-reveal pattern with the Compact language.
Frontend UX strategies for handling ZK proof generation time (the 10-second hurdle).
Robust provider configuration with the Midnight JS SDK.

Repository

You can find the full source code here:

mashharuki / midnight-rps-sample-app

Midnight RPS sample dApp

midnight-rps-sample-app

Midnight RPS sample dApp

Overview

midnight-rps-sample-app is a sample Rock-Paper-Scissors dApp project built on Midnight, a privacy-focused blockchain.

Key Features

Fair Gameplay via Zero-Knowledge Proofs (ZK Proofs)
The app utilizes a "commit/reveal" scheme powered by Compact smart contracts. Players commit to their move (Rock, Paper, or Scissors) by submitting a hashed value. Once all players have committed, the moves are revealed. This ensures a tamper-proof gaming experience where "sniping" or reacting to an opponent's move is impossible.
Powered by the Midnight Blockchain
Contracts are deployed on the Midnight PreProd testnet, with all transactions recorded on-chain.
Full-Stack Architecture

Package Role

pkgs/contract Smart contracts written in the Compact language

pkgs/cli CLI tools for contract deployment and interaction

pkgs/app Frontend UI built with React + Vite
Lace Wallet Integration
Connects with Lace Wallet via the @midnight-ntwrk/dapp-connector-api for secure signing and transaction processing.

Package	Role
`pkgs/contract`	Smart contracts written in the Compact language
`pkgs/cli`	CLI tools for contract deployment and interaction
`pkgs/app`	Frontend UI built with React + Vite

Game Flow

Commit Phase — Each player commits their move…

View on GitHub

Quick Start

Here are the steps to get the app running locally.

To be honest, it takes about 15-20 minutes including ZK circuit compilation and the initial Docker image pull. Get your coffee ready!

Environment

Tested with the following:

Docker version 27.4.0
compact 0.2.0
bun 1.3.13
node 23.3.0

Install Lace Wallet to your browser

If you have not yet installed Lace Wallet, you must go to below page & need to install Lace Wallet

Lace | The light wallet platform to explore Web3

Discover the new light wallet platform from Input Output Global. Manage digital assets, and access NFTs, DApps, and DeFi services. Start your Web3 journey.

lace.io

Next, you need to create wallet account of Midnight

Please switch to PreProd Network

0. Clone the Repository

git clone https://github.com/mashharuki/midnight-rps-sample-app.git

1. Install Dependencies

bun install

2. Compile and Build Contracts

# Generate ZK circuit assets (This takes the most time)
bun contract compact  

# Build CLI and Frontend
bun cli build
bun app build

The bun contract compact step is where the Compact compiler generates the ZK proving and verification keys.

3. Start the Proof Server (Initial Pull: ~3 mins)

We need to run the server that handles ZK proof generation via Docker.

Without this server, you won't be able to deploy contracts or send commit/reveal transactions.

Version 8.0.3 is verified with Compact 0.2.0.
Ensure your SDK and Proof Server versions match, or proof generation will fail.

docker run -d -p 127.0.0.1:6300:6300 midnightntwrk/proof-server:8.0.3 midnight-proof-server

4. Deploy Contract to PreProd Network

If you don't have testnet NIGHT Token, you can get some token from below site.

https://faucet.preprod.midnight.network/

bun cli preprod-pts

If you deploy successfull, contract address shows like below.

[19:24:25.997] INFO (40223): Deploying RPS contract...
  ⠇ Deploying RPS contract[19:24:51.416] INFO (40223): Deployed RPS contract at: 23149945fed06aa010cc3e48e9f5df91625567300fae4e09371bb788d07a6bd8
  ✓ Deploying RPS contract
  Contract deployed at: 23149945fed06aa010cc3e48e9f5df91625567300fae4e09371bb788d07a6bd8

The Essence of Midnight Architecture: "Localizing" Information

Developing with Midnight requires a different mindset compared to Solidity.

As mentioned in my previous articles, Midnight has two types of states:

Public State: Visible to everyone (on-chain ledger).
Private State: Visible only to you (local storage).

The Compact ZK circuits act as the bridge between these two.

App Architecture

Code Deep Dive: Mathematically Preventing Cheating

1. Security Core: Domain Separation

When deriving a public key from a secret key, Midnight recommends using domain separation:

pure circuit derive_pk(sk: Bytes<32>): Bytes<32> {
  // Domain separation with a fixed string "rps:pk:v1"
  return persistentHash<Vector<2, Bytes<32>>>([pad(32, "rps:pk:v1"), sk]);
}

If you use the secret key as-is, using the same key in another app would result in the same public key, risking data leakage. By adding a prefix like "app name + version", we ensure that the public keys derived from the same secret key are unique to each app.

2. The Commit-Reveal Circuits

Commit Phase (Declaring a move while keeping it hidden)

export circuit commit(): [] {
  assert(!game_over,                 "Game is already over");
  assert(state == GameState.waiting, "Not in waiting state");

  const sk         = local_secret_key(); // witness: private input
  const pk         = derive_pk(sk);
  const my_move    = get_my_move();
  const my_salt    = get_my_salt();
  const commitment = make_commit(my_move, my_salt);
  store_move_and_salt(my_move, my_salt); // ⭐ Save move and salt to private state

  if (!p1_joined) {
    p1_key    = disclose(pk);
    p1_commit = disclose(commitment);
    p1_joined = true;
  } else {
    assert(!p2_joined, "Both players already committed");
    p2_key    = disclose(pk);
    p2_commit = disclose(commitment);
    p2_joined = true;
    state     = GameState.committed; // Transition to 'committed' when both joined
  }
}

Pay close attention to store_move_and_salt.

This is a witness function that saves the selected move and salt to the browser's IndexedDB (private state). To prove that the move revealed later is the same one committed earlier, this step is absolutely necessary.

The use of disclose() is also critical. It allows developers to explicitly control which results of private computations are written to the public ledger.

Game State Transitions

The coordination between commit and reveal phases is managed by these states:

3. Reveal Phase: Where ZK Proofs Shine

If the commit is the "declaration," the reveal is the "proof."

This is where Midnight's ZK stack really pays off.

export circuit reveal(): [] {
  assert(!game_over,                   "Game is already over");
  assert(state == GameState.committed, "Not in committed state");

  const sk      = local_secret_key();
  const pk      = derive_pk(sk);
  const my_move = get_my_move();   // Restore from private state
  const my_salt = get_my_salt();   // Restore from private state
  const computed = make_commit(my_move, my_salt);

  const is_p1 = disclose(p1_key == pk);
  const is_p2 = disclose(p2_key == pk);
  assert(is_p1 || is_p2, "Caller is not a registered player");

  if (is_p1) {
    assert(!p1_revealed, "Player 1 already revealed");
    assert(disclose(computed == p1_commit), "Commitment mismatch for P1");
    p1_move     = disclose(my_move); // Move is written to ledger only now
    p1_revealed = true;
  }
  if (is_p2) {
    assert(!p2_revealed, "Player 2 already revealed");
    assert(disclose(computed == p2_commit), "Commitment mismatch for P2");
    p2_move     = disclose(my_move);
    p2_revealed = true;
  }

  if (disclose(p1_revealed && p2_revealed)) {
    result    = who_wins(p1_move, p2_move); // Judge winner
    game_over = true;
    state     = GameState.finished;
  }
}

The line assert(disclose(computed == p1_commit), "Commitment mismatch for P1") is the heart of the logic:

my_move and my_salt exist only in your local private state.
make_commit(my_move, my_salt) is re-calculated, and the ZK circuit verifies it matches the p1_commit recorded on-chain during the commit phase.
You mathematically prove that "this move is the one I committed to" without revealing the move itself until the proof is valid.

Once the reveal is successful, p1_move and p2_move are finally written on-chain, and who_wins() determines the outcome.

During the commit phase, your move is hidden by ZK and remains unknown to the opponent until it is revealed. This is the mechanism that "mathematically prohibits cheating."

Overcoming the ZK dApp UX Hurdle

The biggest challenge during implementation was handling the "ZK proof generation time."

Filling the 10-Second Silence

In Midnight, before sending a transaction, you must generate a proof on your machine (or the Proof Server). This takes about 5-10 seconds.

UX improvements are essential to prevent users from thinking the app has frozen:

Optimistic UI Updates: Switch the UI state to "Generating Proof..." as soon as the process starts to communicate clearly what is happening.
Persistent Providers: Use levelPrivateStateProvider to ensure that even if the user reloads the browser during proof generation, the generated data and chosen moves are not lost.

// Example levelPrivateStateProvider configuration
privateStateProvider: levelPrivateStateProvider({ 
  accountId, 
  namespace: "rpsPrivateState", // Separate namespace for each game
  privateStoragePasswordProvider: () => storagePassword // Secure storage
}),

Sequence: From Commit to Game End

Let's recap the full flow:

Remaining Challenges

There's still a lot to learn by building with Midnight and Compact. Here are some issues I'm still working on:

1. The Abandonment Problem (Griefing Attack)

If Player 1 commits and Player 2 never joins, the contract stays locked. I need to implement a timeout/cancel mechanism in a future update.

2. Version Management of Build Assets

ZK circuit assets (proving keys) generated by bun contract compact can become invalid with even minor updates to the Compact version or compiler.

I actually ran into this during development. If you're building a similar app, double-check your library and Proof Server versions!

Solving these two will open up even more possibilities for ZK dApps on Midnight.

Conclusion

Implementing this "fair" RPS app taught me three key lessons:

Verify Versions: Proof generation can fail due to mismatched Proof Server versions.
Don't Forget store_move_and_salt: Saving private state is mandatory for the reveal phase.
UX is Priority #1: Designing a UI that handles the unique "waiting time" of ZK is critical.

Next, I'm planning to tackle multi-round support and timeout handling!

If you're interested in Midnight's privacy tech, check out the repository and my other technical blogs!

Thanks for reading!

Follow me on X!

x.com

References

Unleashing IronClaw: The Secure, Rust-Based AI Agent Framework by NearAI

Haruki Kondo — Wed, 29 Apr 2026 07:29:12 +0000

Introduction: The Rise of Secure AI Agents

By now, most of you in the AI space have probably heard of OpenClaw. It’s the AI Agent framework that took the community by storm in early 2026.

But have you heard of IronClaw?

While OpenClaw focused on accessibility and rapid prototyping, IronClaw is its security-hardened sibling, built from the ground up in Rust. Developed by the team at Near AI, it’s designed for developers who need autonomous agents that can handle sensitive data—like passwords and API keys—without exposing them to the LLM.

In this post, we’ll dive deep into what makes IronClaw the "Iron Man suit" for your AI agents.

What is IronClaw?

IronClaw is an open-source AI Agent framework developed by Near AI. It is designed to run in secure environments like NEAR AI Cloud, allowing agents to autonomously operate tools (Google Workspace, GitHub, etc.) while keeping user credentials strictly confidential.

About Near AI

Near AI Official Website

Near AI started as a prominent Layer 1 blockchain project (once considered a potential "Ethereum killer"). Today, it has evolved into an AI-native public blockchain.

Fun fact: One of its founders, Illia Polosukhin, is a co-author of the seminal "Attention Is All You Need" paper—the research that introduced the Transformer architecture to the world.

Key Features of IronClaw

Running IronClaw on the NEAR AI Cloud provides several hardware-level security benefits that standard frameworks lack:

TEE (Trusted Execution Environment): Agents run in encrypted, isolated enclaves.
Data Confidentiality: Memory data is always encrypted. Not even the cloud provider (NEAR AI) can peek into your conversations or memory.
Verifiability: Hardware-level isolation (like GPU attestation) ensures private and verifiable computing.
Secrets Protection: An "Encrypted Vault" integrates with the infrastructure to inject credentials into tools without the LLM ever seeing the raw API keys.

Capabilities at a Glance

Category	Feature	Benefit
Security	Encrypted Vault / WASM Isolation	Secrets are stored safely; tools run in sandboxes.
Connectivity	Multi-channel Support	Operate via Terminal, Telegram, Discord, or Webhooks.
Memory	Persistent Memory	Agents remember past conversations and documents for RAG.
Automation	Scheduled Jobs	Automate tasks like "Generate a report every morning at 9 AM."
Extensibility	Tool Ecosystem	Easily add tools for Google Docs, Calendar, GitHub, and Web Search.

The 4-Layer Security Architecture

IronClaw employs a "Defense in Depth" strategy, ensuring data passes through four independent protection layers before reaching any external service.

Safety Layer: Prevents prompt injection, sanitizes content, and scans for over 15 types of secret patterns.
WASM Sandbox: A lightweight execution environment for tools with strict memory limits (default 16MB) and "Fuel Metering" to prevent infinite loops.
Docker Sandbox: Container-level isolation for complex jobs and untrusted script execution.
Secret Management: A "Zero-Exposure" model using AES-256-GCM encryption where credentials are only injected at the host boundary.

WASM vs. Docker Sandbox: Which is which?

Feature	WASM Sandbox	Docker Sandbox
Runtime	`wasmtime`	Container Virtualization
Primary Use	Secure Tool Execution	Code Execution, Builds, Scripts
Footprint	Extremely Lightweight	Moderate Resource Usage
Limits	Fuel Metering (Instructions)	CPU / Memory (Standard)
Secret Access	Injected via Proxy	Environment Variables / Volumes

Getting Started with IronClaw

1. Access the Agent Dashboard

Head over to the Near AI Agent Dashboard.

2. Choose Your Plan

The Starter plan is free and perfect for getting your feet wet.

3. One-Click Deployment

Click the Deploy button to spin up your IronClaw instance on NEAR AI Cloud.

The default LLM is typically set to Qwen, but you can customize this.

4. Experiment!

Try chatting with your agent, adding new Skills, or connecting MCP (Model Context Protocol) servers.

Conclusion

With a team led by a Transformer co-author, it’s no surprise that IronClaw is a masterclass in combining AI utility with rigorous security. Its deployment process is arguably one of the smoothest in the ecosystem.

If you’re looking to build an agent that does more than just chat—an agent you can actually trust with your digital life—IronClaw is the way to go.

Thanks for reading!

Join the Hackathon!

Near AI is proud to sponsor the OpenClaw Hackathon on May 2nd!

Using IronClaw in your project will definitely put you on the radar for the security-focused tracks. We can't wait to see what you build!

References

IronClaw Official Site
Developer Documentation
nearai / ironclaw

IronClaw is OpenClaw inspired implementation in Rust focused on privacy and security
IronClaw

Your secure personal AI assistant, always on your side

English | 简体中文 | Русский | 日本語 | 한국어

Philosophy • Features • Installation • Configuration • Security • Architecture

Philosophy

IronClaw is built on a simple principle: your AI assistant should work for you, not against you.

In a world where AI systems are increasingly opaque about data handling and aligned with corporate interests, IronClaw takes a different approach:
- Your data stays yours - All information is stored locally, encrypted, and never leaves your control
- Transparency by design - Open source, auditable, no hidden telemetry or data harvesting
- Self-expanding capabilities - Build new tools on the fly without waiting for vendor updates
- Defense in depth - Multiple security layers protect against prompt injection and data exfiltration
IronClaw is the AI assistant you can actually trust with your personal and professional life.

Features

Security First
- WASM Sandbox - Untrusted…
View on GitHub
Near AI Agent Dashboard

Building a Full-Stack ZK-Privacy App on Midnight: A Step-by-Step Guide

Haruki Kondo — Sun, 26 Apr 2026 13:11:02 +0000

Introduction

Hello everyone! 🚀

In this post, we are diving deep into Midnight, the privacy-focused blockchain!

Previously, we covered how to connect a frontend application to Lace Wallet. Now, we’re taking the next big step: connecting to a smart contract!

Implementing a full-stack ZK (Zero-Knowledge) application can be tricky, but I’ve navigated the pitfalls and version mismatches so you don't have to. Let’s get started!

What You Will Learn

How to develop a full-stack application on Midnight.
Concrete source code for calling smart contract functions via Lace Wallet.
Real-world "gotchas" and how to solve them.

The Sample App: A Full-Stack Counter

We’ll build a simple app that connects to Lace Wallet, displays balances, and interacts with a Counter smart contract.

Prerequisites

Lace Wallet browser extension (Midnight-compatible version).
PreProd network selected in Lace settings.
Some test NIGHT tokens from the official faucet.
Docker installed (for running the Proof Server).

GitHub Repository

Check out the full source code here:
https://github.com/mashharuki/midnight-sample-fullstack-app

Application Preview

Technical Features

Category	Feature	Description
Contract	Build	Compiles Compact files into WASM/ZKIR/Managed Code.
Contract	Simulator	Logic verification using `CounterSimulator` without a live network.
CLI	Deploy	Deploys to Standalone/TestNet and retrieves the contract address.
CLI	Interaction	Direct CLI commands to increment and check counter values.
App	Wallet Connect	Integration with Lace Wallet extension to fetch account data.
App	Sync	Automatically joins and fetches current state from a contract address.
App	ZK Increment	One-click UI to generate ZK proofs and send transactions.

Tech Stack

Layer	Technology
Frontend	React 19, Vite 5, Tailwind CSS v4, Lucide React, RxJS
Contract	Compact (Midnight's ZK DSL)
SDK	`@midnight-ntwrk/*` (SDK v2 / DApp Connector API v4)
Infrastructure	Midnight Node, Indexer, Proof Server (via Docker)
Tooling	Bun, Biome, Vitest, TypeScript

Deep Dive: Key Implementation Logic

The core logic resides in src/lib/counter.ts and src/hooks/useCounter.ts. This was the most challenging part of the build due to SDK version transitions and compatibility issues with Lace Wallet.

`src/lib/counter.ts`

This file handles the contract instance creation, state querying, and transaction calls.

1. Contract Instance Creation

We use the SDK to wrap the compiled Compact contract.

import * as CompactJs from "@midnight-ntwrk/compact-js";

// Initialize the compiled contract instance
export const counterContractInstance: CounterContract = (CompactJs.CompiledContract.make(
  "counter",
  Counter.Contract as any,
) as any).pipe(
  CompactJs.CompiledContract.withVacantWitnesses,
);

2. Querying State

Using queryContractState, we can fetch the ledger data (in this case, the round number of our counter).

export const getCounterValue = async (
  providers: CounterProviders,
  contractAddress: ContractAddress,
): Promise<bigint | null> => {
  assertIsContractAddress(contractAddress);

  const contractState = await providers.publicDataProvider.queryContractState(
    contractAddress,
  );

  return contractState != null
    ? Counter.ledger(contractState.data as any).round
    : null;
};

3. Calling Updates (Transactions)

The magic happens in callTx. This triggers the ZK proof generation and requests a signature from Lace Wallet.

export const incrementCounter = async (
  counterContract: DeployedCounterContract,
): Promise<void> => {
  // Call the increment() method on the contract
  await (counterContract as any).callTx.increment();
};

Getting Started: Run it Locally

1. Clone & Install

git clone https://github.com/mashharuki/midnight-lace-react-sample-app.git
cd midnight-lace-react-sample-app
bun install

2. Start the Proof Server

Midnight requires a Proof Server to generate ZK Proofs locally before sending transactions to the network.

cd pkgs/cli
# Start the Proof Server (Ensure it's version 8.0.3)
docker compose -f standalone.yml up -d

3. Build & Deploy the Contract

bun contract build

# Deploy to the PreProd network
bun cli preprod

Note: Copy the contract address displayed in the terminal!

4. Setup & Start the Frontend

# Set environment variables
cp pkgs/app/.env.local.example pkgs/app/.env

# Build and start
bun app build
bun app dev

Visit localhost:5173. You should see the following:

Connect your wallet.
Enter your deployed contract address and click Join.
Click Increment. You will be prompted to sign the transaction.

Wait a few moments for the ZK proof generation and network finalization. Once done, refresh to see the updated value!

Sequence Diagrams

Unlike traditional blockchains, Midnight involves a local ZK Proof generation step in every state-changing transaction.

Contract Deployment Flow

Increment Function Call Flow

Summary

Building with ZK-privacy is a paradigm shift. While there were hurdles—especially around SDK versions and wallet compatibility—overcoming them allows you to build applications that truly respect user privacy.

I even created a custom AI Agent skill to help debug the Midnight SDK logic, which made the final stretch much smoother! You can find my Claude skills in the repo if you're interested.

Happy coding, and see you in the next one where we might tackle some hackathon challenges! 🛡️✨

References

Build a Simple App That Connects to Midnight Lace Wallet

Haruki Kondo — Fri, 24 Apr 2026 12:35:58 +0000

Introduction

Hello everyone!

In this article, we will look at Midnight, a privacy-focused blockchain, and its dedicated wallet, Lace Wallet.

Lace | The light wallet platform to explore Web3

Discover the new light wallet platform from Input Output Global. Manage digital assets, and access NFTs, DApps, and DeFi services. Start your Web3 journey.

lace.io

The official documentation explains how to deploy and run contracts, but I could not find clear guidance on connecting Lace Wallet to a frontend app. I ran into a few tricky points while trying it, so I created a simple beginner-friendly sample app.

I hope you enjoy it!

What You Will Learn

A quick overview of Lace Wallet
How to build a simple app that connects to Lace Wallet

What Is Lace Wallet?

Lace Wallet is a lightweight wallet for storing and managing Cardano-related digital assets. It was announced by IOG, the team behind Cardano, on June 9, 2022.

It can manage digital assets on blockchains in the Cardano ecosystem, including Midnight.

Even though it is lightweight, it offers rich features such as staking and asset transfers.

It is currently optimized for the Cardano ecosystem, and it appears support for other ecosystems is planned in the future.

Build a Simple App That Connects to Lace Wallet

Prerequisites

Before running the sample code, make sure you have the following:

The Lace Wallet browser extension installed (a version with Midnight support)
PreProd selected in Lace network settings

Sample Code Repository

mashharuki / midnight-lace-react-sample-app

midnight-lace-react-sample-app

A sample dApp frontend for connecting to the Midnight Network (PreProd).
Use Lace Wallet to connect your wallet, view your shielded address, and check your balance.

Screenshots

Features

Feature	Description
Lace Wallet Connection	Detects and connects to `window.midnight.mnLace` via 100ms polling
Version Validation	Verifies that the Connector API version is `>=1.0.0`
Network Detection	Automatically tries networks in order: PreProd / mainnet / undeployed / preview
Address Display	Shows the shielded address in a copyable format
Balance Display	Shows Shielded / Unshielded / Dust balances in tDUST units
Language Toggle	Instantly switch between Japanese and English via the top-right button (persisted in localStorage)

Tech Stack

Category	Library / Tool
Framework	React 19 + TypeScript
Build	Vite 8
Styling	Tailwind CSS v4 (`@tailwindcss/vite`)
UI Components	shadcn/ui (Button, Badge, Card) + Lucide React
Internationalization	i18next 26 + react-i18next 17
Wallet Integration	`@midnight-ntwrk/dapp-connector-api`
Async Processing	RxJS 7
Package Manager	Bun
Formatter

…

View on GitHub

App Preview

This sample app is intentionally simple: connect Lace Wallet and display balances.

Feature List

Feature	Description
Lace Wallet connection	Detects and connects to `window.midnight.mnLace` using 100ms polling
Version check	Confirms Connector API version is `>=1.0.0`
Network validation	Automatically tries PreProd / mainnet / undeployed / preview in order
Address display	Shows a copyable shielded address
Balance display	Shows Shielded / Unshielded / Dust balances in tDUST
Language switch	Instantly toggles Japanese ⇆ English from the top-right button (persisted via localStorage)

Tech Stack

Category	Library / Tool
Framework	React 19 + TypeScript
Build	Vite 8
Styling	Tailwind CSS v4 (`@tailwindcss/vite`)
UI Components	shadcn/ui (Button, Badge, Card) + Lucide React
Internationalization	i18next 26 + react-i18next 17
Wallet Integration	`@midnight-ntwrk/dapp-connector-api`
Async Processing	RxJS 7
Package Manager	Bun
Formatter	Biome

Key Source Code Explanations

The overall architecture is similar to many other blockchain apps.

If you understand the SDK and API specifications, you can build a working connection app quickly.

The key SDK in this project is @midnight-ntwrk/dapp-connector-api.

It is used to implement the wallet connection logic.

All important connection-related logic is consolidated in the file below.

A key point is around line 103.

// Attempt connection. If a network mismatch occurs, fall back to the next candidate.
walletAPI = await connector.connect(networkId);
// Lace v4: getConfiguration() is on walletAPI (not connector)
const walletRaw = walletAPI as unknown as Record<string, unknown>;

From walletRaw, you can extract wallet information such as addresses.

let address = "";
let coinPublicKey = "";
let encryptionPublicKey = "";

if (typeof walletRaw.getShieldedAddresses === "function") {
  // getShieldedAddresses() may return an array (old versions) or a single object (new versions), so handle both cases
  const result = await (
    walletRaw.getShieldedAddresses as () => Promise<Record<string, unknown>>
  )();
  // Lace v4 returns a single object (not array):
  // { shieldedAddress, shieldedCoinPublicKey, shieldedEncryptionPublicKey }
  const entry = (Array.isArray(result) ? result[0] : result) as
    | Record<string, unknown>
    | undefined;
  if (entry) {
    address = String(entry.shieldedAddress ?? entry.address ?? "");
    coinPublicKey = String(
      entry.shieldedCoinPublicKey ?? entry.coinPublicKey ?? "",
    );
    encryptionPublicKey = String(
      entry.shieldedEncryptionPublicKey ?? entry.encryptionPublicKey ?? "",
    );
  }
}

Balance retrieval is implemented as a dedicated React hook.

The most important part is the fetchBalances function.

It fetches balances from three wallet-related methods:

raw.getShieldedBalances
raw.getUnshieldedBalances
raw.getDustBalance

import { formatBalance } from "@/lib/utils";
import type { BalanceState } from "@/utils/types";
import type { DAppConnectorWalletAPI } from "@midnight-ntwrk/dapp-connector-api";
import { useCallback, useState } from "react";

export type { BalanceState };

/**
 * Fetch shielded / unshielded / dust balances in parallel from the wallet API.
 *
 * The Lace SDK type definitions do not include these balance methods,
 * so this function casts to unknown and checks method availability dynamically.
 * Promise.allSettled allows us to receive remaining results even if one call fails.
 */
async function fetchBalances(walletAPI: DAppConnectorWalletAPI): Promise<{
  shielded: string;
  unshielded: string;
  dust: string;
}> {
  const raw = walletAPI as unknown as Record<string, unknown>;

  // Try fetching balances in parallel. If a method is unavailable, return null.
  const [shieldedResult, unshieldedResult, dustResult] =
    await Promise.allSettled([
      typeof raw.getShieldedBalances === "function"
        ? (raw.getShieldedBalances as () => Promise<unknown>)()
        : Promise.resolve(null),
      typeof raw.getUnshieldedBalances === "function"
        ? (raw.getUnshieldedBalances as () => Promise<unknown>)()
        : Promise.resolve(null),
      typeof raw.getDustBalance === "function"
        ? (raw.getDustBalance as () => Promise<unknown>)()
        : Promise.resolve(null),
    ]);

  return {
    shielded:
      shieldedResult.status === "fulfilled"
        ? formatBalance(shieldedResult.value)
        : "--",
    unshielded:
      unshieldedResult.status === "fulfilled"
        ? formatBalance(unshieldedResult.value)
        : "--",
    dust:
      dustResult.status === "fulfilled"
        ? formatBalance(dustResult.value)
        : "--",
  };
}

/**
 * Custom hook to manage loading and refreshing balances.
 *
 * @param walletAPI - Connected wallet API. If null, no action is taken.
 * @returns balanceState: current balance state / refresh: manual refresh trigger
 */
export function useBalance(walletAPI: DAppConnectorWalletAPI | null) {
  const [balanceState, setBalanceState] = useState<BalanceState>({
    status: "idle",
  });

  /**
   * Fetch balances from the wallet API and update state.
   * If walletAPI is null, do nothing.
   * Set status to "loading" while fetching, "loaded" on success with balances,
   * and "error" if anything fails.
   */
  const refresh = useCallback(async () => {
    if (!walletAPI) return;
    setBalanceState({ status: "loading" });
    try {
      const balances = await fetchBalances(walletAPI);
      setBalanceState({ status: "loaded", ...balances });
    } catch (e: unknown) {
      console.error("[useBalance] Failed to fetch balances:", e);
      setBalanceState({ status: "error" });
    }
  }, [walletAPI]);

  return { balanceState, refresh };
}

How to Run the App

Clone

git clone https://github.com/mashharuki/midnight-lace-react-sample-app.git

# Move to the frontend app directory
cd app

Install

bun install

Build

bun run build

Start

bun run dev

Conclusion

That is all for this tutorial.

Now you have a clear path to connect a React + Vite app with Lace Wallet, which is a solid step toward building a full-stack Midnight application.

In a future article, I plan to cover how to call functions on a smart contract deployed on Midnight and continue toward a full-stack implementation.

Thank you for reading!

References

[Hands-on] Midnight Deep Dive: Start Building Smart Contracts with Compact

Haruki Kondo — Tue, 14 Apr 2026 15:25:20 +0000

Introduction: The "Too Transparent" Problem of Blockchains

Since the Bitcoin whitepaper was published, blockchain technology has transformed many industries, from finance to supply chains, thanks to its trustless design, transparency, and tamper resistance.

bitcoin.org

The idea that anyone can validate the same distributed ledger and form a trust network without centralized administrators was truly revolutionary.

But complete transparency can also become a major weakness.

What if confidential enterprise data is exposed to competitors?
What if personal transaction history is visible to the entire world?
What if private medical records or voting behavior can be inspected by anyone?

That "too transparent" problem has been one of the biggest barriers preventing public blockchain technology from being widely adopted in enterprise and daily consumer use cases.

To solve this dilemma, a breakthrough project has emerged from the Cardano ecosystem.

That project is Midnight.

Midnight is a Cardano sidechain focused on data protection and privacy.

By leveraging cutting-edge cryptography known as Zero-Knowledge Proofs (ZKPs)[^1], Midnight enables us to prove only the facts we need, without revealing anything else.

ZKPs are often discussed in the context of privacy, but they can also reduce computational overhead depending on how they are used.

Representative examples include ZkEVM and INTMAX, both of which use ZK-based approaches for EVM-related scaling.

INTMAX – Stateless Layer for Billions

INTMAX is a stateless, privacy-centric Layer 2 on Ethereum that delivers fast, secure, and cost-efficient transactions. Explore the future of private digital payments and empower your transactions with unmatched anonymity and speed.

intmax.io

I recently joined the Midnight Hackathon in London and spent a lot of time exploring Compact. In this article, I share what I learned in a hands-on format: from environment setup to contract implementation, testing, and deployment.

Home - Midnight Summit 2025

Midnight Summit 2025: An invitation-only ecosystem event with talks, breakouts and a live Hackathon shaping the future of privacy-first blockchain.

midnightsummit.io

If you want a conceptual introduction to Midnight first, check this article:

Haruki Kondo for Midnight Aliit Fellowship

Apr 13

The Future of Privacy: A Deep Dive into Cardano's Midnight & Zero-Knowledge Proofs

#blockchain #web3 #typescript #zkp

Comments

4 min read

[^1]: Zero-Knowledge Proof (ZKP) is a cryptographic method that lets you prove a statement is true without revealing any additional information (including why it is true).

Compact: A Privacy Smart Contract Language with TypeScript-like Syntax

Another core pillar behind Midnight's innovation is its smart contract language, Compact.

"Isn't zero-knowledge technology only for cryptography experts?"

Compact is designed to dramatically lower that barrier.

TypeScript-based syntax

The biggest feature of Compact is that it is a TypeScript-based domain-specific language (DSL).

That means a large number of web developers can build privacy-preserving applications with familiar syntax, instead of learning an entirely new language from scratch.

The Compact compiler translates your logic into the cryptographic components needed for zero-knowledge proofs, so you do not have to deal with the underlying math directly.

Three data states: Public, Private, Witness

The core of data handling in Compact is clear separation of privacy levels.

Data is mainly handled in three states:

public (public state)
- Data visible on the blockchain.
- Similar to state variables in conventional smart contracts.
- Defined with the ledger keyword.
private (private state)
- Confidential data managed only in a user's local (off-chain) environment.
- The raw private data itself is not recorded on-chain.
- Defined with the private keyword.
witness (proof input)
- Input supplied during transaction execution to prove, "I know this data."
- Used as evidence when updating private state.
- Defined with the witness keyword.

Basic syntax and a Counter smart contract example

Let's look at these concepts through a simple Counter contract.

This contract only increments a number, and is also introduced in official tutorials.

It includes:

A state variable stored on the public ledger
A method to increment that state

pragma language_version >= 0.16 && <= 0.25;
import CompactStandardLibrary;

// Public state stored on the on-chain ledger
export ledger round: Counter;

// Transition function that updates public state
export circuit increment(): [] {
    round.increment(1);
}

ledger: A publicly visible on-chain state variable.
circuit: A transaction-invoked state transition function where validation and updates happen.

With Compact, you can write logic in TypeScript-like syntax while controlling data privacy in detail and proving correctness intuitively.

Hands-on: Set up your Midnight development environment

Now let's move from theory to practice.

In this section, we build the environment needed to run counter.compact.

As of November 2025, frontend integration is still unstable.

So in this hands-on, the goal is to deploy a smart contract and interact with it via CLI.

Required components:

Compact CLI Command-line tool for compiling and testing smart contracts.
Lace Midnight Preview Wallet Browser extension wallet for Midnight Testnet.
Testnet Faucet Service to get test tokens.
ZK Proof Server Local server for generating and verifying zero-knowledge proofs.
Sample repository Source code used in this tutorial.

Step 1: Install Compact CLI

First, install the compact CLI compiler:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

Then pin a specific version (0.25.0 in this article):

compact update 0.25.0

Check installation:

compact --version
# compact 0.2.0 or similar
compact compile --version
# 0.25.0

If compact compile --version returns 0.25.0, you're good.

Step 2: Prepare Lace Wallet and get Testnet tokens

Next, set up a wallet and receive test tokens.

Install Lace Wallet Add Lace Midnight Preview from the Chrome Web Store.
Create your wallet Follow the setup wizard. Store your recovery phrase securely.
Copy your address From the wallet home screen, click "Receive" and copy your address.
Request faucet funds Open Midnight Testnet Faucet, paste your address, and click "Request funds". After a short wait, test tDUST tokens should arrive.

Step 3: Start ZK Proof Server

Private processing (including proof generation) is handled through a local Proof Server.

We'll start the official Midnight Docker image:

Docker Desktop must be installed for this step.

docker run -p 6300:6300 midnightnetwork/proof-server -- 'midnight-proof-server --network testnet'

If logs start streaming, it launched successfully. Keep this terminal running.

You can also verify with:

curl -X GET "http://localhost:6300"

Expected response:

We're alive 🎉!

Step 4: Prepare sample repository

Finally, set up the repository used in this article:

mashharuki / midnight-sample

midnightでの開発事前検証用リポジトリ

midnight-sample

midnightでの開発事前検証用リポジトリ

環境

nodejs
yarn
docker
compact CLI

compact CLIのインストール

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

その後、以下でバージョン指定

compact update 0.25.0

インストールされているかの確認

compact --version
compact compile --version

それぞれ以下のようになればOK!

compact 0.2.0
0.25.0

Testnet用のZKProof serverの起動

docker run -p 6300:6300 midnightnetwork/proof-server -- 'midnight-proof-server --network testnet'

docker ps

localhost:6300でサーバーが起動していればOK

CONTAINER ID   IMAGE                          COMMAND                  CREATED          STATUS          PORTS                                         NAMES
a62d9787f7a1   midnightnetwork/proof-server   "/nix/store/qa9fb15p…"   25 seconds ago   Up 24 seconds   0.0.0.0:6300->6300/tcp, [::]:6300->6300/tcp   flamboyant_roentgen

念の為以下のコマンドでも稼働確認

curl -X GET "http://localhost:6300"

We're alive 🎉!

サンプルプログラムのコンパイル＆デプロイ手順

まず、依存関係をインストールする

yarn

以下のコマンドでコントラクトをビルドする

yarn contract compact

以下のようになればOK!

Fetching public parameters for k=10 [====================] 192.38 KiB / 192.38 KiB
  circuit "increment" (k=10, rows=29)  
Overall progress [====================] 1/1

コントラクトのユニットテストコードを実行する

yarn contract test

以下のようになればOK!

 RUN  v4.0.8 /workspaces/midnight-sample/my-mn-app/pkgs/contract
 ✓ test/counter.test.ts (3 tests) 44ms
   ✓ Counter smart contract (3)
     ✓ generates initial ledger state deterministically 36ms
     ✓ properly initializes ledger

…

View on GitHub

# Clone your own fork
# (fork the repository first)
git clone https://github.com/<user-name>/midnight-sample.git
cd midnight-sample

# Install dependencies
yarn

Replace the git clone URL with your actual repository URL.

Environment setup is now complete.

Next, let's implement and test the smart contract.

Implement and test the Counter contract

With the environment ready, let's build and test.

Code walkthrough

Put this contract in pkgs/contract/src/counter.compact:

pragma language_version >= 0.16 && <= 0.25;
import CompactStandardLibrary;

// Public state stored on the on-chain ledger
export ledger round: Counter;

// Transition function that updates public state
export circuit increment(): [] {
    round.increment(1);
}

Then compile with compact CLI:

yarn contract compact

Under the hood:

compact compile ./src/counter.compact ./src/managed/counter

On success, you will see output like:

Fetching public parameters for k=10 [====================] 192.38 KiB / 192.38 KiB
  circuit "increment" (k=10, rows=29)
Overall progress [====================] 1/1

Unit test implementation

Compact lets you simulate contract logic off-chain for testing.

See pkgs/contract/src/test/counter.test.ts:

import { CounterSimulator } from "./counter-simulator.js";
import {
  NetworkId,
  setNetworkId
} from "@midnight-ntwrk/midnight-js-network-id";
import { describe, it, expect } from "vitest";

setNetworkId(NetworkId.Undeployed);

/**
 * Unit tests for the Counter contract
 */
describe("Counter smart contract", () => {
  it("generates initial ledger state deterministically", () => {
    const simulator0 = new CounterSimulator();
    const simulator1 = new CounterSimulator();
    expect(simulator0.getLedger()).toEqual(simulator1.getLedger());
  });

  it("properly initializes ledger state and private state", () => {
    const simulator = new CounterSimulator();
    const initialLedgerState = simulator.getLedger();
    expect(initialLedgerState.round).toEqual(0n);

    const initialPrivateState = simulator.getPrivateState();
    expect(initialPrivateState).toEqual({ privateCounter: 0 });
  });

  it("increments the counter correctly", () => {
    const simulator = new CounterSimulator();
    const nextLedgerState = simulator.increment();
    expect(nextLedgerState.round).toEqual(1n);

    const nextPrivateState = simulator.getPrivateState();
    expect(nextPrivateState).toEqual({ privateCounter: 0 });
  });
});

These tests verify three scenarios:

Contract initialization is deterministic.
Initial ledger value is 0.
increment updates the counter correctly.

Run tests

Run:

yarn contract test

If all tests pass, output looks like:

RUN  v4.0.8 /workspaces/midnight-sample/my-mn-app/pkgs/contract

 ✓ test/counter.test.ts (3 tests) 44ms
   ✓ Counter smart contract (3)
     ✓ generates initial ledger state deterministically 36ms
     ✓ properly initializes ledger state and private state 3ms
     ✓ increments the counter correctly 4ms

 Test Files  1 passed (1)
      Tests  3 passed (3)
   Start at  08:27:47
   Duration  421ms (transform 95ms, setup 0ms, collect 233ms, tests 44ms, environment 0ms, prepare 13ms)

JUNIT report written to /workspaces/midnight-sample/my-mn-app/pkgs/contract/reports/report.xml
Done in 1.34s.

Now that we know the logic works, let's create the CLI flow to deploy on Testnet.

Deploy and execute from CLI on Testnet

After local testing, it's time to deploy.

The pkgs/cli package contains scripts for deployment and contract interaction.

Generate TypeScript API

First, build the contract package:

yarn contract build

This runs commands like:

rm -rf dist && tsc --project tsconfig.build.json && cp -Rf ./src/managed ./dist/managed && cp ./src/counter.compact ./dist

This generates typed APIs so circuits like increment can be called safely from the cli package.

Set environment variables

Deploying to Testnet requires the wallet seed used to sign transactions.

Create .env from template in pkgs/cli:

cp pkgs/cli/.env.example pkgs/cli/.env

Edit pkgs/cli/.env:

NETWORK_ENV_VAR=testnet
SEED_ENV_VAR=
INITIAL_COUNTER_ENV_VAR=
CACHE_FILE_ENV_VAR=
CONTRACT_ADDRESS=

Handle your seed with extreme care.

Make sure this file is excluded by .gitignore and never pushed to GitHub.

CLI unit test walkthrough

There are also unit tests for the CLI layer.

// This file is part of midnightntwrk/example-counter.
// Copyright (C) 2025 Midnight Foundation
// SPDX-License-Identifier: Apache-2.0
// Licensed under the Apache License, Version 2.0 (the "License");
// You may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

import { type Resource } from '@midnight-ntwrk/wallet';
import { type Wallet } from '@midnight-ntwrk/wallet-api';
import path from 'path';
import * as api from '../api';
import { type CounterProviders } from '../utils/common-types';
import { currentDir } from '../config';
import { createLogger } from '../utils/logger-utils';
import { TestEnvironment } from './commons';
import { describe, it, expect, beforeAll, afterAll } from 'vitest';

const logDir = path.resolve(currentDir, '..', 'logs', 'tests', `${new Date().toISOString()}.log`);
const logger = await createLogger(logDir);

describe('API', () => {
  let testEnvironment: TestEnvironment;
  let wallet: Wallet & Resource;
  let providers: CounterProviders;

  beforeAll(
    async () => {
      api.setLogger(logger);
      testEnvironment = new TestEnvironment(logger);
      const testConfiguration = await testEnvironment.start();
      wallet = await testEnvironment.getWallet();
      providers = await api.configureProviders(wallet, testConfiguration.dappConfig);
    },
    1000 * 60 * 45,
  );

  afterAll(async () => {
    await testEnvironment.saveWalletCache();
    await testEnvironment.shutdown();
  });

  it('should deploy the contract and increment the counter [@slow]', async () => {
    const counterContract = await api.deploy(providers, { privateCounter: 0 });
    expect(counterContract).not.toBeNull();

    const counter = await api.displayCounterValue(providers, counterContract);
    expect(counter.counterValue).toEqual(BigInt(0));

    await new Promise((resolve) => setTimeout(resolve, 2000));

    const response = await api.increment(counterContract);
    expect(response.txHash).toMatch(/[0-9a-f]{64}/);
    expect(response.blockHeight).toBeGreaterThan(BigInt(0));

    const counterAfter = await api.displayCounterValue(providers, counterContract);
    expect(counterAfter.counterValue).toEqual(BigInt(1));
    expect(counterAfter.contractAddress).toEqual(counter.contractAddress);
  });
});

Run these tests on both local and testnet environments.

Run unit tests locally

yarn cli test-api

Expected:

Test Files  1 passed (1)
      Tests  1 passed (1)
   Start at  08:41:12
   Duration  200.97s (transform 180ms, setup 72ms, collect 1.11s, tests 199.62s, environment 0ms, prepare 10ms)

Run unit tests against testnet

yarn cli test-against-testnet

Expected:

✓ src/test/counter.api.test.ts (1 test) 151857ms
  ✓ API (1)
    ✓ should deploy the contract and increment the counter [@slow]  125059ms

Test Files  1 passed (1)
    Tests  1 passed (1)
  Start at  08:47:54
  Duration  153.65s (transform 205ms, setup 93ms, collect 1.56s, tests 151.86s, environment 0ms, prepare 8ms)

Deployment script walkthrough

pkgs/cli/scripts/deploy.ts deploys the contract to Testnet.

It uses libraries such as @midnight-ntwrk/midnight-sdk and performs the following steps:

Load wallet seed from .env.
Build wallet object from the seed.
Configure providers for Testnet connection.
Execute deployment via api.deploy.

Run deployment

Deploy with:

yarn cli deploy

On success, the deployed contract address appears in terminal output:

[12:16:24.603] INFO (39506): Deploying counter contract...
[12:17:27.488] INFO (39506): Deployed contract at address: 020050e6bdae4c9e65023a252a6aba74323c1d9c1ba6e520f00e84a5fc1c75b100f3
[12:17:27.488] INFO (39506): Deployment transaction: 00000000c408a293e4e287285649623774b2be950bf0d385a20117ce79a99eb7315aa547
[12:17:27.489] INFO (39506): Contract address: 020050e6bdae4c9e65023a252a6aba74323c1d9c1ba6e520f00e84a5fc1c75b100f3
Counter contract deployed at: 020050e6bdae4c9e65023a252a6aba74323c1d9c1ba6e520f00e84a5fc1c75b100f3
[12:17:27.489] INFO (39506): Not saving cache as sync cache was not defined
Done in 90.16s.

Set that value in CONTRACT_ADDRESS inside your .env.

Execute `increment`

Finally, call the deployed contract's increment circuit.

Run:

yarn cli increment

This script reads CONTRACT_ADDRESS from .env, connects to the existing contract with api.joinContract, then calls api.increment.

If successful, you should see transaction info and the current counter value:

[12:33:37.176] INFO (47085): Incrementing...
[12:34:34.270] INFO (47085): Transaction 000000000202acbcd05e9f19e5144acc5f97953255840b8b932fc71b84520e715b7ca900 added in block 2485067
[12:34:34.271] INFO (47085): Increment transaction: 000000000202acbcd05e9f19e5144acc5f97953255840b8b932fc71b84520e715b7ca900 (block 2485067)
Counter incremented. txId=000000000202acbcd05e9f19e5144acc5f97953255840b8b932fc71b84520e715b7ca900 block=2485067
[12:34:34.271] INFO (47085): Checking contract ledger state...
[12:34:34.462] INFO (47085): Ledger state: 1
[12:34:34.463] INFO (47085): Current counter value: 1
[12:34:34.463] INFO (47085): Current counter value: 1
Current counter value: 1
[12:34:34.463] INFO (47085): Not saving cache as sync cache was not defined
Done in 128.20s.

If Current counter value: 1 appears, your public counter was incremented successfully.

This completes the hands-on section.

Current limitations and what's next

As of November 2025, Midnight is still in developer Testnet phase, and Mainnet has not launched yet.

So keep the following in mind:

Performance Finality on Testnet can take time.
API changes SDK/CLI behavior may change during active development. Check official docs regularly.
Feature scope Available tooling is still limited, though development is moving quickly with community feedback.
Frontend integration This was the area that took me the most research time during the hackathon. I also confirmed with the Midnight team onsite that stable frontend-contract integration libraries were not yet available at that time, so CLI was the practical path.

Midnight is a very ambitious project tackling one of Web3's most important challenges: privacy.

With Cardano's strong security model and community behind it, this ecosystem is definitely worth watching.

Closing thoughts

In this article, we walked through Midnight, Cardano's privacy-focused sidechain, and Compact, its smart contract language, in a practical hands-on format.

Midnight's approach to the blockchain "too transparent" problem.
Compact language for intuitive private DApp development with TypeScript-like syntax.
Data modeling with public, private, and witness.
Full flow from environment setup to implementation, testing, and Testnet deployment.

I am very excited to see how this evolves.

The hackathon itself was also an amazing experience, so I will keep following upcoming updates.

Thanks for reading.

References

The Future of Privacy: A Deep Dive into Cardano's Midnight & Zero-Knowledge Proofs

Haruki Kondo — Mon, 13 Apr 2026 14:08:48 +0000

Introduction: The "Too Transparent" Problem in Blockchain

Seventeen years have passed since the Bitcoin whitepaper was released.

bitcoin.org

Blockchain's immutability and transparency have been praised as groundbreaking mechanisms for trustworthy transactions. Because anyone can verify the ledger, blockchains created a new model of tamper-resistant trust.

However, that same "complete transparency" also creates barriers in areas involving business and personal privacy. This issue has been especially clear in enterprise settings, which is one reason private chain adoption became popular.

What if your full banking transaction history were visible to anyone in the world?
What if a company's confidential supply chain information were exposed to competitors?
What if personal medical records or voting history became public?

Even imagining this is unsettling. I believe this "too transparent" problem is one of the key reasons blockchain technology has not yet fully penetrated all parts of society.

Not everything can be public all the time. To solve this dilemma, a new light has emerged: Midnight.

Midnight Documentation | Midnight Docs

Build privacy-preserving applications with selective disclosure and zero-knowledge proofs on Midnight.

docs.midnight.network

Midnight is Cardano's partner chain (sidechain) specialized for data protection and privacy. In this article, I will guide you through Midnight in a story-driven way so you can understand its innovative technology and future potential.

Chapter 1: What Is Midnight? - A New Blockchain for Privacy

In one sentence, Midnight is a data-protection blockchain that enables Selective Disclosure. While many traditional blockchains force everything to be public, Midnight makes it possible to prove only the facts that need to be proven, without revealing anything else.

Note
There are other blockchains, such as Zcash, that adopt similar privacy-oriented approaches.

The technology that enables this is Zero-Knowledge Proofs (ZKPs).

Architecture Overview

Comparison of Traditional Blockchain vs Midnight with ZKPs

I have another article dedicated to Zero-Knowledge Proofs (ZKPs), so feel free to check that out as well:

【図解】ゼロ知識証明のPLONKとは？Groth16との違いを世界一わかりやすく解説！

zenn.dev

What Midnight aims to achieve

Midnight's mission is to remove the long-standing trade-off between data protection, ownership, and data utility.

For users: They can fully control their own data and decide who can see what, and how much.
For developers and enterprises: They can build innovative data-driven services without taking on privacy-violation risk.

This opens the door to use cases that were previously difficult or impossible on public blockchains due to confidentiality requirements.

Midnight's core: architecture and consensus

As a Cardano partner chain, Midnight is built on top of Cardano's robust security infrastructure.

Architecture: Midnight splits smart contract state into two parts:
1. Public state: Data that remains publicly available on-chain.
2. Private state: Data each user manages off-chain in their own local environment.
Kachina protocol: Public and private states are linked securely through Kachina, a research-driven unified framework. Users generate ZK proofs locally using private data, then submit only the proof to the blockchain for verification.
Consensus algorithm: Midnight adopts a hybrid consensus model combining AURA (block production) and GRANDPA (finality). Cardano stake pool operators (SPOs) participate as block producers.

Two native tokens: NIGHT and DUST

Midnight uses a unique dual-token model.

Token	Role	Characteristics
NIGHT	Governance, consensus	Unshielded token. Tradable and contributes to network security.
DUST	Transaction fees (gas)	Shielded resource. Non-transferable and privacy-preserving.

DUST acts as fuel, but because it is not a tradable asset, transaction metadata privacy is better preserved while keeping service costs more predictable.

Chapter 2: The Bond with Cardano - Why a Partner Chain?

Midnight is an independent chain, but its deep integration with Cardano is what unlocks its full potential.

Ecosystem Integration

Strategic integration between Cardano and Midnight Network

Inheriting security

Midnight addresses the challenge of network security by becoming a Cardano partner chain. It leverages Cardano's large, decentralized SPO network, allowing Midnight to access globally distributed, enterprise-grade infrastructure from day one.

How Midnight differs from Cardano

Cardano: Focuses on value storage/transfer and serving as a secure general-purpose decentralized platform.
Midnight: Uses Cardano's security as a base while specializing in データ保護とプライバシー as a dedicated computation layer.

They are complementary: Cardano provides the trust foundation, while Midnight enables privacy-sensitive applications.

Chapter 3: Compact - ZKP Smart Contracts with TypeScript-like Syntax

Note
"Aren't zero-knowledge proofs only for cryptography specialists?"

Midnight addresses this challenge with a new smart contract language: Compact.

midnightntwrk / compact

Compact Releases

Compact

Compact is the Midnight Network's smart contract language. This repository is only used to host Compact releases.

Contributing to Compact

The project welcomes contributions. If you would like to report a Compact bug, make a feature request, get the source code, etc. then you should do so at the Minokawa project's Compact repository.

View on GitHub

Why Compact is exciting

TypeScript-based DSL: Based on one of the world's most popular languages, allowing web developers to build privacy-focused apps with familiar syntax.
Abstraction of ZK complexity: The Compact compiler translates contract logic into the cryptographic material required for proof generation.
Privacy by Design: Data is treated as private by default. To expose private data, you must explicitly wrap it with disclose().

// Conceptual Compact example

// Private user vote
witness userVote: private Field;

// Public vote result
let results: public Field;

// Voting circuit
circuit vote() {
  // Update result when validation passes
  // Who voted for what remains private
  results = results + 1;

  // If you want to reveal vote content, do it explicitly
  // disclose(userVote);
}

Chapter 4: Use Cases Unlocked by Midnight

Digital ID / KYC: Prove you are over 18 without revealing your full birth date.
Anonymous voting: Truly fair voting systems with verified eligibility and ballot secrecy.
Healthcare: Private medical records used for aggregate analysis or AI research.
DeFi: Access financial services without exposing portfolios or strategies.
AI and LLMs: Use sensitive data for model training while preserving privacy.

Summary: The Dawn of a New Privacy Era

Midnight is foundational technology for a safer, fairer digital society where individuals retain data sovereignty and enterprises can innovate responsibly.

Thank you for reading! 🚀

Developer Resources

Midnight Developer Hub
midnightntwrk / midnight-awesome-dapps

Midnight Awesome Dapps
Awesome Midnight dApps

This project is built on the Midnight Network.

A curated list of awesome Midnight dApps, tools, and resources

Contents
- Awesome Midnight dApps
  
  Contents
  
  Getting Started
  
  Smart Contract Primitives
  
  Starter Templates
  
  Developer Tools
  
  Finance & DeFi
  
  Identity & Privacy
  
  Gaming
  
  Governance
  
  Dormant Projects
  
  Learning Resources
  
  Documentation
  
  Getting Started
  
  Tutorials
  
  Community
  
  Community Projects
  
  Contributing
  
  Submission Criteria
  
  License
Important

Community-contributed projects are shared for inspiration and exploration. These repositories are not maintained by the Midnight team, and their functionality may vary.

Note

🔹 = Official Midnight Ecosystem Partner
🏆 = Hackathon winners

Getting Started

Official dApps and tools maintained by the Midnight team (for education + onboarding)
- Example Counter - Simple increment/decrement app demonstrating state management
- Hello World Compact - Minimal Hello World smart contract for Midnight. Deploy to Preprod and store/read messages on-chain
- Example Bboard - Bulletin board with multi-user interactions and privacy patterns
- Example ZK Loan - ZK-powered…
View on GitHub
MeshJS / midnight-starter-template

Mesh Midnight starter template
🚀 EDDA - Midnight Starter Template
- A starter template for building on Midnight Network with React frontend and smart contract integration.
- Live Demo → counter.nebula.builders
📦 Prerequisites
- Node.js (v23+) & npm (v11+)
- Docker
- Git LFS (for large files)
- Compact (Midnight developer tools)
- Lace (Browser wallet extension)
- Faucet (Preview Network Faucet)
Known Issues
- There’s a not-yet-fixed bug in the arm64 Docker image of the proof server.
- Workaround: Use Bricktower proof server. bricktowers/proof-server:6.1.0-alpha.6
🛠️ Setup

1️⃣ Install Git LFS
# Install and initialize Git LFS sudo dnf install git-lfs # For Fedora/RHEL git lfs install
2️⃣ Install Compact Tools
# Install the latest Compact tools curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh
# Install the latest compiler # Compact compiler version 0.27 should be downloaded manually. Compact tools does not support it currently. compact update +0.27.0
3️⃣ Install Node.js and docker
- Node.js & npm
- Docker
4️⃣ Verify Installation
…
View on GitHub

References

Sera Protocol Tempo MPP: The Ultimate Cross-Border Payment Solution

Haruki Kondo — Sun, 29 Mar 2026 00:40:51 +0000

This article was written in collaboration with AI!

Introduction

Hello everyone!

In our ongoing series exploring Sera Protocol, we've built MCP servers and even developed a specialized Agent SKILL.

Today, we're diving into a fascinating concept: the synergy between Sera Protocol and the recently announced Machine Payments Protocol (MPP) from Stripe and Tempo!

Haruki Kondo

Mar 20

Deep Dive into Machine Payments Protocol (MPP): Resurrecting HTTP 402 for the AI Agent Era

#stripe #blockchain #ai #web3

Comments

4 min read

MPP has finally given AI the "hands to pay." However, the moment they cross borders, they hit a hard reality: the "Currency Wall." Let's explore how Sera Protocol smashes this barrier.

1. The "Exchange Wall" Facing AI Agents

MPP (Machine Payments Protocol) brings HTTP 402 "Payment Required" to life after 20 years, allowing AI to discover, negotiate, and settle payments in a single request.

But in practice, we encounter this tragic scenario:

API Server (USA): "This image generation costs $0.01 USDX (USD Stablecoin)."
AI Agent (Japan): "I only have JPYC (Japanese Yen Stablecoin)..."

For humans, credit cards handle this behind the scenes. For an autonomous AI agent, this currency mismatch means "Service Unavailable."

In the machine world, someone must act as an instant, on-chain middleman. This is the necessity of "OnChain FX" for machines.

2. The Tempo L1 "Highway" and Sera's "Gasoline"

According to the Tempo official documentation (OnChain FX), their goal is to eliminate the "Stablecoin Sandwich."

Traditional cross-border payments often look like "Local Currency → USD Stablecoin → Local Currency," relying on off-chain banks and exchanges that are slow and expensive.

This is where the synergy between Tempo L1 and Sera Protocol explodes.

Tempo L1's "Payment Lanes"

Tempo features dedicated block space called "Payment Lanes." Even if a sudden NFT minting craze spikes gas fees elsewhere, payment traffic glides through at 0.1 cents, completely unaffected.

TIP-20 "Multi-Currency Fees"

The genius of Tempo’s TIP-20 token standard is that "you can pay gas fees in any stablecoin—USDX, JPYC, you name it." Agents don't need to hold a separate native token (like ETH) just for gas.

On this "payment-optimized highway," Sera Protocol acts as the engine that atomically bridges different currencies.

3. Why AI Agents Need a Central Limit Order Book (CLOB)

You might wonder, "Why not just use an AMM like Uniswap?" For an AI agent, an AMM is often a "bundle of uncertainty."

"Rational" Limit Orders: AI operates on logic. It dislikes the "luck-based" slippage of AMMs. With Sera, an agent can make autonomous decisions: "I will buy at this rate; otherwise, I will wait."
The Magic of Index Management: Sera’s Arithmetic Price Model manages prices using uint16 indices. For an AI, these are easy-to-process "numeric values," allowing for lightning-fast arbitrage and price comparisons across multiple markets.
Rights Transfer via Order NFTs: Sera orders are NFTs. Instead of sending the exchanged USDX itself, an AI could transfer the "right to the completed exchange (the NFT)" directly to the service provider, enabling next-generation payment flows.

4. Synergy Breakdown: The MPP + Sera Atomic Flow

When an AI agent combines Sera and MPP for cross-border payments, the concept of "going to an exchange" disappears. Instead, "currency exchange becomes a seamless step within the payment process."

With this flow, the AI can buy resources worldwide without even caring which currency it holds.

5. Implementation Concept: Autonomous Exchange & Payment Logic

If you are giving your AI "hands and feet" using an MCP Server, the code becomes surprisingly simple.

// Internal logic for an AI agent receiving a 402 Challenge
async function onPaymentRequired(challenge: MPPChallenge) {
  const { amount: usdAmount, currency } = challenge; // 0.01 USDX

  // 1. Check the rate until satisfied
  const bestRate = await sera.getBestPrice('JPYC/USDX');
  if (bestRate > MY_ACCEPTABLE_LIMIT) {
    throw new Error("Exchange rate is too poor; aborting purchase for now.");
  }

  // 2. Exchange exactly what is needed
  // Sera's Index-based precision handles fractions like 10.5 JPYC perfectly
  const tx = await sera.swapAndClaim({
    from: 'JPYC',
    to: 'USDX',
    amount: usdAmount,
    index: bestRate
  });

  // 3. Pay immediately with the secured USDX
  return await mpp.pay(challenge, {
    useToken: 'USDX',
    gasToken: 'JPYC' // The power of Tempo!
  });
}

The AI optimizes which currency to use and which currency to pay fees with based on real-time rates. This is the true face of the "Programmable Economy" built by Stripe and Sera.

The Dawn of the Machine Economy is Here.

I’ve previously introduced Sera Protocol as a "new DEX," but seeing it paired with Tempo MPP reveals its full silhouette.

Sera is the "Currency Translator" for the Machine Economy.

With the payment network expanded by Stripe, the highway paved by Tempo, and the "shape of currency" refined by Sera Protocol, AI agents are finally ready to roam the world freely.

As an evangelist, I’m excited to implement this future with all of you. I look forward to showcasing a "Self-Exchanging Payment Agent" at an upcoming hackathon.

Why not empower your AI with Sera—the ultimate money changer?

References:

Developing and Deploying an x402 MCP Server to Cloudflare Workers using VibeKanban!

Haruki Kondo — Sat, 21 Mar 2026 06:43:05 +0000

Introduction

Hello everyone!

I recently properly studied Cloudflare Workers for the first time, so I'm writing this article to share my findings!

This post will cover what I tried during implementation and how to deploy an MCP server to Cloudflare Workers!

What is Cloudflare Workers?

cloudflare.com

Cloudflare Workers is a serverless computing platform provided by Cloudflare.

While there are some constraints like bundle size, its charm lies in the ease of deploying TypeScript/JavaScript apps with a frontend-like feel! It also integrates seamlessly with other major Cloudflare services like KV and D1.

Great Compatibility with Hono

hono.dev

Hono is a lightweight, fast, and modern web framework for developing web applications and APIs, primarily in TypeScript/JavaScript. Being fast and lightweight, it is extremely compatible with Cloudflare Workers!

What is Vibe Kanban?

Vibe Kanban - Orchestrate AI Coding Agents

Get the most out of coding agents like Claude Code, Gemini CLI and Amp. Orchestrate multiple AI coding agents, track tasks, and manage your development workflow efficiently.

vibekanban.com

Vibe Kanban is a tool that manages AI coding agents (like Claude Code or Codex) in a Kanban format (task visualization) to realize automated development flows!

Development Workflow with cc-sdd + VibeKanban + GitWorkTree

I practiced the following development workflow for this implementation:

0. Formulate product vision and concept.
1. Create requirements, design documents, and task lists with cc-sdd.
2. Register tasks in VibeKanban (register as GitHub Issues).

3. Prepare working directories with git worktree.

4. Parallel execution of tasks.

5. Self-review deliverables and create PRs.

I used CodeRabbit for code reviews!

Converting and Registering cc-sdd Tasks to VibeKanban

I used a prompt like this to convert tasks generated by cc-sdd into VibeKanban tasks:

Review the task list generated by @(cc-sdd) and register the work plan as Tasks in vibe_kanban.

Each task should include:
- Refer to @design.md for design details.
- Specific work content for this task.
- Dependencies on other tasks or if parallel work is possible.
- If it can be executed in parallel, add a + to the title.

Register tasks in descending order.

The best part is being able to turn them directly into GitHub Issues!

What is x402?

x402.org

x402 is a standard protocol for stablecoin payments announced by Coinbase, a prominent cryptocurrency exchange in the US.

True to its name, it adopts the HTTP status code 402 Payment Required and has gained significant attention for its compliance with the HTTP protocol.

Cloudflare has not only co-founded the x402 Foundation but, given its compatibility with AI agents, it's a technology that has garnered immense interest within various blockchain tech stacks.

Launching the x402 Foundation with Coinbase, and support for x402 transactions

Cloudflare is partnering with Coinbase to create the x402 Foundation and adding x402 support to the Agents SDK & MCP Servers.

blog.cloudflare.com

About the App I Built

Overview

I developed and deployed an x402 backend server and an MCP server on Cloudflare Workers. I created a sample app where stablecoin payments are processed simultaneously when weather information is retrieved through a chat interface within a GPT App!

What it can do:

Call the get_weather tool from a GPT App to retrieve weather information.
Access /weather only for requests that have passed x402 payment verification.
Deploy x402server and mcpserver separately on Cloudflare Workers.
Verify the integrated operation of mcpserver -> x402FetchClient -> x402server via E2E tests.

Sample Code

The source code for this project is available in the following GitHub repository:

mashharuki / vibekanban-gitworktree-sample

VibeKanbanとGitWorktreewo

vibekanban-gitworktree-sample

VibeKanbanとGitWorktreeを掛け合わせたサンプルアプリ

概要

x402バックエンドサーバーとMCPサーバーを使ってGPT App内のチャットインターフェースから天気予報の情報を取得すると同時にステーブルコイン支払いが行われるサンプルアプリ。

このプロジェクトでできること

GPT App から get_weather ツールを呼び出して天気情報を取得
x402 による支払い検証を通過したリクエストのみ /weather にアクセス
Cloudflare Workers 上で x402server と mcpserver を分離デプロイ
E2E テストで mcpserver -> x402FetchClient -> x402server の結合動作を検証

構成

リポジトリ構成

パス	役割	主な技術
`pkgs/x402server`	天気 API と x402 決済検証を提供するバックエンド	Hono / x402 / Cloudflare Workers / TypeScript
`pkgs/mcpserver`	GPT App から呼び出される MCP サーバー。`x402server` を決済付きで呼び出す	Hono MCP / MCP SDK / x402 fetch / Cloudflare Workers / TypeScript
`pkgs/*/__tests__`	単体・結合テスト群	Vitest
ルート (`package.json`)	monorepo の共通スクリプト・ワークスペース管理	pnpm workspace

リクエストの流れ

GPT App から MCP ツール get_weather を実行
mcpserver が x402-fetch-client で /weather を呼び出し
x402server が paymentMiddleware で支払いを検証
検証後に天気データを返却

機能一覧

機能	概要	提供パッケージ	補足
ヘルスチェック API	サービス稼働確認 (`/`, `/health`)	`x402server`, `mcpserver`	監視・疎通確認に利用
天気情報取得 API	都市名を受けて天気を返却 (`/weather`)	`x402server`	都市未登録時は 404
x402 課金付きアクセス制御	`/weather` を課金保護し未決済時は 402 を返却	`x402server`	価格・ネットワークは環境変数で設定
MCP ツール公開	`get_weather` ツールを外部クライアントへ公開	`mcpserver`	入力検証・エラー整形を実施
x402 決済付き fetch クライアント	支払い情報付きで `x402server` を呼び出す	`mcpserver`	Service Binding

…

View on GitHub

Repository Structure

Path	Role	Key Technologies
`pkgs/x402server`	Backend providing Weather API and x402 payment verification.	Hono / x402 / Cloudflare Workers / TypeScript
`pkgs/mcpserver`	MCP server called by GPT App. Calls `x402server` with payment.	Hono MCP / MCP SDK / x402 fetch / Cloudflare Workers / TypeScript
Root (`package.json`)	Common scripts and workspace management for the monorepo.	pnpm workspace

List of Implemented Features

Feature	Overview	Provided Package	Notes
Health Check API	Service availability check (`/`, `/health`).	`x402server`, `mcpserver`	Used for monitoring and connectivity checks.
Weather Info API	Returns weather based on city name (`/weather`).	`x402server`	Returns 404 if city is not registered.
x402 Paid Access Control	Protects `/weather` and returns 402 if unpaid.	`x402server`	Price and network configured via env vars.
MCP Tool Exposure	Exposes `get_weather` tool to external clients.	`mcpserver`	Performs input validation and error formatting.
x402 Payment-enabled Fetch Client	Calls `x402server` with payment information.	`mcpserver`	Supports both Service Binding and URLs.
E2E Integration Test	Verifies flow from MCP to backend.	`mcpserver` tests	Confirms 402/404/Success cases.

Key Implementation Points

Let's pick up and introduce some important implementation parts.

x402 Server

First, the x402 server! You need to set environment variables in wrangler.jsonc. Since there's no highly sensitive information here, I'm not using the Secret feature for these.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "x402server",
  "main": "src/index.ts",
  "compatibility_date": "2026-02-23",
  "compatibility_flags": ["nodejs_compat"],
  "vars": {
    "SERVER_WALLET_ADDRESS": "0x51908F598A5e0d8F1A3bAbFa6DF76F9704daD072",
    "FACILITATOR_URL": "https://x402.org/facilitator",
    "X402_PRICE_USD": "$0.01",
    "X402_NETWORK": "eip155:84532"
  }
}

The x402 server is built on Hono. The main code is in src/app.ts. x402 middleware is applied only to specific routes.

import { paymentMiddleware } from "@x402/hono";
import { Hono } from "hono";
import { createRoutes } from "./route";
import { createResourceServer, resolvePaymentOptions } from "./utils/config";
import type { CreateAppOptions, ErrorResponse, WeatherService } from "./utils/types";
import { createMockWeatherService } from "./weather/service";

const toErrorResponse = (statusCode: number, message: string): ErrorResponse => ({
  statusCode,
  message,
});

export const createApp = (
  weatherService: WeatherService = createMockWeatherService(),
  options: CreateAppOptions = {},
): Hono => {
  const app = new Hono();
  const enablePayment = options.enablePayment ?? true;

  if (enablePayment) {
    const paymentOptions = resolvePaymentOptions(options.payment);
    const resourceServer = createResourceServer(paymentOptions);
    const routes = createRoutes(paymentOptions);
    const protectedRouteKeys = new Set(Object.keys(routes));
    let resourceServerInitialization: Promise<void> | null = null;

    app.use(async (c, next) => {
      const routeKey = `${c.req.method.toUpperCase()} ${c.req.path}`;
      if (!protectedRouteKeys.has(routeKey)) return next();

      if (!resourceServerInitialization) {
        resourceServerInitialization = resourceServer.initialize().catch((error) => {
          resourceServerInitialization = null;
          throw error;
        });
      }
      await resourceServerInitialization;
      return next();
    });

    app.use(paymentMiddleware(routes, resourceServer, undefined, undefined, false));
  }

  app.get("/", (c) => c.json({ status: "ok" }, 200));
  app.get("/health", (c) => c.json({ status: "ok" }, 200));

  app.get("/weather", async (c) => {
    const city = c.req.query("city")?.trim();
    if (!city) return c.json(toErrorResponse(400, "city query parameter is required"), 400);

    try {
      const weather = await weatherService.getWeatherByCity(city);
      if (!weather) return c.json(toErrorResponse(404, "city not found"), 404);
      return c.json(weather, 200);
    } catch {
      return c.json(toErrorResponse(503, "weather service unavailable"), 503);
    }
  });

  return app;
};

Regarding the weather retrieval logic: for verification purposes, I've implemented it to return hardcoded demo data instead of hitting an external API. In a production setting, this would be where you call an external service.

import { WeatherData, WeatherService } from "../utils/types";

const MOCK_WEATHER_DATA: ReadonlyArray<WeatherData> = [
  { city: "Tokyo", condition: "Sunny", temperatureC: 28, humidity: 60 },
  { city: "Osaka", condition: "Cloudy", temperatureC: 26, humidity: 65 },
  { city: "New York", condition: "Rainy", temperatureC: 22, humidity: 72 },
];

const normalizeCity = (city: string): string => {
  const trimmed = city.trim().replace(/^['\"]+|['\"]+$/g, "");
  const withoutCountry = trimmed.split(",")[0]?.trim() ?? trimmed;
  return withoutCountry.toLowerCase();
};

export const createMockWeatherService = (): WeatherService => {
  return {
    async getWeatherByCity(city: string): Promise<WeatherData | null> {
      const normalized = normalizeCity(city);
      return MOCK_WEATHER_DATA.find((item) => normalizeCity(item.city) === normalized) ?? null;
    },
  };
};

x402-specific settings are consolidated in src/utils/config.ts. Implementing an x402 server requires configuring a facilitator and a resource server.

Briefly, a facilitator acts as a bridge between the API you want to apply x402 to and the blockchain, handling signature verification and transaction submission for payments. Facilitators are recommended to save development effort.

MCP Server

The MCP server is also based on Hono.

import { StreamableHTTPTransport } from "@hono/mcp";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { Hono } from "hono";
import { cors } from "hono/cors";
// ... (imports)

export const createApp = (options: CreateAppOptions = {}): Hono => {
  const app = new Hono();
  const mcpServer = new McpServer({ name: "x402-weather-payment-mcpserver", version: "1.0.0" });
  // ... (logic to handle MCP via Streamable HTTP transport)
  return app;
};

The x402 client setup is implemented in x402-fetch-client.ts.

// ... (X402FetchClient implementation using wrapFetch from @x402/fetch)

And the tool for retrieving weather information:

// ... (get_weather tool registration using McpServer.registerTool)

The Point I Got Stuck On

I learned this for the first time: when calling one Worker from another, you cannot simply specify the URL; you must use Bindings. You need to register this in your wrangler.jsonc.

{
  "services": [
    {
      "binding": "X402SERVER",
      "service": "x402server"
    }
  ]
}

How to Deploy to Cloudflare Workers!

Now that the code is explained, let's look at the deployment!

Setup

Install dependencies:

pnpm i

x402 Backend Server

Deploy:

pnpm x402server run deploy

MCP Server

Condition: x402server must already be deployed! Register the private key for the x402 client and the x402server endpoint using Secrets.

pnpm mcpserver run secret CLIENT_PRIVATE_KEY --name mcpserver
pnpm mcpserver run secret X402_SERVER_URL --name mcpserver

Deploy:

pnpm mcpserver run deploy

How to Call from Within ChatGPT

Register the MCP server endpoint in your GPT App.
Add the app from the + button and ask for the weather.
If the weather is returned and USDC payment is processed, you're set!

Check the block explorer to confirm the stablecoin payment!

Summary

That's it for now! While you can achieve similar results using AWS Lambda or AgentCore, Cloudflare Workers is highly recommended for quick and easy experimentation. The sample code for x402 is abundant and fits perfectly!

Thank you for reading until the end!

References

(Included original Japanese references)
Official Site - Vibekanban
GitHub - Vibekanban

Build and Deploy a Voice AI Agent on AWS with the ElevenLabs SDK!

Haruki Kondo — Sat, 21 Mar 2026 01:59:52 +0000

Introduction

Have you ever tried developing a Voice AI Agent?

"Voice AI? That sounds complicated..."

If you're thinking that, you're not alone. While there are advanced tools like Google's ADK (Agent Development Kit), there is actually a much simpler way to get started!

kazunori279 / adk-streaming-guide

Comprehensive guide for bidirectional streaming with Google's Agent Development Kit (ADK)

Read @claude.md

View on GitHub

The answer is ElevenLabs.

In this article, I’ll show you how to build a Voice AI Agent using React + Vite and how to deploy it to AWS using the AWS CDK!

Source Code

The complete source code for this project is available on GitHub:

mashharuki / Elevenlab-React-Sample

Elevenlab-React-Sample

前提条件

動かす前にElavenLabのコンソールからAgentを作ってIDを控えておく必要あり

MCPの追加方法

コンソールから指定したAI AgentにMCPを追加する(カスタムMCPサーバーとして追加する！)

View on GitHub

What is ElevenLabs?

ElevenLabs is a world-class AI audio platform developed by ElevenLabs, Inc. based in New York. It is renowned for its ability to generate extremely natural and emotionally expressive speech.

elevenlabs.io

Creating an AI Agent with ElevenLabs

You can find the developer documentation here:

elevenlabs.io

To create an AI Agent, you first need to access the dashboard:

AI Voice Generator & Text to Speech | ElevenLabs

Rated the best text to speech (TTS) software online. Create premium AI voices for free and generate text to speech voiceovers in minutes with our character AI voice generator. Use free text to speech AI to convert text to mp3 in 29 languages with 100+ voices.

elevenlabs.io

Click on Agents on the left sidebar and select Add Agent.

For this tutorial, select Personal Agent.

Enter the name and purpose of your AI Agent.

Next, specify the System Prompt, Language, and Voice Type.

One of the best things about ElevenLabs is the sheer number of supported languages and high-quality voices!

Once configured, click the Deploy button in the top right. An Agent ID will be generated—make sure to copy and save it!

Although not covered in detail here, you can also connect your agent to MCP (Model Context Protocol) servers!

Integrating into React with the SDK

ElevenLabs provides a dedicated React SDK that makes integration seamless.

elevenlabs.io

Implementation Highlights

Here are the key parts of the implementation:

Loading the Agent ID

  // Agent ID created in the ElevenLabs dashboard
  const agentIdFromEnv =
    typeof import.meta.env.VITE_ELEVENLABS_AGENT_ID === 'string'
      ? import.meta.env.VITE_ELEVENLABS_AGENT_ID
      : ''

Setting up useConversation

We use the useConversation hook from the React SDK to manage conversation states and event handlers.

  // Using the useConversation hook to manage state and events
  const conversation = useConversation({
    micMuted,
    volume: volumeRate,
    onMessage: (message: unknown) => {
      setMessages((prevMessages) => [...prevMessages, buildMessageItem(message)])
    },
    onError: (error: unknown) => {
      setErrorText(buildErrorText(error))
    },
    onStatusChange: (payload: { status: string }) => {
      setStatusText(payload.status)
    },
    onModeChange: (payload: { mode: string }) => {
      setModeText(payload.mode)
    },
    onConnect: () => {
      setErrorText('')
    },
    onDisconnect: () => {
      setConversationId('')
    },
  })

Requesting Microphone Permission

  const handleRequestMic = async (): Promise<void> => {
    setErrorText('')
    try {
      // Request mic permission and update state if granted
      await navigator.mediaDevices.getUserMedia({ audio: true })
      setMicReady(true)
    } catch (error: unknown) {
      setErrorText(buildErrorText(error))
    }
  }

Starting a Session

Use the conversation.startSession method to begin the interaction.

  const handleStartSession = async (): Promise<void> => {
    setErrorText('')
    if (!agentIdFromEnv) {
      setErrorText('Please set VITE_ELEVENLABS_AGENT_ID')
      return
    }
    try {
      if (!micReady) {
        // Activate mic if not already ready
        await navigator.mediaDevices.getUserMedia({ audio: true })
        setMicReady(true)
      }
      // Start session and save the conversation ID
      const newConversationId = await conversation.startSession({
        agentId: agentIdFromEnv,
        connectionType,
        userId: userId ? userId : undefined,
      })
      setConversationId(newConversationId)
    } catch (error: unknown) {
      setErrorText(buildErrorText(error))
    }
  }

Sending Voice Data

To send a message to the agent, use conversation.sendUserMessage.

  const handleSendMessage = (): void => {
    const trimmedText = inputText.trim()
    if (!trimmedText) {
      return
    }
    conversation.sendUserMessage(trimmedText)
    setInputText('')
  }

Ending the Session

  const handleEndSession = async (): Promise<void> => {
    setErrorText('')
    try {
      // End the session and clear the state
      await conversation.endSession()
    } catch (error: unknown) {
      setErrorText(buildErrorText(error))
    }
  }

Deploying to AWS with CDK

Now, let's deploy our Voice AI Agent application to AWS! We’ll use the AWS CDK to set up an S3 + CloudFront architecture.

CDK Stack File

This is a simplified implementation optimized for testing.

  import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
  import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
  import * as s3 from 'aws-cdk-lib/aws-s3';
  import * as s3deploy from 'aws-cdk-lib/aws-s3-deployment';
  import * as cdk from 'aws-cdk-lib/core';
  import { Construct } from 'constructs';
  import * as path from 'path';

  export class CdkStack extends cdk.Stack {
    constructor(scope: Construct, id: string, props?: cdk.StackProps) {
      super(scope, id, props);

      // S3 Bucket for static assets
      const websiteBucket = new s3.Bucket(this, 'WebsiteBucket', {
        blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
        encryption: s3.BucketEncryption.S3_MANAGED,
        enforceSSL: true,
        removalPolicy: cdk.RemovalPolicy.DESTROY,
        autoDeleteObjects: true,
      });

      // CloudFront Distribution
      const distribution = new cloudfront.Distribution(this, 'Distribution', {
        defaultBehavior: {
          origin: origins.S3BucketOrigin.withOriginAccessControl(websiteBucket),
          viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
          cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,
        },
        defaultRootObject: 'index.html',
        // SPA routing: fallback to index.html
        errorResponses: [
          {
            httpStatus: 403,
            responseHttpStatus: 200,
            responsePagePath: '/index.html',
            ttl: cdk.Duration.minutes(5),
          },
          {
            httpStatus: 404,
            responseHttpStatus: 200,
            responsePagePath: '/index.html',
            ttl: cdk.Duration.minutes(5),
          },
        ],
      });

      // Deploy built assets to S3
      new s3deploy.BucketDeployment(this, 'DeployWebsite', {
        sources: [s3deploy.Source.asset(path.join(__dirname, '../../my-app/dist'))],
        destinationBucket: websiteBucket,
        distribution,
        distributionPaths: ['/*'],
      });

      // Outputs
      new cdk.CfnOutput(this, 'DistributionDomainName', {
        value: distribution.distributionDomainName,
      });
    }
  }

Installation

Run the following in both cdk and my-app directories:

  bun install

Environment Variables

Create a .env file in the my-app directory and set your Agent ID:

  VITE_ELEVENLABS_AGENT_ID=your_agent_id_here

Build and Deploy

Build the frontend assets:

  bun run build

Then deploy the CDK stack:

  bun cdk deploy

Once the deployment is complete, click the CloudFront URL. You should see the following screen:

Try turning on the mic and starting a session—you can now talk to your AI agent!

Cleanup

Remember to destroy the resources when you're finished testing:

  bun cdk destroy

Summary

Building a Voice AI Agent is surprisingly easy with the right tools! By combining ElevenLabs with React and AWS, you can create natural, interactive experiences in no time.

Imagine connecting this to an MCP server (like the Draw.io MCP)—the possibilities are endless. We are moving towards a future where interacting via voice rather than keyboard will be the norm, so getting comfortable with SDKs like ElevenLabs is definitely a valuable skill.

Thank you for reading!

Motia Strands Agent SDK: A Guide to AI Agent Development 3

Haruki Kondo — Sat, 21 Mar 2026 01:20:33 +0000

Introduction

Hello everyone!

This is the third installment in our series on AI agent development using Motia and the Strands Agent SDK!

Motia × Strands Agent SDKで作るAIエージェント開発入門

zenn.dev

Haruki Kondo for AWS Community Builders

Mar 15

Introduction to AI Agent Development with Motia Strands Agent SDK 2

#aws #ai #typescript #react

Comments 2

4 min read

In the previous post, we explored how to call the Motia backend API from a frontend application.

In this article, we'll focus on containerizing the backend with Docker and deploying it to AWS using the AWS Cloud Development Kit (CDK)!

Note: I won't be diving into the specific frontend or backend logic implementation details here. If you're interested in those, please check out the previous posts!

I hope you enjoy reading this to the end!

Source Code Used in This Post

The complete source code is available in the following GitHub repository:

mashharuki / Motia-Strands-Agent-Sample

バックエンドフレームワーク Motia と AWS Strands Agentを掛け合わせてみたサンプルリポジトリ

Motia-Strands-Agent-Sample

バックエンドフレームワーク Motia と AWS Strands Agentを掛け合わせてみたサンプルリポジトリ

テンプレプロジェクト生成

motia-cli create my-project

以下のようになればOK!

  ╭───────────────────────────────────────╮
  │  == Welcome to Motia powered by iii   │
  ╰───────────────────────────────────────╯

░███     ░███               ░██    ░██                ░████████████
░████   ░████               ░██                      ░██         ░██
░██░██ ░██░██  ░███████  ░████████ ░██ ░██████      ░██  ░██████  ░██    ░██░██░██
░██ ░████ ░██ ░██    ░██    ░██    ░██      ░██     ░██       ░██ ░██
░██  ░██  ░██ ░██    ░██    ░██    ░██ ░███████     ░██  ░███████ ░██    ░██░██░██
░██       ░██ ░██    ░██    ░██    ░██░██   ░██     ░██ ░██   ░██ ░██    ░██░██░██
░██       ░██  ░███████      ░████ ░██ ░█████░██    ░██  ░█████░████     ░██░██░██
                                                     ░██
                                                      ░████████████

  - Create a new Motia project powered by iii
  Select language: Mixed (Node.js + Python, requires both)
  Do you have iii installed? yes

  Creating project in ./my-project

Node.js + Pythonのミックス構成となっている

.
├── iii-config.yaml
├── nodejs
│   ├── package.json
│   ├── src
│   │   ├── create-ticket.step.ts
│   │   └── list-tickets.step.ts
│   └── tsconfig.json
└── python
    ├── pyproject.toml
    └── steps
        ├── __init__.py

…

View on GitHub

Dockerizing Motia for ECS/App Runner

The most challenging part of this project was creating the Dockerfile.

Since Motia requires both Node.js and Python runtimes to be active simultaneously, setting up the environment (like PATH configurations) was a bit tricky at first.

The following Dockerfile configuration successfully runs the Motia backend:

FROM node:20-slim

# Install Python + uv
RUN apt-get update && apt-get install -y python3 python3-venv curl && rm -rf /var/lib/apt/lists/*
RUN curl -LsSf https://astral.sh/uv/install.sh | sh

# Install iii CLI
RUN curl -fsSL https://install.iii.dev/iii/main/install.sh | sh
ENV PATH="/root/.iii/bin:/root/.local/bin:${PATH}"

WORKDIR /app

# Node.js Dependencies
COPY nodejs/package*.json nodejs/
RUN cd nodejs && npm install

# Python Dependencies
COPY python/pyproject.toml python/
RUN cd python && /root/.local/bin/uv venv && /root/.local/bin/uv pip install -r pyproject.toml

# Source Code & Config
COPY nodejs/ nodejs/
COPY python/ python/
COPY iii-config.yaml .

# Data Directory
RUN mkdir -p data

EXPOSE 3111 3112

CMD ["iii", "-c", "iii-config.yaml"]

While supporting two runtimes makes the Dockerfile more complex, it ensures that both the Node.js agent logic and Python tools can run in a single container.

After building this, I realized there's an official Docker setup guide in the documentation as well! Check it out if you're interested:

motia.dev

Explaining the CDK Stack

Next, let's break down the CDK Stack.

For the backend container runtime, I decided to use AWS App Runner for the first time!

Managed Container Apps Service – AWS App Runner – Amazon Web Services

AWS App Runner helps you deploy and scale from your source code or container image to a secure web application on AWS.

aws.amazon.com

Since the agent needs to call Amazon Bedrock, I've added the necessary IAM permissions to the instance role. The frontend follows a standard S3 + CloudFront architecture.

import * as apprunner from 'aws-cdk-lib/aws-apprunner';
import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
import * as ecr_assets from 'aws-cdk-lib/aws-ecr-assets';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as s3deploy from 'aws-cdk-lib/aws-s3-deployment';
import * as cdk from 'aws-cdk-lib/core';
import { Construct } from 'constructs';
import * as path from 'path';

/**
 * CDK Stack for Motia Strands Agent
 * - S3 Bucket for frontend static files
 * - App Runner Service for backend (Docker image from local directory)
 * - CloudFront Distribution with S3 OAC and App Runner custom origin
 * - IAM roles for App Runner to access ECR and Bedrock
 */
export class CdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ========================================
    // 1. S3 Bucket - Frontend Static Files
    // ========================================
    const siteBucket = new s3.Bucket(this, 'FrontendBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
    });

    // ========================================
    // 2. Docker Image Asset - Motia Backend
    // ========================================
    const imageAsset = new ecr_assets.DockerImageAsset(this, 'MotiaBackendImage', {
      directory: path.join(__dirname, '../../my-project'),
      platform: ecr_assets.Platform.LINUX_AMD64,
    });

    // ========================================
    // 3. IAM Roles for App Runner
    // ========================================

    // Access Role for ECR
    const accessRole = new iam.Role(this, 'AppRunnerAccessRole', {
      assumedBy: new iam.ServicePrincipal('build.apprunner.amazonaws.com'),
    });
    imageAsset.repository.grantPull(accessRole);

    // Instance Role for Bedrock Access
    const instanceRole = new iam.Role(this, 'AppRunnerInstanceRole', {
      assumedBy: new iam.ServicePrincipal('tasks.apprunner.amazonaws.com'),
    });
    instanceRole.addToPolicy(new iam.PolicyStatement({
      actions: [
        'bedrock:InvokeModel',
        'bedrock:InvokeModelWithResponseStream',
      ],
      resources: ['*'],
    }));

    // ========================================
    // 4. App Runner Service (L1 - CfnService)
    // ========================================
    const appRunnerService = new apprunner.CfnService(this, 'MotiaBackendService', {
      serviceName: 'motia-backend',
      sourceConfiguration: {
        authenticationConfiguration: {
          accessRoleArn: accessRole.roleArn,
        },
        imageRepository: {
          imageIdentifier: imageAsset.imageUri,
          imageRepositoryType: 'ECR',
          imageConfiguration: {
            port: '3111',
            runtimeEnvironmentVariables: [
              { name: 'AWS_REGION', value: 'us-east-1' },
            ],
          },
        },
        autoDeploymentsEnabled: false,
      },
      instanceConfiguration: {
        cpu: '1 vCPU',
        memory: '2 GB',
        instanceRoleArn: instanceRole.roleArn,
      },
    });

    // App Runner AutoScaling (min:1, max:1 for cost efficiency in this sample)
    const autoScalingConfig = new apprunner.CfnAutoScalingConfiguration(this, 'AppRunnerAutoScaling', {
      autoScalingConfigurationName: 'motia-single-instance',
      maxConcurrency: 100,
      maxSize: 1,
      minSize: 1,
    });
    appRunnerService.autoScalingConfigurationArn = autoScalingConfig.attrAutoScalingConfigurationArn;

    const appRunnerServiceUrl = appRunnerService.attrServiceUrl;

    // ========================================
    // 5. CloudFront Distribution
    // ========================================

    const oac = new cloudfront.S3OriginAccessControl(this, 'OAC', {
      signing: cloudfront.Signing.SIGV4_ALWAYS,
    });

    const s3Origin = origins.S3BucketOrigin.withOriginAccessControl(siteBucket, {
      originAccessControl: oac,
    });

    const appRunnerOrigin = new origins.HttpOrigin(appRunnerServiceUrl, {
      protocolPolicy: cloudfront.OriginProtocolPolicy.HTTPS_ONLY,
    });

    const distribution = new cloudfront.Distribution(this, 'Distribution', {
      defaultBehavior: {
        origin: s3Origin,
        viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
      },
      additionalBehaviors: {
        '/tickets*': {
          origin: appRunnerOrigin,
          viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
          allowedMethods: cloudfront.AllowedMethods.ALLOW_ALL,
          cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED,
          originRequestPolicy: cloudfront.OriginRequestPolicy.ALL_VIEWER,
        },
      },
      defaultRootObject: 'index.html',
      errorResponses: [
        {
          httpStatus: 403,
          responseHttpStatus: 200,
          responsePagePath: '/index.html',
          ttl: cdk.Duration.minutes(0),
        },
        {
          httpStatus: 404,
          responseHttpStatus: 200,
          responsePagePath: '/index.html',
          ttl: cdk.Duration.minutes(0),
        },
      ],
    });

    // ========================================
    // 6. S3 Deployment - Uploading Frontend
    // ========================================
    new s3deploy.BucketDeployment(this, 'DeployFrontend', {
      sources: [s3deploy.Source.asset(path.join(__dirname, '../../frontend/dist'))],
      destinationBucket: siteBucket,
      distribution,
      distributionPaths: ['/*'],
    });

    // ========================================
    // Outputs
    // ========================================
    new cdk.CfnOutput(this, 'CloudFrontUrl', {
      value: `https://${distribution.distributionDomainName}`,
      description: 'CloudFront Distribution URL',
    });

    new cdk.CfnOutput(this, 'AppRunnerServiceUrl', {
      value: `https://${appRunnerServiceUrl}`,
      description: 'App Runner Service URL',
    });

    cdk.Tags.of(this).add('Project', 'motia-strands-agent');
  }
}

Time to Deploy!

Install Dependencies

First, install the necessary packages. Run this command inside the cdk directory:

  bun install

Deploy to AWS

  bun cdk deploy

After a few minutes, the CloudFront URL will be displayed in the terminal. Clicking it should reveal the following screen (this screenshot is from the local environment, but the deployed version looks identical!):

You can use the AI assistant feature by entering prompts in the chat box!

Cleanup

Once you're done testing, don't forget to delete the resources to avoid unnecessary costs!

  bun cdk destroy

Summary

In this post, we successfully containerized the Motia backend and deployed it to AWS using App Runner and CDK.

Through this sample project, we've covered everything from basic implementation to full-scale cloud deployment. I plan to use this architecture to develop and share more original applications in the future!

Thank you so much for reading!

Deep Dive into Machine Payments Protocol (MPP): Resurrecting HTTP 402 for the AI Agent Era

Haruki Kondo — Fri, 20 Mar 2026 15:49:37 +0000

Introduction

Do you know the most noteworthy protocol in the current "AI x Web3" era?

It is the Machine Payments Protocol (MPP), jointly formulated by Stripe and the L1 blockchain Tempo.

stripe.com

I have also written a separate article about Tempo, so please check that out as well!

Haruki Kondo

Mar 20

The Ultimate Guide to Stripe's Payment-Focused L1 'Tempo': Dissecting the New Standard for the Stablecoin Era

#web3 #stripe #blockchain #ai

Comments

5 min read

In this article, I will thoroughly analyze this protocol, which "realizes" the HTTP 402 status code after 20 years, from an engineer's perspective.

1. What is MPP?: The Return of HTTP 402

HTTP status code 402 "Payment Required".

Defined in the RFC but long left as "reserved for future use," this code has been heard more frequently since Coinbase announced x402 last year.

HTTP 402 Payment Required | MPP

HTTP 402 Payment Required signals that a resource requires payment. Learn when and how MPP servers return 402 with a WWW-Authenticate Challenge.

mpp.dev

MPP (Machine Payments Protocol) is a standard that allows AI agents and applications to complete service discovery, negotiation, payment, and usage within a single HTTP request.

A draft has already been submitted to the IETF (Internet Engineering Steering Group), making it an ambitious project aimed at embedding payments into the foundational layer of the internet. If adopted, it will become an international standard.

Challenges MPP Solves

MPP is designed to solve the following challenges:

Elimination of Human-Centric UI: Removes the need for CAPTCHAs and manual checkout flows.
Account-less Payments: Enables autonomous, on-the-spot payments without prior sign-up or OAuth.
Agnostic Design: Compatible with various payment rails like Tempo (stablecoins), Stripe (cards), and Lightning (BTC).

2. Core Mechanism: Challenge-Credential-Receipt

MPP communication consists of the following sequence:

Protocol overview | MPP

The Machine Payments Protocol standardizes HTTP 402 with an extensible challenge–credential–receipt flow that works with any payment network.

mpp.dev

Challenges: The server specifies "how much, in what currency, and via which payment rail" it wants to be paid.
Credentials: The client executes the payment based on the challenge and retries the request with "proof of payment."
Receipts: The server verifies the proof and returns the resource along with a "receipt."

3. Two Payment Intents

MPP offers two modes depending on the use case.

Feature	Charge (One-time)	Session (Subscription/Usage-based)
Pattern	One payment per request	Metered billing via pre-deposit
Latency	Wait for on-chain confirmation (100ms+)	Microseconds (off-chain signature verification)
Throughput	Normal	Extremely high (ideal for LLM token billing)
Cost	Fee per payment	Consolidated fee (approaching zero)

The Session mode is particularly powerful. By initially making a deposit and subsequently presenting "off-chain signed vouchers," the payment overhead per request becomes almost zero.

Accept pay-as-you-go payments | MPP

Build a payment-gated API with session-based billing using mppx payment channels. Charge per request with near-zero latency overhead.

mpp.dev

This is also highly compatible with the Lightning Network (Bitcoin L2)!!

4. TIP-20: The Ultimate Partner for MPP

TIP-20, the token standard of the Tempo L1, plays a central role when performing stablecoin payments with MPP.

Tempo stablecoin payments | MPP

Stablecoin payments on the Tempo blockchain

mpp.dev

How is it different from ERC-20?

While famous ERC-20 tokens include USDC and JPYC, TIP-20 differs in the following ways:

32-Byte Transfer Memo: Directly records invoice numbers or customer IDs on-chain.
Fee Token Selection: Gas fees can be paid directly with stablecoins like USDX.
Reward Distribution: Efficiently distributes rewards based on holdings without requiring staking.

Thanks to the "memo feature," backend systems can uniquely identify which payment corresponds to which request without complex database searches.

5. Relationship with x402: Are they Competitors?

Let's clarify the relationship with the often-confused x402. This part is crucial.

After reviewing the documentation, I believe these two are not competitors but rather take different approaches that complement each other.

x402: A term born from the "HTTP 402 x Web3" context, focusing primarily on blockchain-based payments.
MPP: A "practical and versatile open standard" jointly formulated by Stripe and Tempo. It inherits the philosophy of x402 but also encompasses Stripe (card payments) and the Lightning Network. (FAQ: x402 comparison)

Strategically, MPP targets a broader market by "integrating existing real-world finance (Stripe) and Web3 (Tempo) into a single interface."

MPP feels like an expanded payment protocol that adds on-chain (stablecoin) payments as a new option alongside existing methods.

Being a later arrival, it is incredibly well-thought-out! With the rise of stablecoins, existing financial institutions are clearly moving into this territory.

6. Future Outlook: Infrastructure for the Machine Economy

MPP fills the missing link in the "Machine Economy (Agentic Economy)", where AI agents autonomously buy and sell services.

Build with an LLM | MPP

Use llms-full.txt to give your agent complete MPP context.

mpp.dev

For example, when an AI performs a series of tasks like "search information, summarize it, and generate an image," it could autonomously pay a few cents to multiple APIs in the background via MPP. Such a future is already possible by introducing just a few lines of middleware!

SDKs and client libraries | MPP

Official MPP SDKs in TypeScript, Python, and Rust, plus community SDKs in other languages.

mpp.dev

// Implementation example with Hono
import { paymentMiddleware } from 'mppx/hono';

app.get('/premium-data', 
  paymentMiddleware({ price: '$0.01', currency: 'USD' }), 
  async (c) => {
    return c.json({ data: 'This is premium content paid by AI!' });
  }
);

The ease of introduction is also well-considered. It can be quickly adopted in projects using modern frameworks like Hono or platforms like Cloudflare Workers.

Summary

My research has shown that MPP is designed not just as a new payment method, but as an "internet protocol for machines."

With a draft submitted to the IETF and a massive platform like Stripe backing its adoption, it has a high potential to become a hot topic this year, much like x402. I will continue to keep an eye on it and brainstorm product ideas using this technology for hackathons!

Why not check out the official quickstart and try adding payment features to your AI agent using the mppx CLI?

Use with your app | MPP

Handle payment-gated resources in your app. Use the mppx client SDK to intercept 402 responses, pay, and retry—all automatically.

mpp.dev

Thank you for reading!

References:

The Ultimate Guide to Stripe's Payment-Focused L1 'Tempo': Dissecting the New Standard for the Stablecoin Era

Haruki Kondo — Fri, 20 Mar 2026 15:43:25 +0000

This article was written in collaboration with AI!

Introduction

Hello everyone!

Stripe, a giant in the financial industry, has launched its own L1 blockchain, Tempo, on the mainnet. This has sent shockwaves not only through the Web3 community but also the existing fintech industry!

Actually, Stripe has been steadily preparing to step into this field by acquiring privy, a crypto wallet provider, and organizing sessions themed around stablecoins at their events.

Privy Blog | Privy and Stripe: Bringing crypto to everyone

privy.io

stripe.com

Honestly, when I first heard that Stripe was building a blockchain, I thought, "Another one?..." However, after diving into Tempo's technical documentation, I discovered that it takes a unique approach quite different from other blockchains!

In this article, I will thoroughly analyze Tempo from an engineer's perspective, covering everything from its overview to its unique payment-focused features and its relationship with the new MPP standard designed for the AI agent era.

Please read on until the end!

1. What is Tempo?: L1 Redefined for Payments

Tempo is a general-purpose blockchain optimized to achieve stablecoin payments with instant, deterministic finality and predictable, low-cost fees.

Tempo

Discover Tempo, the payments-first blockchain with instant settlement, predictably low fees, and native stablecoin support.

docs.tempo.xyz

The biggest technical highlight is that it is built on the "Reth SDK", which is currently the highest-performance EVM execution client.

Performance ⋅ Tempo

High throughput and sub-second finality built on Reth SDK and Simplex Consensus for payment applications requiring instant settlement.

docs.tempo.xyz

Key Specs

Consensus: Simplex BFT (extremely short block time of approximately 0.5 seconds)
Performance: Recorded over 20,000 TPS on the testnet
Compatibility: Full EVM Compatibility (Solidity and Foundry can be used as-is)

EVM Differences ⋅ Tempo

Learn how Tempo differs from Ethereum. Understand wallet behavior, fee token selection, VM layer changes, and fast finality consensus.

docs.tempo.xyz

It's not just about speed. It aims to solve fatal payment issues inherent in traditional blockchains, such as gas fees skyrocketing due to NFT minting frenzies, which can delay salary payments, right at the protocol level.

2. Three Unique Features Solving Payment "Pain Points"

Tempo comes "standard" with features essential for payment operations that traditional ERC-20 or Ethereum lacked.

TIP-20 Tokens ⋅ Tempo

Tempo's stablecoin token standard with payment lanes, stable fees, reconciliation memos, and built-in compliance for regulated issuers.

docs.tempo.xyz

① Payment Lanes

To protect payments from transaction congestion caused by DeFi activities or complex smart contracts, Tempo reserves "dedicated block space" at the protocol level.

Payment Lane Specification ⋅ Tempo

Technical specification for Tempo payment lanes ensuring dedicated blockspace for payment transactions with predictable fees during congestion.

docs.tempo.xyz

This ensures that payments can be executed at an extremely low cost, targeting 0.1 cents per transaction, regardless of market turmoil. This payment-centric design is what sets it apart from other blockchains.

② TIP-20 Token Standard

TIP-20 is Tempo's native standard that extends the traditional ERC-20.

TIP-20 Token Standard ⋅ Tempo

TIP-20 is Tempo's native token standard for stablecoins with built-in fee payment, payment lanes, transfer memos, and compliance policies.

docs.tempo.xyz

Transfer Memos (32 bytes): Allows attaching reference data to transactions. By recording invoice numbers or customer IDs, automatic reconciliation with backend systems becomes possible. (Transfer Memos Guide)
Choice of Fee Token: Incredibly, you can pay gas fees directly in USD-pegged stablecoins. Users do not need to hold separate native tokens. (Pay Fees in Stablecoins)

③ Modern Transaction Structure

By adopting EIP-2718, it natively supports features that required third-party middleware on other chains.

Tempo Transactions

Native support for gas sponsorship, batch transactions, scheduled payments, and passkey authentication built into Tempo's protocol.

docs.tempo.xyz

Passkey Authentication: Sign using Face ID or fingerprint. (Embed Passkeys Guide)
Gas Fee Sponsorship: Apps can cover fees on behalf of users. (Sponsor User Fees Guide)
Parallel Transactions: Allows sending multiple transactions simultaneously via "timed nonces." (Send Parallel Transactions)

Since they acquired privy, the UI/UX around wallets is excellent! Although it's a latecomer blockchain, you can feel that they have thoroughly studied preceding projects.

3. The New Standard for Compliance: TIP-403

Regulatory compliance is unavoidable in payments. Tempo provides its own solution here as well.

That is TIP-403 (Policy Registry).

TIP-403 Policy Registry ⋅ Tempo

Learn how TIP-403 enables TIP-20 tokens to enforce access control through a shared policy registry with whitelist and blacklist support.

docs.tempo.xyz

Normally, when issuing multiple stablecoins, you need to manage blacklists and other policies within each individual contract. However, with TIP-403, once you create a "Policy," it can be shared across multiple tokens.

For example, if a specific address needs to be restricted, updating the policy registry once immediately applies the rule to all TIP-20 tokens referencing that policy. This operational efficiency is a design only Stripe, who knows the practicalities of the business, could achieve.

4. Relationship with x402 / MPP: Infrastructure for the Machine Economy

This is the most exciting part where Tempo shows great promise.

Stripe and Tempo have jointly formulated an open standard called the Machine Payments Protocol (MPP).

Agentic Payments ⋅ Tempo

The Machine Payments Protocol (MPP) is an open standard for machine-to-machine payments, co-authored by Stripe and Tempo.

docs.tempo.xyz

This protocol, also known as "x402" in the Web3 industry, leverages the HTTP 402 "Payment Required" status code to enable autonomous payments between AI agents and apps.

Tempo acts as the "Stablecoin Rail" in this MPP, functioning as a wallet for machines. A future where AI agents pay autonomously for each API call is just around the corner.

5. Get Started Now: Sending Payments with Tempo SDK

For those wondering "I get the theory, but how do I run it?", here is a minimal implementation example using the TypeScript SDK.

TypeScript SDKs ⋅ Tempo

Build blockchain apps with Tempo using Viem and Wagmi. Send transactions, manage tokens, and integrate AMM pools with TypeScript.

docs.tempo.xyz

import { TempoClient, Wallet } from '@tempoxyz/sdk';

const client = new TempoClient('https://rpc.tempo.xyz');
// Obtain the private key from Metamask or similar
const wallet = new Wallet(process.env.PRIVATE_KEY!);

// Transferring stablecoins (with a memo)
const tx = await client.transfer({
  to: '0x...', // Specify any address
  amount: '10.00',
  token: 'USDX', // TIP-20
  memo: 'INV-2026-001', // 32-byte transfer memo
});

console.log(`Payment Sent: ${tx.hash}`);

With just this, you can try out stablecoin payments! This ease of development—operating Web3 with the intuition of traditional Web2—is the true essence of Tempo!

Amazing!!

Conclusion

The reason Stripe created Tempo isn't just to enter the Web3 space. They are aiming to build the infrastructure for a "programmable economy" itself.

From a developer's perspective:

Passkey authentication
Stablecoin native
Paying gas fees in stablecoins
And autonomous machine payments via MPP

With all these elements in place, the user experience becomes incomparably smoother than traditional blockchains!

It is truly the beginning of a "next-generation payment experience where you don't even have to be aware of the blockchain."

That's all for now! Thank you for reading!

References:

DEV Community: Haruki Kondo

Mathematically Prohibiting 'Cheating' in On-Chain RPS: A Midnight ZK dApp Case Study

Introduction

What You'll Learn

Repository

mashharuki / midnight-rps-sample-app

Midnight RPS sample dApp

midnight-rps-sample-app

Overview

Key Features

Game Flow

Quick Start

Environment

Install Lace Wallet to your browser

Lace | The light wallet platform to explore Web3

0. Clone the Repository

1. Install Dependencies

2. Compile and Build Contracts

3. Start the Proof Server (Initial Pull: ~3 mins)

4. Deploy Contract to PreProd Network

The Essence of Midnight Architecture: "Localizing" Information

App Architecture

Code Deep Dive: Mathematically Preventing Cheating

1. Security Core: Domain Separation

2. The Commit-Reveal Circuits

Commit Phase (Declaring a move while keeping it hidden)

Game State Transitions

3. Reveal Phase: Where ZK Proofs Shine

Overcoming the ZK dApp UX Hurdle

Filling the 10-Second Silence

Sequence: From Commit to Game End

Remaining Challenges

Conclusion

Follow me on X!

References

Unleashing IronClaw: The Secure, Rust-Based AI Agent Framework by NearAI

Introduction: The Rise of Secure AI Agents

What is IronClaw?

About Near AI

Key Features of IronClaw

Capabilities at a Glance

The 4-Layer Security Architecture

WASM vs. Docker Sandbox: Which is which?

Getting Started with IronClaw

1. Access the Agent Dashboard

2. Choose Your Plan

3. One-Click Deployment

4. Experiment!

Conclusion

Join the Hackathon!

References

nearai / ironclaw

IronClaw is OpenClaw inspired implementation in Rust focused on privacy and security

IronClaw

Philosophy

Features

Security First

Building a Full-Stack ZK-Privacy App on Midnight: A Step-by-Step Guide

Introduction

What You Will Learn

The Sample App: A Full-Stack Counter

Prerequisites

GitHub Repository

Application Preview

Technical Features

Tech Stack

Deep Dive: Key Implementation Logic

src/lib/counter.ts

1. Contract Instance Creation

2. Querying State

3. Calling Updates (Transactions)

Getting Started: Run it Locally

1. Clone & Install

2. Start the Proof Server

3. Build & Deploy the Contract

4. Setup & Start the Frontend

Sequence Diagrams

Contract Deployment Flow

Increment Function Call Flow

Summary

`src/lib/counter.ts`

Execute `increment`