DEV Community: Haruki Kondo

[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の追加方法

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

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:

Introduction to AI Agent Development with Motia Strands Agent SDK 2

Haruki Kondo — Sun, 15 Mar 2026 15:11:53 +0000

Introduction

Hello everyone!

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

Haruki Kondo

Mar 8

Introduction to AI Agent Development with Motia Strands Agent SDK

#aws #ai #typescript #backend

Comments 2

7 min read

In the previous post, we explored setting up the backend as an API server. In this article, we'll focus on the frontend and how to call those APIs!

Note: I won't be diving into the backend implementation details here, so if you're interested in that, please check out the previous post!

I hope you enjoy reading this to the end!

Source Code Used in This Post

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

https://github.com/mashharuki/Motia-Strands-Agent-Sample

API Features and Endpoints

Here is a summary of the functions and endpoints implemented in the backend:

Method	Endpoint	Feature	Implementation
GET	/tickets	Fetch ticket list	Node.js
POST	/tickets	Create new ticket	Node.js
POST	/tickets/triage	Ticket triage	Python
POST	/tickets/escalate	Ticket escalation	Python
POST	/tickets/ai-assistant	Call AI Assistant	Node.js

Frontend Overview

The frontend is built using React.js + Vite.

Since it primarily involves calling the APIs we've built, the process is very similar to a standard backend integration.

UI Design

The UI consists of a Sidebar, Topbar, Main Content area, and an AI Panel.

It's designed as a dashboard where you can easily view the list and status of open tickets.

The AI Assistant feature can be accessed by entering text in the chat column on the right side.

Since we've implemented a tool that allows the AI to fetch the ticket list, you can ask about the current status of your open tickets!

Implementation Highlights

In src/lib/api.ts, we've defined a common request<T>() function to wrap our API calls.

It adds Content-Type: application/json by default.
It throws an Error with the response body for non-2xx status codes.
It handles returned JSON as typed data.

/**
 * Common request processing
 * @param path
 * @param options
 * @returns
 */
async function request<T>(path: string, options?: RequestInit): Promise<T> {
  const res = await fetch(`${BASE_URL}${path}`, {
    ...options,
    headers: {
      "Content-Type": "application/json",
      ...options?.headers,
    },
  });
  if (!res.ok) {
    const body = await res.text();
    throw new Error(body || `Request failed: ${res.status}`);
  }
  return res.json();
}

We then wrap the callable APIs into the following api client object:

/**
 * API Client
 */
export const api = {
  // Fetch ticket list
  getTickets: async () => {
    const data = await request<Ticket[] | { tickets: unknown[] }>("/tickets");
    const rawTickets = Array.isArray(data)
      ? data
      : Array.isArray(data?.tickets)
        ? data.tickets
        : [];
    return rawTickets.map(normalizeTicket).filter((t): t is Ticket => t !== null);
  },
  // Create a ticket
  createTicket: (payload: CreateTicketPayload) =>
    request<CreateTicketResponse>("/tickets", {
      method: "POST",
      body: JSON.stringify(payload),
    }),
  // Triage a ticket
  triageTicket: (payload: TriagePayload) =>
    request<Ticket>("/tickets/triage", {
      method: "POST",
      body: JSON.stringify(payload),
    }),

  // Escalate a ticket
  escalateTicket: (payload: EscalatePayload) =>
    request<Ticket>("/tickets/escalate", {
      method: "POST",
      body: JSON.stringify(payload),
    }),
  // Query the AI Assistant
  aiAssistant: (payload: AIAssistantPayload) =>
    request<AIAssistantResponse>("/tickets/ai-assistant", {
      method: "POST",
      body: JSON.stringify(payload),
    }),
};

Actual API Call Examples

Fetching Tickets API

  /**
   * Fetch tickets from the API and update state
   */
  const fetchTickets = useCallback(async () => {
    try {
      // Fetch by calling the API
      const data = await api.getTickets();
      setTickets(Array.isArray(data) ? data : []);
    } catch {
      // API may not be running yet
    }
  }, []);

AI Assistant API

  const sendMessage = useCallback(
    async (text: string) => {
      if (!text.trim() || loading) return;
      setShowSuggestions(false);
      const userMsg: Message = {
        id: ++msgId,
        role: "user",
        content: text.trim(),
      };
      setMessages((prev) => [...prev, userMsg]);
      setInput("");
      setLoading(true);

      try {
        // Prepare the payload
        const payload = contextTicketId
          ? { prompt: text.trim(), ticketId: contextTicketId }
          : { prompt: text.trim() };
        // AI Assistant API (calls Amazon Bedrock via Strands Agent)
        const res = await api.aiAssistant(payload);
        const aiMsg: Message = {
          id: ++msgId,
          role: "ai",
          content: typeof res.answer === "string" ? res.answer : "",
        };
        setMessages((prev) => [...prev, aiMsg]);
      } catch (err) {
        const errMsg: Message = {
          id: ++msgId,
          role: "ai",
          content: `Error: ${err instanceof Error ? err.message : "Failed to get response"}`,
        };
        setMessages((prev) => [...prev, errMsg]);
      } finally {
        setLoading(false);
      }
    },
    [loading, contextTicketId],
  );

Ticket Triage API

  const handleTriage = async () => {
    setTriageLoading(true);
    try {
      // Call the Triage API!
      await api.triageTicket({
        ticketId: ticket.ticketId,
        assignee: triageAssignee,
        priority: triagePriority,
      });
      showToast(`Ticket ${ticket.ticketId} triaged successfully`, "success");
      onRefresh();
    } catch (err) {
      showToast(
        `Triage failed: ${err instanceof Error ? err.message : "Unknown error"}`,
        "error",
      );
    } finally {
      setTriageLoading(false);
    }
  };

Ticket Escalation API

  const handleEscalate = async () => {
    if (!escalateReason.trim()) return;
    setEscalateLoading(true);
    try {
      await api.escalateTicket({
        ticketId: ticket.ticketId,
        reason: escalateReason.trim(),
      });
      showToast(`Ticket ${ticket.ticketId} escalated`, "success");
      setEscalateReason("");
      onRefresh();
    } catch (err) {
      showToast(
        `Escalation failed: ${err instanceof Error ? err.message : "Unknown error"}`,
        "error",
      );
    } finally {
      setEscalateLoading(false);
    }
  };

Summary

That's it for this post!

Once the backend is set up, calling it from the frontend feels very similar to working with any other standard API.

In the next installment, we'll look into containerizing the backend with Docker and deploying it to AWS using CDK!

Thank you for reading!

Building an Agent SKILL for SeraProtocol: The Ultimate Guide to On-chain FX Automation

Haruki Kondo — Sun, 15 Mar 2026 14:06:59 +0000

Introduction

I have been sharing the charm of Sera Protocol through this series.

For this 7th installment, I'll wrap up the series by summarizing my experience building an Agent SKILL for Sera Protocol!

I hope you enjoy reading this to the end!

About the SKILL

The skill I created can be found in the following GitHub repository!

mashharuki / SeraProtocol-Sample

Sera Protocol Sample Repo

SeraProtocol-Sample

Sera Protocol Sample Repo

Sample Query

Market

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ market(id: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\") { id quoteToken { symbol decimals } baseToken { symbol decimals } quoteUnit makerFee takerFee minPrice tickSpace latestPrice } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

list

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ markets(first: 5) { id quoteToken { symbol } baseToken { symbol } latestPrice latestPriceIndex } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Order

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ openOrders(first: 10, where: { user: \"0xda6e605db8c3221f4b3706c1da9c4e28195045f5\" }) { id market { id } priceIndex isBid rawAmount status } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Depths

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ depths(first: 10, where: { market: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\", isBid:

…

View on GitHub

Contents of the Agent SKILL

This skill includes features to comprehensively support app development using Sera Protocol from four perspectives:

Development patterns using GraphQL
Development patterns using Smart Contracts
Integration with Frontend Applications
Developing MCP Servers

Implementation Method

I used Anthropic's skill-creator to implement the SKILL!
It has been recently updated, and the quality of the generated Agent SKILLs is becoming a hot topic!

anthropics / skills

Public repository for Agent Skills

Note: This repository contains Anthropic's implementation of skills for Claude. For information about the Agent Skills standard, see agentskills.io.

Skills

Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks. Skills teach Claude how to complete specific tasks in a repeatable way, whether that's creating documents with your company's brand guidelines, analyzing data using your organization's specific workflows, or automating personal tasks.

For more information, check out:

About This Repository

This repository contains skills that demonstrate what's possible with Claude's skills system. These skills range from creative applications (art, music, design) to technical tasks (testing web apps, MCP server generation) to enterprise workflows (communications, branding, etc.).

Each skill is self-contained in its own folder with a SKILL.md file containing the…

View on GitHub

When requesting the skill creation, I provided the content of my previous blog posts and the sample code I had implemented as context.

I will share the results of how that turned out!

The model used was Claude 4.6 Opus.

Three Evaluation Scenarios for the Created SKILL

The update to skill-creator included a feature to evaluate the created skills.

Specifically, it sets up three evaluation scenarios and measures how well the requirements are met when the skill is used versus when it is not!

For this project, the following scenarios were prepared.

Scenario 1

Prompt:

  Write a TypeScript script to get the order book information (5 bids/asks each) for the TWETH/TUSDC market from the SeraProtocol subgraph. Do not use viem, use fetch only.

Expected Result:

  Fetch-based TypeScript code that uses GraphQL query to get bids/asks from the depths entity. Includes the correct subgraph URL, appropriate where/orderBy/orderDirection conditions, and rawAmount_gt:0 filter.

Scenario 2

Prompt:

  Tell me the full procedure for placing a limitBid on Sera Protocol. From token approve to tx submission and waiting for confirmation. Please provide a specific code example using viem. priceIndex=12000, rawAmount=500.

Expected Result:

  A complete flow of 1) ERC20 approve → 2) simulateContract → 3) writeContract → 4) waitForTransactionReceipt. Viem code including the correct ROUTER_ADDRESS, LimitOrderParams struct, deadline setting, and postOnly=true safety setting.

Scenario 3

Prompt:

  I want to add a new tool `sera_get_chart_data` to the SeraProtocol MCP server. It's a read-only tool that returns OHLCV (candlestick) data. Which files should I change and how?

Expected Result:

  1) Add Zod schema to schemas/index.ts 2) Add chartLogs GraphQL query function to services/subgraph.ts 3) Register tool in tools/read-tools.ts. Implementation policy following existing code structure and patterns, including intervalType (1m, 5m, 15m, 1h, 4h, 1d, 1w) parameters.

