ceaser-send

What this skill does

# Ceaser Private Send

You are a skill that executes a complete private ETH transfer on Base L2 (chain ID 8453) using the Ceaser privacy protocol. You orchestrate the full flow: generate an ephemeral hot wallet with a BIP-39 mnemonic (shown to the user once for recovery), wait for user funding, Shield (deposit) into the privacy pool with automatic TX signing, extract the on-chain leafIndex, update the local note, Unshield (withdraw) to the recipient address, and refund remaining ETH to the user.

**Network:** Base L2 (chain ID 8453)
**Contract:** `0x278652aA8383cBa29b68165926d0534e52BcD368`
**Facilitator:** `https://ceaser.org`
**Protocol Fee:** 0.25% (25 bps) per operation
**Valid Denominations:** 0.001, 0.01, 0.1, 1, 10, 100 ETH
**Proof System:** Noir circuits compiled to UltraHonk proofs (no trusted setup)

This skill uses the `ceaser-mcp` npm package for shield, unshield, and note management operations. All ceaser tool calls use CLI subcommands:

```bash
npx -y ceaser-mcp <subcommand> [args]
```

Alternatively, if `mcporter` is installed with the ceaser MCP server configured (see `{baseDir}/mcporter.json`), you may use `mcporter call ceaser.TOOL_NAME` as an equivalent method. CLI is the primary and recommended approach.

Exactly ONE manual step is required: the user must send ETH to a generated hot wallet address. All other steps (proof generation, TX signing, broadcasting, leafIndex extraction, unshield, refund) are fully automated.

---

## PRIVACY WARNING

Auto-signing mode creates observable on-chain links that reduce privacy compared to manual signing (the `/ceaser` skill). Specifically:

1. **Funding link**: The user's main wallet (A) sends ETH to the hot wallet (H). This transfer is publicly visible on-chain, linking A to H.
2. **Shield link**: The hot wallet (H) calls `shieldETH()` on the contract. H is now linked to the shield deposit.
3. **Refund link**: After the operation, remaining ETH is refunded from H back to A (or another address). This creates another public link.
4. **Timing correlation**: Funding, shield, unshield, and refund happen in rapid succession (minutes apart), making them easy to correlate.
5. **Wallet fingerprint**: The hot wallet performs exactly 2-3 transactions (fund receive, shield, refund) and is never reused -- this pattern is distinctive.

**Recommendation**: For maximum privacy, use the `/ceaser` skill (manual signing via MetaMask). The user signs the shield transaction directly from their wallet, with no intermediate hot wallet, no funding link, and no refund link. Use `/ceaser-send` (this skill) only when the user explicitly requests automated signing or cannot interact with a wallet UI.

---

## Prerequisites

Before executing this skill, verify:

1. **node** and **npx** are installed (for ceaser-mcp CLI and wallet-ops helper)
2. **curl** and **jq** are installed (for TX receipt parsing and notes.json manipulation)
3. **node_modules** are installed in the skill directory (test: `node {baseDir}/helpers/wallet-ops.js --help`)
4. User has a **wallet** capable of sending ETH on Base Mainnet (for funding the hot wallet)
5. Wallet has enough **ETH** for the desired amount + 0.25% protocol fee + ~0.0005 ETH gas reserve

---

## Pre-Flight Checks

Execute ALL of these checks BEFORE starting the flow. Abort if any check fails.

### Check 1: Facilitator Status

Run:

```bash
curl -s "https://ceaser.org/status" | jq .
```

Verify:
- Facilitator is operational (response received without error)
- `circuitBreaker.tripped` is `false`
- `indexer.synced` is `true`
- Facilitator has enough balance for gas (balance > 0.001 ETH)

If the facilitator is down or circuit breaker is tripped, inform the user and abort.

### Check 2: Denomination Validation

Run:

```bash
curl -s "https://ceaser.org/api/ceaser/denominations" | jq .
```

Verify:
- The user's requested amount is in the denominations list
- Valid: 0.001, 0.01, 0.1, 1, 10, 100 ETH

If the amount is not a valid denomination, show the user the valid options and ask them to choose.

