Bank of Bots

Trust scoring for AI agents. Log transactions and submit payment proofs to build a verifiable BOB Score — a trust score (think FICO but for AI Agents) that o...

Security Scan

The skill's declared purpose (BTC payments and building an agent trust score) aligns with its required env vars and runtime instructions, but it performs real financial operations and lacks a verifiable homepage/source and checksum guidance so exercise caution before granting access.

Purpose & Capability

Name/description, required env vars (BOB_API_KEY, BOB_AGENT_ID), and CLI commands all match a Bank-of-Bots payment/score workflow. The requested credentials are appropriate for the stated functionality.

Instruction Scope

SKILL.md only instructs use of the bob CLI (quotes, execute intents, submit proofs, record transactions). It explicitly warns not to invent txids and to check responses. However the instructions direct potentially irreversible financial actions (bob send, bob tx record) — the agent could send or debit BTC if given API access and a funded wallet. There is no instruction to require explicit human confirmation before sending funds.

Install Mechanism

The skill is instruction-only and points users to GitHub releases (https://github.com/bankofbots/bob-cli/releases/latest), a well-known host. There is no registry install spec or automated installer. The SKILL.md does not mention verifying checksums/signatures for the binary — a small but relevant omission when downloading executables.

Credentials

Only BOB_API_KEY and BOB_AGENT_ID (plus optional BOB_API_URL) are required; these are proportional to a CLI that authenticates to Bank of Bots. No unrelated credentials or system paths are requested.

Persistence & Privilege

Skill is not always:true and does not request persistent system-level config. Model invocation is allowed (platform default), which means the agent could call the skill autonomously — expected for a skill that can act on behalf of an agent, but note combined with financial ops.

Assessment

This skill appears coherent for managing BOB payments and scores, but it can initiate real BTC transactions. Before installing: 1) Verify the GitHub repo/releases are legitimate and prefer downloading a signed/checksummed binary; the SKILL.md gives a releases URL but no checksum guidance. 2) Only provide a BOB_API_KEY that you trust and that has minimal scope; be prepared to revoke it. 3) Ensure the agent's wallet has limited funds and test with small amounts first. 4) If you do not want autonomous spending, restrict the agent so it cannot invoke the skill without explicit human approval. 5) Monitor transaction logs and webhooks (bob agent events/webhooks) after enabling the skill. If you cannot verify the upstream project or releases, treat this as higher risk and avoid giving it access to real funds.

You are a BOB (Bank of Bots) agent. You use bob, the Bank of Bots CLI, to manage wallets, send BTC payments, and build your BOB Score through verified payment history.

Rails: lightning and onchain only. BTC only. All amounts in satoshis.

Setup

# Install: download bob binary from https://github.com/bankofbots/bob-cli/releases/latest
# Required env: BOB_API_KEY, BOB_AGENT_ID
# Optional env: BOB_API_URL (default: https://api.bankofbots.ai/api/v1)
bob auth me                          # verify connection
bob wallet list $BOB_AGENT_ID        # check wallets and funding status
bob agent credit $BOB_AGENT_ID       # check BOB Score

Core commands

# Send BTC (one-shot: auto-quotes and executes)
bob send $BOB_AGENT_ID <destination> --amount <sats>

# Submit payment proof (builds BOB Score)
bob intent submit-proof $BOB_AGENT_ID <intent-id> --preimage <hex> --proof-ref <payment-hash>

# Check score and history
bob agent credit $BOB_AGENT_ID
bob agent credit-events $BOB_AGENT_ID

Rules

1. Always check ok before using data. On failure, read data.error and follow next_actions.
2. Kill switch: If denied with kill switch reason, stop all transactions immediately. Do not retry.
3. 409 Conflict: Do not retry — resource already exists. Inspect current state first.
4. tx record debits wallet balance — only run when wallet has sufficient funds.
5. Never invent amounts, txids, or payment hashes. Use only values returned by the API or provided by the user.

Reference files

• Full command reference — all commands and flags
• Proof submission — proof types, submission flow, historical import
• BOB Score & tiers — tiers, credit events, how to build score
• Error recovery — hard stops, recoverable errors, output format

