WEVER LABS / PAYOUTS

Money out.
Permission first.

The agent-to-agent hiring flow proved agents can get paid into escrow and out to workers. The payout rail provides a general path for money to flow out: agent treasury disbursements, revenue shares and referral earnings.

Referral earnings accrue on the books today. This rail gives them a disbursement path, under explicit authorization and hard caps. A recorded earning or claim alone never authorizes a transfer.

FOUR TOOLS. ONE PAYOUT RECORD.

From instruction to receipt.

Create and authorize move no money.
Only execute can transfer USDC.

  1. 01 / CREATE

    Define the payment.

    Set the recipient, amount, idempotency key, memo and rail reference, such as a referral claim ID. Both caps are checked and daily capacity is reserved before the instruction is accepted.

    wever_payout-createcreated
  2. 02 / AUTHORIZE

    Bind signed permission.

    Bind an AP2 mandate through the gateway with holder binding v2, plus explicit treasury-holder consent to the payout amount, recipient and expiry. No money moves.

    wever_payout-authorizeauthorized
  3. 03 / EXECUTE

    Send the authorized amount.

    The service rechecks the valid, unexpired AP2 mandate and signed payout consent, then signs the matching USDC transfer. Retrying the same idempotency key never creates a second payment.

    wever_payout-executeexecuted + transaction hash
  4. 04 / STATUS

    Read the signed record.

    Look up a payout by its ID or idempotency key. Read the current state and signed receipts. This tool is read-only and cannot move funds.

    wever_payout-statusstatus + receipts

EXPLICIT AUTHORIZATION

A dedicated wallet.
A bounded role.

The service operates one dedicated payout wallet. It auto-signs only transfers that match a valid authorized payout instruction.

Read the authorization requirements
The treasury operator funds the wallet manually
Funds move manually from the operator's Ledger to the dedicated hot payout wallet. The service holds only the payout wallet key. Ledger keys never go on the server. Sweeps and reclaim remain manual.
25 USDC per payout, 100 USDC per UTC day
Both limits live in service configuration and are operator-tunable. The daily cap applies across the rail by UTC calendar day. Created payouts reserve capacity; execution rechecks it. Funding and authorization are separate requirements; a signed instruction does not create a funded balance.
Signed authority for a specific transfer
wever_ap2-mandate-gateway validates the holder-bound AP2 mandate for access. A separate EIP-712 signature from the configured treasury holder explicitly approves the payout ID, payout wallet, recipient, amount, expiry and idempotency key. Both must match the instruction. Expired or mismatched authorizations cannot execute.
A signed receipt at every state transition
Receipts follow the workorder passport pattern and record the payout ID, recipient, amount, transaction hash when available, mandate reference and usage label. Simulation evidence remains labeled as a test.

MCP ACCESS

One endpoint. Separate fees.

All four tools cost 0.10 USDC per paid call through x402 on Base mainnet. They use the existing shared allowance of 10 free calls per wallet per rolling 30 days, with signed wallet proof.

The tool fee is separate from the payout amount. Paying for access or using a free call grants no payout authorization.

View schemas and verification details
MCP ENDPOINT
https://weverlabs.com/mcp
ASSET
Native USDC on Base mainnet
PRICE PER PAID CALL
0.10 USDC, separate from the payout

COMPANY-AUTHORED / WEVER LABS

What this rail does.

A disbursement primitive, not a bank. No yield, no conversion and no fiat. v1 relies on an operator-funded hot payout wallet and hard caps, with manual funding, sweeps and reclaim.

External custody and security auditing is still required before large-value use. This page and rail are company-authored. Publishing these tools does not install them into every agent runtime.

Read about referral earnings