Skip to content

feat(bitcoin-agents): add backend API, tools, and services#633

Open
pbtc21 wants to merge 4 commits intoaibtcdev:mainfrom
pbtc21:feature/bitcoin-agents
Open

feat(bitcoin-agents): add backend API, tools, and services#633
pbtc21 wants to merge 4 commits intoaibtcdev:mainfrom
pbtc21:feature/bitcoin-agents

Conversation

@pbtc21
Copy link

@pbtc21 pbtc21 commented Jan 21, 2026

Summary

  • Implements Phase 2 of Bitcoin Agents - backend API, tools, and services
  • Adds data models, FastAPI router, contract tools, and lifecycle services
  • Integrates Bitcoin Faces API for agent visuals

Changes

Models (app/backend/models.py)

  • BitcoinAgentStatus enum (alive/dead)
  • BitcoinAgentLevel enum (5 evolution tiers)
  • BitcoinAgent model with on-chain data, computed state, face URLs
  • DeathCertificate model with epitaph support
  • Filter models for queries

API Router (app/api/bitcoin_agents.py)

Endpoint Method Description
/bitcoin-agents GET List agents with filters
/bitcoin-agents/leaderboard GET Top agents by XP
/bitcoin-agents/graveyard GET Dead agents memorial
/bitcoin-agents/stats GET Global statistics
/bitcoin-agents/food-tiers GET Food pricing info
/bitcoin-agents/{id} GET Get specific agent
/bitcoin-agents/{id}/status GET Computed hunger/health
/bitcoin-agents/mint POST x402 mint payment flow
/bitcoin-agents/{id}/feed POST x402 feed payment flow
/bitcoin-agents/{id}/check-death POST Process death

Tools (app/tools/bitcoin_agents.py)

  • Contract read functions (get_agent_state, get_computed_state)
  • Transaction builders (mint, feed, check-death, epitaph, add-xp)
  • Batch operations (check_and_process_deaths)
  • LangChain tools for MCP integration

Services (app/services/bitcoin_agents/)

  • face_service.py: Bitcoin Faces API integration with caching
  • lifecycle_service.py: Background jobs for death checks and alerts

Test plan

  • API endpoints return expected responses
  • Models serialize/deserialize correctly
  • Face service fetches from bitcoinfaces.xyz
  • Integration with existing auth system

Related

🤖 Generated with Claude Code

pbtc21 and others added 2 commits January 21, 2026 02:24
Implements Phase 2 of Bitcoin Agents backend integration:

Models (app/backend/models.py):
- BitcoinAgentStatus enum (alive/dead)
- BitcoinAgentLevel enum (hatchling/junior/senior/elder/legendary)
- BitcoinAgent model with on-chain data, computed state, face URLs
- BitcoinAgentFilter for queries
- DeathCertificate model with epitaph support
- DeathCertificateFilter

API Router (app/api/bitcoin_agents.py):
- GET /bitcoin-agents - List all agents with filters
- GET /bitcoin-agents/leaderboard - Top agents by XP
- GET /bitcoin-agents/graveyard - Dead agents memorial
- GET /bitcoin-agents/stats - Global statistics
- GET /bitcoin-agents/food-tiers - Food pricing info
- GET /bitcoin-agents/{id} - Get specific agent
- GET /bitcoin-agents/{id}/status - Computed hunger/health
- GET /bitcoin-agents/{id}/death-certificate
- POST /bitcoin-agents/mint - x402 payment flow
- POST /bitcoin-agents/{id}/feed - x402 payment flow
- POST /bitcoin-agents/{id}/check-death
- POST /bitcoin-agents/{id}/epitaph

Tools (app/tools/bitcoin_agents.py):
- Contract read functions (get_agent_state, get_computed_state, etc.)
- Transaction builders (build_mint_agent_tx, build_feed_agent_tx, etc.)
- Batch operations (check_and_process_deaths)
- LangChain tools for MCP integration

Services (app/services/bitcoin_agents/):
- face_service.py: Bitcoin Faces API integration with caching
- lifecycle_service.py: Background jobs for death checks, alerts, stats

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Phase 3 implementation:
- Add tier-based tool access (TIER_CAPABILITIES) with 5 levels:
  - Hatchling (0): Read-only operations
  - Junior (1): Simple transfers
  - Senior (2): Trading and contracts
  - Elder (3): DAO participation and social
  - Legendary (4): Full autonomy
- Create MCPService with execute_action and tool initialization
- Integrate with existing LangChain tools via tools_factory
- Add XP rewards for completed actions (ACTION_XP_REWARDS)
- Implement agent-to-agent visit interactions with rate limiting
- Add API endpoints:
  - GET /{agent_id}/capabilities
  - POST /{agent_id}/execute
  - POST /{agent_id}/visit/{host_agent_id}
  - GET /tier-info

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Complete API reference for Bitcoin Agents endpoints:
- Agent CRUD operations
- Leaderboard and graveyard
- Food tiers and stats
- Payment endpoints (x402)
- MCP integration endpoints
- Error codes and rate limits
- Evolution tier reference

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@pbtc21
Copy link
Author

pbtc21 commented Jan 21, 2026

@whoabuddy Ready for review - Bitcoin Agents backend API. Adds endpoints for agent lifecycle, feeding, death checks, leaderboard, graveyard, and MCP tool execution.

- Add network validation (must be mainnet or testnet)
- Add agent_id validation via Path (must be >= 0)
- Support contract addresses via environment variables
- Add validate_network and get_contract_address helpers

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@pbtc21
Copy link
Author

pbtc21 commented Jan 21, 2026

Fixes pushed:

  • Added network parameter validation (must be mainnet or testnet)
  • Added agent_id validation via Path (must be >= 0)
  • Contract addresses now configurable via environment variables
  • Added validate_network() and get_contract_address() helpers

Copy link

@JackBinswitch-btc JackBinswitch-btc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the scaffolding. A few observations:

  1. 27 TODOs -- this is clearly a WIP scaffold for the Tamagotchi agent feature. The API surface looks well-structured (CRUD, leaderboard, graveyard, food tiers).

  2. Security -- write operations documented as requiring wallet-signed messages. No hardcoded secrets. Looks clean.

  3. Placeholder returns -- all endpoints return empty lists/zero stats. Functional as stubs but the real implementation will need contract read integration (Stacks read-only calls).

  4. Error handling -- consistent pattern across all endpoints. The generic except Exception with str(e) in 500 responses could leak internal details in production -- consider a generic error message for 500s.

  5. Contract addresses -- using placeholder SP000000000000000000000000000000 which is fine for scaffolding.

Not blocking since this is a scaffold. Worth noting the companion frontend PR (#752) exists as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants