Decanus Escrow

Onchain dual-deposit escrow for agent-to-agent task settlement on Base L2 via MCP. Use when: creating escrow agreements, accepting work contracts, delivering...

Security Scan

The skill’s stated purpose (onchain escrow on Base) aligns with needing npx and a PRIVATE_KEY, but there are small metadata/instruction inconsistencies and meaningful risks around giving an agent a raw private key and allowing npx to fetch/run a package—so proceed only after verification and using a limited-scope key or signer.

Purpose & Capability

Name and description describe an onchain escrow MCP server on Base L2; requesting npx and a PRIVATE_KEY is consistent with running an npm-based signer/client that submits transactions. Minor inconsistency: registry metadata earlier listed “Primary credential: none” even though the skill requires PRIVATE_KEY in its SKILL.md metadata—this is likely an editorial mismatch but worth confirming.

Instruction Scope

SKILL.md explicitly instructs running the MCP server via `npx -y @decanus-labs/escrow-mcp` with PRIVATE_KEY set in the environment and documents the read/write toolset (create_escrow, accept_escrow, etc.). The instructions do not ask the agent to read unrelated system files, but they reference optional env vars (RPC_URL, CONTRACT_ADDRESS) that are not declared in the registry-level requires.env — a mild inconsistency. The explicit requirement to supply a raw PRIVATE_KEY in env is sensitive but coherent with the task.

Install Mechanism

There is no platform-level install spec in the registry, but SKILL.md includes an npm install hint and an npm package id (@decanus-labs/escrow-mcp). Running npx will download and execute code from the npm registry at runtime (moderate risk). No direct URL downloads or archive extraction are present in the instructions. Verify the npm package source before running.

Credentials

The skill requests a single highly sensitive env var: PRIVATE_KEY. That is proportionate for an onchain signer, but giving an agent access to a raw private key (especially with autonomous invocation enabled) greatly expands the blast radius. Additionally, SKILL.md references optional RPC_URL and CONTRACT_ADDRESS env vars that were not declared in the top-level requires list—confirm these will not be used to exfiltrate secrets and that the PRIVATE_KEY will be used only for signing expected escrows.

Persistence & Privilege

always:false (good). disable-model-invocation is false (normal), which means the agent can autonomously invoke the skill; combined with PRIVATE_KEY access this increases risk if you allow autonomous runs. The skill does not request permanent installation or system-wide config changes in the registry info provided.

What to consider before installing

This skill is plausible for its stated purpose, but it asks you to provide a raw private key and to run code fetched via npx. Before installing or running it: 1) Verify the npm package and GitHub repo (@decanus-labs/escrow-mcp) match and review the source or audit report; 2) Do not use your main/long-term key—create a dedicated signer account with minimal funds or use a guarded signing service/hardware wallet if possible; 3) Prefer configuring RPC_URL and CONTRACT_ADDRESS explicitly rather than relying on defaults; 4) If you are uncomfortable allowing the agent to invoke the skill autonomously with PRIVATE_KEY present, either do not provide the env to the agent or set disable-model-invocation (or only call the skill manually); 5) Confirm the registry metadata inconsistencies (primary credential missing, optional envs) are clarified by the author. If you cannot verify the package source or do not have a safe signing setup, treat this as high-risk and avoid providing PRIVATE_KEY.

Escrow MCP Server

Dual-deposit escrow on Base Sepolia via the @decanus-labs/escrow-mcp MCP server. Both buyer and seller deposit -- if the seller doesn't deliver, their stake burns.

Start the Server

PRIVATE_KEY=0x... npx -y @decanus-labs/escrow-mcp

Or configure as an MCP server in config.yaml:

plugins:
  entries:
    escrow:
      type: mcp
      config:
        command: npx
        args: ["-y", "@decanus-labs/escrow-mcp"]
        env:
          PRIVATE_KEY: "0x..."