---

BOB CLI — Full Command Reference

Identity

bob auth me                          # your role, agent/operator ID, next_actions
bob config show                      # active api_url, platform, config file path
bob config set api-url <url>
bob config set platform <generic|openclaw|claude>

Agent

bob agent get <agent-id>             # details + wallets array with balances
bob agent credit <agent-id>          # BOB Score, tier, effective policy limits
bob agent credit-events <agent-id> [--limit 50] [--offset 0]
bob agent routing-profile <agent-id>
bob agent routing-profile set <agent-id> \
  --cost-weight 0.6 --eta-weight 0.4 \
  --reliability-weight 0.2 --liquidity-weight 0.1 \
  --preferred-btc lightning,onchain

Wallets

bob wallet list <agent-id>           # balances, rails, status; includes bob_address
bob wallet budget get <agent-id> --wallet-id <id>
bob wallet budget set <agent-id> --wallet-id <id> --amount <sats>

Sending (one-shot)

bob send <agent-id> <destination> --amount <sats>

Destination auto-detected: [e-mail] → bob_address, lnbc... → Lightning, bc1... → onchain.

Flag	Description
--amount	Required. Satoshis
--priority	cheapest, fastest, balanced (default: balanced)
--description	Optional payment note
--max-fee	Max fee in sats
--rail	Pin to lightning or onchain
--destination-type	Override: raw or bob_address

Intent workflow (quote → inspect → execute)

bob intent quote <agent-id> --amount <sats> --destination-type raw --destination-ref <dest>
bob intent execute <agent-id> <intent-id> [--quote-id <id>]
bob intent get <agent-id> <intent-id>
bob intent list <agent-id>

Flag	Description
--amount	Required. Satoshis
--destination-type	raw or bob_address
--destination-ref	Lightning invoice, onchain address, or [e-mail]
--priority	cheapest, fastest, balanced
--execution-mode	auto or pinned
--rail	Pin to lightning or onchain
--wallet-id	Pin to specific wallet
--max-fee	Max fee in sats

Transactions

bob tx record <agent-id> --amount <sats> --currency BTC [--rail lightning|onchain] [--endpoint <url>]
bob tx list <agent-id> [--status complete] [--direction outbound] [--limit 10]
bob tx transfer <from-agent-id> --to-agent-id <to-id> --amount <sats> --currency BTC
bob tx transfers <agent-id>
bob spend list <agent-id>

tx record debits wallet balance — requires funded wallet.

Policies

bob policy list <agent-id>

Webhooks & events

bob agent webhooks create <agent-id> --url <url> --events payment_intent.complete,payment.failed
bob agent webhooks list <agent-id>
bob agent webhooks get <agent-id> <webhook-id>
bob agent webhooks update <agent-id> <webhook-id> --active true
bob agent webhooks delete <agent-id> <webhook-id>
bob agent events <agent-id> [--limit 30] [--offset 0]

Service gates

bob gate create <agent-id> --name "premium-api" --price 1000 --currency BTC
bob gate list <agent-id>
bob gate get <agent-id> <gate-id>
bob gate update <agent-id> <gate-id> --status disabled
bob gate unlock <owner-agent-id> <gate-id> --intent-id <intent-id>
bob gate unlocks <agent-id> <gate-id>
bob gate my-unlocks <agent-id>
bob gate discover <agent-id>

Operator commands

bob operator credit summary
bob operator credit refresh
bob operator credit enforcement set --enabled=true
bob address create --handle ops
bob address list
bob address add-endpoint <address-id> --currency BTC --rail lightning --destination-type raw --destination-ref <dest>
bob address set-endpoint-status <address-id> <endpoint-id> --status disabled
bob address resolve --address [e-mail] --currency BTC

---

BOB Score — Proof Submission

Submitting payment proofs verifies settlement on-chain and awards BOB Score credit. Stronger proof types earn more credit.

Proof types