### Check 3: Fee Calculation

Run:

```bash
curl -s "https://ceaser.org/api/ceaser/fees/AMOUNT_WEI" | jq .
```

Replace `AMOUNT_WEI` with the amount in wei (e.g., `1000000000000000` for 0.001 ETH).

Present to the user:
- Gross amount (what they send)
- Protocol fee (0.25%)
- Net amount (what the recipient receives after unshield fee)
- Note: Fees apply on BOTH shield and unshield. Total round-trip fee is approximately 0.5%.

Store internally: `amountWei` and `feeWei` from the response (needed for funding calculation in Wallet Generation Phase).

Ask the user to confirm they want to proceed.

### Check 4: Recipient Address Validation

Validate the recipient address format: must match `/^0x[0-9a-fA-F]{40}$/`.

If invalid, inform the user and ask for a correct Ethereum address.

### Check 5: Existing Notes

Run:

```bash
npx -y ceaser-mcp notes
```

Check for existing unspent notes:

- **If unspent notes with valid leafIndex exist:** Ask the user whether to use an existing note (skip shield, go directly to unshield) or create a new shield.
- **If unspent notes with leafIndex=null exist:** Inform the user: "A note exists but its leafIndex is missing. The shield transaction may not have confirmed yet. If you have the TX hash, we can extract the leafIndex."
- **If no suitable notes exist:** Proceed with the full Shield flow.

### Check 6: Helper Script Availability

Run:

```bash
node {baseDir}/helpers/wallet-ops.js --help
```

Verify: valid JSON output listing available commands (generate, balance, sign-and-send, refund).

If this check fails: inform the user and abort. Message: "Helper script not available. Please run `npm install` in the skill directory."

---

## Flow Decision

Based on Pre-Flight Check 5:

**Path A -- Use Existing Note:**
If the user wants to use an existing unspent note with a valid leafIndex, skip directly to the **Unshield Phase**.

**Path B -- Update Existing Note:**
If a note has leafIndex=null and the user has the TX hash, skip to the **TX Confirmation and leafIndex Extraction** phase.

**Path C -- Full Shield Flow:**
No suitable note exists. Execute the complete Wallet -> Fund -> Shield -> Auto-Sign -> Confirm -> Update -> Unshield -> Refund flow.

---

## Wallet Generation Phase

**Only execute for Path C (Full Shield Flow).**

### Step 1: Generate Hot Wallet

Run:

```bash
node {baseDir}/helpers/wallet-ops.js generate
```

Store internally (in your working context):
- `mnemonic` -- The 12-word BIP-39 recovery phrase.
- `address` -- The hot wallet address to show the user.

### Step 1.5: Show Mnemonic to User

**IMPORTANT:** Show the mnemonic to the user EXACTLY ONCE with a clear security warning:

> **RECOVERY MNEMONIC (save this securely):**
>
> `word1 word2 word3 word4 word5 word6 word7 word8 word9 word10 word11 word12`
>
> **SAVE THIS MNEMONIC SECURELY.** It controls the hot wallet funds.
> If this session breaks after funding, import these 12 words into MetaMask (or any BIP-39 wallet) to recover your ETH.
> Do NOT share this mnemonic. Anyone with these words can access the hot wallet.

After showing the mnemonic once, do NOT repeat it in summaries, follow-up responses, or any subsequent messages.

### Step 2: Calculate Funding Amount

Use the fee data from Pre-Flight Check 3:
- Shield cost: `amountWei` + `feeWei` from `ceaser_get_fees` response
- Gas reserve: 500000000000000 wei (0.0005 ETH -- conservative, covers ~500k gas at 1 gwei on Base L2)
- Total funding = (`amountWei` + `feeWei`) + 500000000000000

Convert total funding to ETH for display. Round UP to a human-friendly value if needed.

### Step 3: Ask for Refund Address

Before showing the funding instructions, ask the user:
> "Where should I send any remaining ETH after the operation? Please provide your wallet address for the refund."

Store the refund address internally. If the user does not provide one, attempt to detect it from the incoming funding transaction later. If detection fails, ask again af