Set policy and payments

Define what your Gora app can do, which chains it can use, and who pays for execution.

Set policy and payments

policy.json is your app’s rule book. It tells Gora, wallets, and contracts what the app is allowed to request.

Declaring a policy does not grant transaction authority. The public managed testnet requires a separate wallet-approved agent policy or on-chain vault authorization. See Agent identities and signing. Test GORA AI payments are also separate from gas, stake and collateral; follow AI credits before the first provider attempt.

A good first policy is strict:

• one chain
• one action
• one or two recipients
• low amount limits
• manual mobile approval

Example policy

{
  "schema_version": 1,
  "policy_id": "policy:my-agent:v1",
  "allowed_actions": ["agent_mobile_signing"],
  "allowed_chains": ["base"],
  "chain_policies": {
    "base": {
      "execution_modes": ["manual_mobile_signature", "preapproved_agent_wallet"],
      "max_amount_per_tx": "1000000000000000",
      "max_amount_per_day": "5000000000000000",
      "amount_unit": "wei",
      "native_token": "ETH",
      "allowed_recipients": [
        "0x2222222222222222222222222222222222222222"
      ]
    }
  },
  "payment_principles": {
    "gora_node_holds_user_keys": false,
    "gora_node_pays_user_gas": false,
    "default_fee_payer": "user_or_user_preapproved_on_chain_account"
  }
}

Important fields

Field	Meaning
allowed_actions	App result types that are allowed
allowed_chains	Chains the app can target
execution_modes	How an intent becomes an approved action or transaction
max_amount_per_tx	Per-transaction limit in chain units
max_amount_per_day	Daily limit in chain units
allowed_recipients	Recipient allowlist
payment_principles	Explicit statement of who holds keys and who pays

Execution modes

Mode	Meaning
offchain_result	App returns a result with no chain execution
manual_mobile_signature	User reviews and signs each action or transaction
preapproved_agent_wallet	Agent can act through a limited wallet policy
preapproved_smart_wallet	Smart wallet enforces limits approved ahead of time
preapproved_logicsig	Algorand-style delegated logic or escrow policy
preapproved_mobile_session	Mobile creates a limited session for repeated actions
app_contract_paid	App contract pays or reimburses execution
paymaster_sponsored	Paymaster or sponsor pays gas

Who pays?

The owner wallet signs locally. If a Base/Solana managed agent is explicitly authorized, its separate key is held by the VM and its wallet needs test gas. The metadata example above does not describe that managed custody; disclose the actual execution mode you choose. Possible app designs include:

Payer	Common use
User wallet	Manual mobile signing, safest first test
Agent/smart wallet	User has pre-approved tight limits
App contract	App sponsors or reimburses users
Paymaster	Account-abstraction style sponsorship
Operator script	Devnet-only testing and fulfillment

Manual mobile signing flow

Gora app returns mobile_signing_request
        ↓
Mobile shows chain, recipient, amount, and app metadata
        ↓
User signs or rejects
        ↓
Signed payload is submitted according to submission_plan

This is the recommended first flow for anything that moves value.

Pre-approved flow

User approves rules once
        ↓
Wallet/contract stores limits
        ↓
Gora result is checked against policy
        ↓
Contract/wallet executes only if limits pass

Use this only after manual signing is working.

Units by chain

Chain	Native token	Unit
Base/EVM	ETH	wei
Solana	SOL	lamports
Algorand	ALGO	microalgos

On the public testnet, Algorand vault/gateway flows and separately approved Base/Solana managed-agent writes are live. Generic metadata fields do not enable every execution mode in the table: use the implemented Base/Solana policy flow or Algorand vault path, and check current endpoints.

Validate policy changes

After editing policy.json:

gora validate
gora package

Then redeploy:

gora deploy

Next: Devnet quickstart.