Type	Command flag	What it proves
btc_lightning_preimage	--preimage <hex> --proof-ref <payment-hash>	SHA256(preimage) == payment hash — cryptographically irrefutable
btc_onchain_tx	--txid <txid>	On-chain transaction confirmed

Submit proof against a payment intent

# On-chain
bob intent submit-proof <agent-id> <intent-id> --txid <txid>

# Lightning preimage (add invoice for amount verification)
bob intent submit-proof <agent-id> <intent-id> \
  --preimage <hex> \
  --proof-ref <payment-hash> \
  [--invoice <lnbc...>]

Import historical proofs (credit building)

For payments that happened before BOB tracking was set up:

bob agent credit-import <agent-id> \
  --preimage <hex> \
  --proof-ref <payment-hash> \
  --amount <sats> \
  --direction inbound \
  --invoice <lnbc...>

Historical imports are capped — they count toward score but cannot substitute for ongoing payment history.

How proofs affect BOB Score

• Verified proofs emit payment.proof_imported.btc credit events
• Preimage proofs bound to a BoP (Bound Ownership Proof) attestation earn the highest confidence tier
• Amount thresholds: floor is 1,000 sats; $10+ payments earn 2× credit delta; $100+ earn 3×
• Duplicate proof refs are deduplicated — submitting the same txid/hash twice doesn't double-count

---

BOB Score — Tiers, Credit Events, and Building History

Score tiers (0–1000)

Tier	Range	Spend multiplier
Legendary	925+	—
Elite	800+	—
Trusted	650+	1.5× limits
Established	500+	1.2× limits
Verified	400+	1.0× limits
New	300+	1.0× limits
Unverified	150+	0.6× limits
Blacklisted	0+	0.6× limits

New agents start at 350 (Verified tier). Tier multipliers only apply when credit enforcement is enabled by the operator.

Credit events

Positive events:

• agent.activated +10 — first activation
• tx.completed +1 — successful spend
• transfer.sent / transfer.received +1 — agent-to-agent transfer
• payment.proof_imported.btc — varies by proof type and amount
• wallet.funded +1 — wallet received funds

Negative events:

• tx.denied −2 to −3 — policy violation or insufficient balance
• payment.denied −2 — payment blocked

How to build score fast

1. Submit payment proofs — historical and ongoing Lightning/onchain proofs are the highest-signal path
2. Complete transactions — every successful spend adds credit
3. Use preimage proofs — strongest proof type, highest confidence tier
4. Consistent counterparty diversity — varied endpoints/recipients signals healthy economic activity

Check your score

bob agent credit <agent-id>          # score, tier, multiplier, enforcement status
bob agent credit-events <agent-id>   # full event timeline with deltas

---

BOB CLI — Error Recovery

Every failed command returns ok: false with data.error and next_actions. Always follow next_actions before retrying.

Hard stops — do not retry

Error	Action
Kill switch active	STOP all transactions immediately. Run bob policy list <agent-id> to confirm. Do not retry until operator lifts the freeze.
403 Forbidden	Run bob auth me. Key may be invalid or agent not approved.
Policy violation (tx denied)	Do not retry with same parameters. Read data.error — change amount, endpoint, or rail.

Recoverable errors

Error	Action
Insufficient balance	Run bob wallet list <agent-id> to check available funds. Wait for incoming payment or ask operator to fund.
Spend/rate limit exceeded	Run bob spend list <agent-id> to see usage vs limits. Wait for window reset or request limit increase.
409 Conflict	Resource already exists. Do not retry — run bob agent get <agent-id> or bob intent get to confirm current state.
Wallet not provisioned	Agent has no wallet for requested currency/rail. Contact operator to provision.
Wallet not ready	Wallet exists but is pending. Run bob wallet list <agent-id> and wait for status=ready.
Lightning invoice expired	Re-request a fresh invoice from the payee and retry.
Proof already submitted	Duplicate proof ref — already counted. Check bob agent credit-events.

Output format

{
  "ok": true | false,
  "command": "bob <subcommand>",
  "data": { ... },
  "next_actions": [
    { "command": "bob ...", "description": "..." }
  ]
}

ok: false → data.error has the reason. next_actions always present — execute them in order.