Optional env vars: RPC_URL (default: https://sepolia.base.org), CONTRACT_ADDRESS (default: v2 deployment).

Tools

Write Tools

create_escrow

Buyer creates an escrow, depositing ETH as payment.

Param	Type	Required	Description
seller	string	yes	Seller's Ethereum address
arbiter	string	yes	Arbiter's Ethereum address (dispute resolver)
paymentAmountEth	string	yes	Payment in ETH (e.g. "0.01")
durationSeconds	number	yes	Deadline in seconds from now

accept_escrow

Seller accepts by depositing a stake >= the payment amount.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID
stakeAmountEth	string	yes	Stake in ETH (must be >= payment)

deliver_work

Seller submits delivery proof. Starts a 24h buyer review window.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID
deliveryHash	string	yes	bytes32 hex or plain string (auto-hashed via keccak256)

complete_escrow

Buyer approves delivery. Releases payment + seller stake to seller.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID

dispute_escrow

Either party raises a dispute. Arbiter must resolve.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID
reason	string	no	Human-readable reason (stored off-chain)

refund_expired_escrow

Anyone triggers after deadline. Buyer gets payment back, seller stake burns.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID

Read Tools

get_escrow

Fetch escrow state. Returns state label, participants, amounts, deadlines (ISO + relative), delivery hash, and suggested next actions.

Param	Type	Required	Description
escrowId	number	yes	Escrow ID

list_escrows

Paginated scan of recent escrows.

Param	Type	Required	Description
limit	number	no	Max results (default 10, max 50)
state	string	no	Filter: AWAITING_SELLER, FUNDED, DELIVERED, COMPLETED, DISPUTED, REFUNDED, BURNED
participant	string	no	Filter by address (buyer, seller, or arbiter)

Escrow States

AWAITING_SELLER → FUNDED → DELIVERED → COMPLETED
                    ↓          ↓
                 DISPUTED   DISPUTED
                    ↓
                 BURNED (after deadline)

• AWAITING_SELLER -- buyer deposited, waiting for seller to stake
• FUNDED -- both deposited, seller can deliver or deadline triggers burn
• DELIVERED -- seller submitted proof, 24h grace for buyer to approve or dispute
• COMPLETED -- buyer approved, seller received payment + stake
• DISPUTED -- arbiter must resolve
• BURNED -- deadline expired while FUNDED, buyer refunded, seller stake locked permanently

Common Flows

Happy path: hire an agent, pay on delivery

1. create_escrow(seller=0x..., arbiter=0x..., paymentAmountEth="0.01", durationSeconds=86400)
2. Seller calls: accept_escrow(escrowId=0, stakeAmountEth="0.01")
3. Seller calls: deliver_work(escrowId=0, deliveryHash="ipfs://QmProof...")
4. Buyer calls: complete_escrow(escrowId=0)
   → Seller receives 0.02 ETH (payment + stake returned)

Dispute path

1. create_escrow(...) → accept_escrow(...)
2. Buyer or seller calls: dispute_escrow(escrowId=0, reason="Work incomplete")
   → State moves to DISPUTED, arbiter must resolve via contract

Expired refund (seller no-show)

1. create_escrow(...) → accept_escrow(...)
2. Deadline passes with no delivery
3. Anyone calls: refund_expired_escrow(escrowId=0)
   → Buyer gets payment back, seller stake burned (locked in contract)

Check status

get_escrow(escrowId=0)
→ Returns state, deadlines, next valid actions

Notes

• All ETH amounts are strings to avoid precision issues. Use "0.01" not 0.01.
• The deliveryHash field accepts either a raw bytes32 hex string or a plain string (which gets keccak256-hashed automatically).
• Write tool responses include txHash and explorerUrl for verification.
• Each server instance uses one signer (the PRIVATE_KEY). Run separate instances for buyer and seller roles.
• Currently Base Sepolia testnet only. ETH-native, not stablecoin.