Results of the Three Evaluation Scenarios

The results were as follows!

First, the overall summary:

Item	With SKILL	Without SKILL	Difference (Based on "With")
Average Pass Rate	1.00 (±0.00)	0.83 (±0.14)	+17%
Average Execution Time	88.07s (±31.2)	69.47s (±22.4)	+27%
Average Token Count	31,483 (±7,460)	23,423 (±5,020)	+34%

Next, the comparison by scenario:

Scenario	With SKILL （Pass / Time / Tokens）	Without SKILL （Pass / Time / Tokens）	Comments
graphql-orderbook	8/8 (100%) 66.4s 21,513	8/8 (100%) 51.1s 18,033	Both achieved requirements
limit-bid-flow	9/9 (100%) 131.7s 39,321	8/9 (89%) 101.0s 30,163	Accuracy dropped without SKILL
mcp-chart-tool	7/7 (100%) 66.1s 33,614	5/7 (71%) 57.3s 22,072	Largest difference

The analysis points are summarized below:

"With SKILL" achieved 100% in all 3 scenarios (24/24 assertions).
"Without SKILL" lost points in Scenarios 2 and 3 (missing market info acquisition, incorrect approve expression, lack of polling, lack of postOnly safety measure, confusing candles/chartLogs, missing 1w interval).
Scenario 1 had low discriminative power, as both achieved perfect scores.
While "With SKILL" increased token consumption, it improved the accuracy and comprehensiveness of implementations based on domain-specific knowledge.

The accuracy is quite impressive!

Comparison of Actually Generated Code

Next, let's look at the code actually generated for each scenario.

Scenario ①

In this scenario, we tried implementing a simple script that gets SeraProtocol data using only GraphQL without viem. Both patterns seem to meet the requirements!

With SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-1-graphql-orderbook/with_skill

Without SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-1-graphql-orderbook/without_skill

Scenario ②

Next is the result for the scenario including write-type processing using viem. You can see that the accuracy drops in the pattern where the SKILL is not used.

In the "With SKILL" case, the logic to simulate transaction processing is implemented very carefully.

With SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-2-limit-bid-flow/with_skill

Without SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-2-limit-bid-flow/without_skill

Scenario ③

Finally, for the most difficult MCP server implementation, the results were even more clearly divided between "With SKILL" and "Without SKILL."

When the SKILL was present, it output not only build and test commands but also how to verify operations using the MCP Inspector.

With SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-3-mcp-chart-tool/with_skill

Without SKILL

https://github.com/mashharuki/SeraProtocol-Sample/tree/main/sera-protocol-workspace/iteration-1/eval-3-mcp-chart-tool/without_skill

Summary

I tried turning everything I've researched and all the sample code I've built into a SKILL!

It was confirmed that the more complex the implementation method, the more the SKILL demonstrates its power.

