Skip to content

Petri configuration and wallet safety

Petri talks to two services: a Solana RPC for the chain, and Amoeba’s futures API for market data and sponsored transactions. It signs with a wallet on your own computer. It never prints key contents and never sends keys to a service or to an AI agent.

Out of the box, Petri talks to Amoeba on Solana mainnet. This is its production profile, and it needs no setup:

Setting Flag Environment variable Default
Solana RPC --rpc <URL> PETRI_RPC_URL https://api.mainnet-beta.solana.com, Solana’s public mainnet RPC
Futures API --api <URL> PETRI_API_URL https://api.amoeba.farm

Petri uses the flag or environment variable first, then the saved setting, then the profile’s default. petri config show (or just petri config) shows the profile and its cluster, which addresses are in use, and where each one comes from.

Terminal window
petri config show # profile, cluster, every setting and where it comes from
petri config set rpc <MAINNET RPC URL> # your own mainnet RPC
petri config reset rpc # back to Solana's public RPC

petri config set and petri config reset take five keys: profile, rpc, api, keypair and deployment. URLs must be http or https, with no user name, password, query or fragment.

Solana’s public mainnet RPC is rate-limited. If you trade often, run scripts or read a lot, use your own mainnet RPC, such as your RPC provider’s: pass --rpc <URL>, set PETRI_RPC_URL, or save it with petri config set rpc <URL>.

The RPC must be a full Solana RPC node. The futures API’s browser gateway at https://api.amoeba.farm/rpc is not one: it allows only the methods the web app needs. If an RPC refuses a method, Petri names the method and says that it needs a full RPC node. Petri calls these methods:

Method Used for
getAccountInfo, getMultipleAccounts Markets, the oracle, governance gates and the cluster’s clock
getProgramAccounts The oracle’s periods and sources (not on the browser gateway)
getBalance A wallet’s SOL
getGenesisHash Checking which chain the RPC serves, before anything is signed
getSlot, getVersion petri status (getVersion is not on the browser gateway)
getLatestBlockhash, getBlockHeight Building transactions, and telling when a sent one has expired
sendTransaction, getSignatureStatuses, getTransaction Sending a signed transaction, confirming it, and reading its logs
simulateTransaction Oracle writes with --simulate (not on the browser gateway)

The profile decides which deployment Petri talks to and trusts when nothing else is set. production (also prod or mainnet) is the default and the only profile you need to trade: Solana mainnet-beta, the RPC and API above, and only Amoeba’s production programs (see Trusted programs).

Choose a profile with --profile <PROFILE>, the PETRI_PROFILE environment variable, or petri config set profile <PROFILE>. petri config reset profile goes back to the default. petri config show and petri status show the profile in use and its cluster. The other profile, dev (also localnet), is for developers testing on a local chain; see Testing on a local chain.

Petri saves settings in a private config.json file:

System Location
Windows %APPDATA%\amoeba\petri\config.json
macOS and Linux $XDG_CONFIG_HOME/amoeba/petri/config.json, or ~/.config/amoeba/petri/config.json

Set PETRI_CONFIG_PATH to use a different file.

Petri needs to know which programs to trust before it reads a market or signs anything. By default it takes their addresses from the futures API’s /v1/config. To pin them yourself, pass a deployment manifest with --deployment <PATH> (or PETRI_DEPLOYMENT), or save it with petri config set deployment <PATH>.

In the production profile, Petri trusts only Amoeba’s production deployment: Solana mainnet-beta, the oracle 45YCerssGjg2M29RFc9D4fAJh7dfFpMJ3ZcZtaTnRXRS, the futures program Bvp9kiRtJ7dT8unxP4Da39gv2eXDLEHLpcDfzcEuRKMu and the governance controller 8fhNi6QHU5TYNhoPDM4vs89ZBztnpxp3LnBXRgkBVKtx. If the API’s /v1/config names another cluster, other programs or another controller, Petri refuses it, so a wrong API cannot point Petri at other programs. See Deployment.

Before signing, Petri checks that the RPC serves the deployment’s chain (its genesis hash) and that the programs are deployed there. It refuses a market that the trusted futures program does not own, or one that settles in another USDC or reads another oracle. If a check fails, it stops before anything is signed.

petri status runs these checks and shows the profile and cluster, the cluster’s clock, the API, each program, the markets and your wallet.

petri wallet new creates a signing wallet and prints only its address. It saves the key as futures-id.json next to Petri’s settings file, readable only by you, and makes it the wallet Petri signs with. --out <PATH> writes it somewhere else without making it your signing wallet. Petri won’t overwrite an existing file unless you pass --force, and the old key is then lost.

Petri looks for the signing wallet in this order:

  1. --keypair <PATH>, or the SOLANA_KEYPAIR environment variable
  2. the saved keypair setting (petri config set keypair <PATH>)
  3. keypair_path in your Solana CLI config file (--solana-config or SOLANA_CONFIG; default ~/.config/solana/cli/config.yml)
  4. ~/.config/solana/id.json

To sign with a Ledger, use a hardware-wallet locator such as --keypair usb://ledger. Unlock the Ledger and open the Solana app first.

Petri signs only with a key file that is a regular local file. It refuses a key file that other users can read. Fix the permissions rather than overriding the check. On macOS and Linux:

Terminal window
chmod 600 ~/.config/solana/id.json

--allow-insecure-keypair (or AMEBA_ALLOW_INSECURE_KEYPAIR) skips that check. Use it only if you understand the risk.

petri wallet address prints the public key Petri would sign with. petri wallet shows that wallet’s SOL, USDC and cash in each market.

Reads don’t need a key. petri positions <OWNER>, petri wallet <OWNER> and petri history <OWNER> read any public address without opening a key file.

Futures markets charge no trading fee. Each transaction still pays a Solana network fee, and --route decides who pays it:

Route Who pays the fee How the transaction is built
local Your wallet, in SOL Petri builds and solves the order from the chain itself.
sponsored The futures API’s sponsor The API prepares it. Before signing, Petri checks that the sponsor pays the fee, that it acts only on this market of the trusted futures program, with you as the owner, for exactly the order you asked for, and that it deposits no more than that order can need.
auto (default) Your wallet when it has SOL for fees, otherwise the sponsor As above.

Petri also refuses the sponsored route if the API names another sponsor or other programs than the deployment it trusts. The local route needs SOL in your wallet for fees; without it, auto uses the sponsor.

Oracle writes always use your wallet: it signs them and pays their fees.

Petri quotes every order and asks before it signs. --yes sends without asking. Use it only in scripts you have checked.

  • Never put a seed phrase, private key, key file contents or provider credential in a command argument, a prompt, an MCP setting or a support request.
  • Keep the file petri wallet new creates private. Anyone who has it controls the wallet.
  • If a check fails, find out why. Do not switch services, networks or wallets to get around it.
Option Effect
--json JSON for scripts and agents. AMEBA_OUTPUT=json does the same.
--no-color or --plain No colors. Petri also leaves colors out when NO_COLOR is set or the output goes to a pipe.
Terminal window
petri markets
petri --json markets
petri market ramx --json

Options can go before or after the command name. See the Command reference for every option and environment variable.