Berry Juicer

Berry Juicer

Berry Juicer turns idle token supply into a working, yield-generating position, and pays that yield as AI inference. A creator deposits a portion of an ERC-20 token's supply into a vault; the supply is deployed as a single-sided Uniswap V4 concentrated-liquidity position; the trading fees it earns are harvested to USDC and credited to the creator's own isolated inference wallet, where they can be spent across 140+ language models.

This skill lets an autonomous agent operate Berry Juicer end to end. There is no browser wallet connection and no required wallet provider. The wallet that created the pool is the creator wallet: it signs a short authorization message, and the Berry backend verifies that signature against the same address. Any wallet that can produce an Ethereum personal_sign signature works, so an agent can use its Bankr wallet, a Privy agentic wallet, or any other EOA it controls.

• Berry API base: https://juicerapi.berryfi.org
• App: https://berryfi.org/juicer
• Chain: Base (8453)
• Docs: https://docs.berryfi.org

Authentication: read this carefully

Every spend or account write is authorized by a wallet signature, not an API key. The agent signs this exact message with the wallet that created its pool:

berry-inference:<address>:<timestamp>

Two rules MUST be followed exactly, or verification fails:

1. <address> MUST be lowercase. Most wallets return a checksummed (mixed-case) address; you must lowercase it before placing it in the message. Signing a message that contains a checksummed address fails with auth_failed. This is the single most common integration mistake; do not skip it.
2. <timestamp> is the current time in milliseconds, and the same value goes in both the message and the x-berry-timestamp header. Signatures are single-use and valid only briefly, so generate a fresh timestamp and a fresh signature for every request. Never reuse one.

Replay protection and signature scope — what is and isn't bound

Be precise about what the signature covers, so you handle it safely:

• Request-bound (v2, preferred): the signed message binds the request to chainId (8453), the API host, the HTTP method, the request path, a keccak256 hash of the body, a unique nonce, and an expiry (issuedAt/expiresAt). The backend recomputes the message from the actual request it received and verifies the signature against it, then enforces single-use via the nonce and rejects anything past expiresAt. This means a captured v2 signature cannot be replayed against a different route, a different body, a different host, or after it expires.
• Legacy (v1, being retired): the older message berry-inference:<addr>:<timestamp> is bound only to the address plus a short freshness window plus single-use. It does not bind host/path/method/ body. The backend still accepts it during migration; prefer v2.
• Treat every signature as a single-use live credential, regardless of version:
  • Generate a new signature with a fresh nonce for every request. Never reuse one.
  • Never log, print, persist, or transmit a signature anywhere except the x-berry-sig header of