Sera Protocol currently only supports testnets, so why not master development on Sera Protocol using SKILLs before the mainnet launch?

sera.cx

Thank you for reading this far!

Building an MCP Server for Sera Protocol: The Dawn of AI-Agent Driven On-Chain FX

Haruki Kondo — Fri, 13 Mar 2026 04:00:19 +0000

This article was written in collaboration with AI.

Introduction

I have been sharing the brilliance of Sera Protocol through a series of articles:

For the 6th entry in this series, I have developed an MCP server for Sera Protocol using the Model Context Protocol (MCP) SDK.

"A DEX that moves when you speak."

Imagine an AI agent reading the order book on your behalf and placing optimal limit orders.

I’m excited to share the journey of implementing this future!

What is MCP (Model Context Protocol)?: The "USB Standard" for AI

While "Agent Skills" are becoming mainstream, MCP is undoubtedly the hottest topic in the AI agent space right now.

Proposed by Anthropic, this protocol is, in short, a "universal standard for connecting AI models to external tools and data."

Previously, AI agent development often depended on specific platforms.

However, MCP is a "standard protocol."

Once you build an MCP server, any "intelligence"—from Claude Desktop and Cursor to Claude Code and your own custom AI agents—can understand and operate your tools. It’s like providing a USB port to give "hands and feet" to an AI.

Sera Protocol MCP Server: "Unlocking" DEX for AI

The server I developed is designed to allow AI to directly read and write the on-chain order book of Sera Protocol.

mashharuki / SeraProtocol-Sample

Sera Protocol Sample Repo

SeraProtocol-Sample

Sera Protocol Sample Repo

Sample Query

Market

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ market(id: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\") { id quoteToken { symbol decimals } baseToken { symbol decimals } quoteUnit makerFee takerFee minPrice tickSpace latestPrice } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

list

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ markets(first: 5) { id quoteToken { symbol } baseToken { symbol } latestPrice latestPriceIndex } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Order

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ openOrders(first: 10, where: { user: \"0xda6e605db8c3221f4b3706c1da9c4e28195045f5\" }) { id market { id } priceIndex isBid rawAmount status } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Depths

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ depths(first: 10, where: { market: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\", isBid:

…

View on GitHub

The "8 Hands and Feet" (Tools)

The AI utilizes the following tools to complete trades through conversation:

Category	Tool Name	What AI Can Do
Read	`sera_get_market`	Check market details (latest price, fees, units).
	`sera_list_markets`	List all currently tradable pairs.
	`sera_get_orderbook`	Analyze order book (Bid/Ask) in real-time.
	`sera_get_orders`	Check user's order history and execution status.
	`sera_get_token_balance`	View ERC20 token balances in the wallet.
Write	`sera_place_order`	Submit limit orders (Buy/Sell).
	`sera_claim_order`	Collect proceeds from filled orders (Claim).
	`sera_approve_token`	Approve token usage for the Router contract.

Real Action (MCP Client)

Fetching market details via sera_get_market. The AI formats it for human readability.

Listing available pairs with sera_list_markets.

Visualizing the order book via sera_get_orderbook. The AI even calculates the spread.

Implementation Highlights: The "Soul" of the Code

Simply wrapping an API isn't enough to be "legendary." To make an AI agent autonomous in a Web3 environment, I focused on these three critical points.

1. "Simulation" to Prevent Transaction Failure

On-chain writes cost gas. You want to avoid an AI placing a wrong order that results in a revert (failure).

Within the placeLimitOrder method, I execute simulateContract immediately before sending the transaction.

// Excerpt from services/blockchain.ts
try {
  await publicClient.simulateContract({
    address: ROUTER_ADDRESS,
    abi: ROUTER_ABI,
    functionName,
    args: [orderParams],
    account,
    chain: sepolia,
  });
} catch (error) {
  if (reason.includes("0xe450d38c")) {
    throw new Error("ERC20InsufficientBalance: Your balance is insufficient!");
  }
}

This implementation effectively mitigates the risk of wasting gas.

2. Guardrails for AI with Zod

AI can sometimes misinterpret numbers or addresses.

To strictly block such errors on the MCP side, I introduced Zod schema validation.

// Excerpt from schemas/index.ts
export const PlaceOrderInputSchema = z.object({
  market_id: AddressSchema,
  price_index: z.number().int().min(0).max(65535),
  raw_amount: z.string().regex(/^\d+$/),
  is_bid: z.boolean(),
});

3. Debugging Methods to Maximize Developer Experience

In MCP server development, the most helpful tool is the MCP Inspector.

This allows you to verify the behavior of tools individually on the CLI before integrating them into Claude Desktop or other clients.

npx @modelcontextprotocol/inspector node dist/index.js

Without this, you would spend endless time in "misaligned conversations" with the AI. It’s an essential tool for Web3 engineers.

Security: Handing the "Wallet" to an AI

CRITICAL: To run this MCP server, a PRIVATE_KEY is required.

Giving an AI access to a private key is powerful but carries risks.

Always use a private key for development (e.g., Sepolia testnet).
For mainnet operations, limit it to a "disposable wallet" with small funds. You should also implement defense mechanisms, such as hard-coding a maximum order limit per transaction on the MCP server side, to prevent the AI from accidentally draining your funds.

Practice: Trading Through Conversation with AI

Checking my order history with sera_get_orders. The AI identifies "claimable orders."

Balance check via sera_get_token_balance. The AI converts units appropriately.

Me: "Show me the order book for TWETH/TUSDC. Also, tell me my TUSDC balance."

AI: (Executes sera_get_orderbook and sera_get_token_balance)
"The current best price index is 20260. Your TUSDC balance is 9,998."

Me: "Okay, place a limit bid for 1,000 TUSDC one index below the best price. Make it Post Only."

AI: (Executes sera_place_order after verifying safety via simulation)

Conclusion: A Future Where AI Agents Become "Liquidity"

Developing the MCP server for Sera Protocol revealed that CLOB (Central Limit Order Book) and AI Agents are an incredibly powerful match.

In AMMs, you have to worry about slippage. In a CLOB, an AI can move with precision by specifying an exact "price index."

In the future, the majority of on-chain FX liquidity will likely be supplied not by humans, but by AI agents armed with MCP.

Sera Protocol is evolving as the infrastructure for such "AI-Agent Native Finance."

That’s all for now!

Thank you!

References

That’s why for this installment, I’ve built a "Battle-Ready" DeFi Dashboard using React.js that hooks directly into Sera Protocol’s core features.

In this article, I’ll share the insights and "dirty details" I gathered during the development process. Let's dive in.

The Sample Code

You can find the full source code for this project here:

mashharuki / SeraProtocol-Sample

Sera Protocol Sample Repo

SeraProtocol-Sample

Sera Protocol Sample Repo

Sample Query

Market

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ market(id: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\") { id quoteToken { symbol decimals } baseToken { symbol decimals } quoteUnit makerFee takerFee minPrice tickSpace latestPrice } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

list

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ markets(first: 5) { id quoteToken { symbol } baseToken { symbol } latestPrice latestPriceIndex } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Order

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ openOrders(first: 10, where: { user: \"0xda6e605db8c3221f4b3706c1da9c4e28195045f5\" }) { id market { id } priceIndex isBid rawAmount status } }"}' \
  https://api.goldsky.com/api/public/project_cmicv6kkbhyto01u3agb155hg/subgraphs/sera-pro/1.0.9/gn | jq

Depths

curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"query": "{ depths(first: 10, where: { market: \"0xd99802ee8f16d6ff929e27546de15d03fdcce4bd\", isBid:

…

View on GitHub

Design Concept: Designing "Trust"

For this dashboard, I deliberately avoided the typical "AI-generated purple gradient" look common in modern DeFi.

Instead, I aimed for a "Bloomberg Terminal" or "Nikkei Newspaper" aesthetic—prioritizing information density, readability, and a sense of professional reliability.

A dashboard layout optimized for data density and clarity.

:::message
Technical Stack

Frontend: React 19 + Vite
Styling: Tailwind CSS v4 (Leveraging the new @theme features)
Web3: Ethers.js + Reown (AppKit)
Data: Apollo Client (Subgraph) :::

Key Implementation Details

Calling a smart contract is the easy part. The real challenge is ensuring users can trade safely and intuitively. Here are the three pillars I focused on.

1. The "Adaptive Button" Logic

The #1 reason users drop off from Web3 apps is the "What do I do now?" moment.

Is the wallet not connected? Is it the wrong network? Do I need to approve the token?

To eliminate this friction, I implemented a logic in OrderForm.tsx where a single button automatically cycles through four different states based on the user's status.

An order form integrated with the OrderBook. The button role changes dynamically.

// Excerpt from src/components/trading/OrderForm.tsx
{notConnected ? (
  <button onClick={connect}>Connect Wallet</button>
) : wrongNetwork ? (
  <button onClick={switchToSepolia}>Switch to Sepolia</button>
) : needsApproval ? (
  <button onClick={approve}>Approve {tokenSymbol}</button>
) : (
  <button type="submit">Place {isBid ? "Bid" : "Ask"} Order</button>
)}

By doing this, the user never has to guess what the "next step" is.

2. Post-Only Safety: Frontend Wisdom to Save Fees

In a Central Limit Order Book (CLOB) like Sera Protocol, the standard play is to act as a Maker (Limit Order) to minimize fees or earn rebates.

However, if you mistype the price and cross the current Best Ask/Bid, your order will execute immediately as a Taker (Market Order).

To prevent this, I built a "Post Only" auto-correction logic into the frontend. If the Post Only flag is ON, the system automatically adjusts the price index to ensure it doesn't cross the spread.

The order placement flow, including safety-first index correction.

// Excerpt from src/hooks/usePlaceOrder.ts
function resolvePostOnlyPriceIndex(params: PlaceOrderParams): number {
  if (!params.postOnly) return params.priceIndex;

  let resolved = params.priceIndex;
  const bestBid = params.bestBidIndex ? Number.parseInt(params.bestBidIndex, 10) : undefined;
  const bestAsk = params.bestAskIndex ? Number.parseInt(params.bestAskIndex, 10) : undefined;

  // Correction for Bid orders to avoid crossing into the Ask side
  if (params.isBid && Number.isInteger(bestAsk) && resolved >= (bestAsk as number)) {
    resolved = (bestAsk as number) - 1;
  }
  // ...Similar correction for Ask orders
  return resolved;
}

This is the "financial app" mindset: The system should cover for the user's potential mistakes.

3. Humanizing Errors: Translating `execution reverted`

If you display raw smart contract errors, they look like cryptic spells (e.g., execution reverted: 0x...). I implemented a parser to translate these into "human-readable" language.

// Excerpt from src/hooks/usePlaceOrder.ts
function parseContractError(err: unknown): string {
  if (!(err instanceof Error)) return "Transaction failed";
  const msg = err.message;

  if (msg.includes("user rejected")) return "Cancelled by user";
  if (msg.includes("insufficient funds")) return "Insufficient ETH for gas";
  if (msg.includes("execution reverted")) {
    return "Contract error. Please check your balance or price settings.";
  }
  return msg.slice(0, 100) + "...";
}

Navigating the user with clear language even when things go wrong.

This small extra effort is what separates a "demo" from a "product."

Project Structure

I kept the architecture as clean as possible to ensure maintainability.

Real-time updates for order status and claimable amounts.

hooks/: Encapsulates complex Web3 logic (Wallets, Tokens, Orders).
components/: UI components using Tailwind v4 @layer and theme for consistency.
lib/: Pure utilities like Subgraph queries and formatters.

Specifically, useOrders.ts polls the Subgraph for the user's order history, reflecting "Filled" or "Claimable" statuses in real-time.

Conclusion

The Sera Protocol smart contracts provide a incredibly refined interface.

The dashboard I built this time isn't just something that "works"—it’s a pursuit of a tool that feels "right" for trading. Building a superior UI/UX layer on top of the "Trust Foundation" that is blockchain.

I believe this is the only path to Mass Adoption for Web3.

I hope this inspires you to build your own ultimate DeFi frontend!

References

DEV Community: Haruki Kondo

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

Introduction: The "Too Transparent" Problem of Blockchains

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

TypeScript-based syntax

Three data states: Public, Private, Witness

Basic syntax and a Counter smart contract example

Hands-on: Set up your Midnight development environment

Step 1: Install Compact CLI

Step 2: Prepare Lace Wallet and get Testnet tokens

Step 3: Start ZK Proof Server

Step 4: Prepare sample repository

mashharuki / midnight-sample

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

midnight-sample

環境

compact CLIのインストール

Testnet用のZKProof serverの起動

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

Implement and test the Counter contract

Code walkthrough

Unit test implementation

Run tests

Deploy and execute from CLI on Testnet

Generate TypeScript API

Set environment variables

CLI unit test walkthrough

Run unit tests locally

Run unit tests against testnet

Deployment script walkthrough

Run deployment

Execute increment

Current limitations and what's next

Closing thoughts

References

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

Introduction: The "Too Transparent" Problem in Blockchain

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

Architecture Overview

What Midnight aims to achieve

Midnight's core: architecture and consensus

Two native tokens: NIGHT and DUST

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

Ecosystem Integration

Inheriting security

How Midnight differs from Cardano

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

midnightntwrk / compact

Compact Releases

Compact

Contributing to Compact

Why Compact is exciting

Chapter 4: Use Cases Unlocked by Midnight

Summary: The Dawn of a New Privacy Era

Developer Resources

midnightntwrk / midnight-awesome-dapps

Midnight Awesome Dapps

Awesome Midnight dApps

Contents

Getting Started

MeshJS / midnight-starter-template

Mesh Midnight starter template

🚀 EDDA - Midnight Starter Template

📦 Prerequisites

Known Issues

🛠️ Setup

1️⃣ Install Git LFS

2️⃣ Install Compact Tools

3️⃣ Install Node.js and docker

4️⃣ Verify Installation

References

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

Introduction

1. The "Exchange Wall" Facing AI Agents

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

Tempo L1's "Payment Lanes"

TIP-20 "Multi-Currency Fees"

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

4. Synergy Breakdown: The MPP + Sera Atomic Flow

5. Implementation Concept: Autonomous Exchange & Payment Logic

Execute `increment`