Test with mobile

Use mobile approval and mobile signing with Gora app results — on the live testnet out of the box, or against a local dev bridge.

Test with mobile

Use mobile when a person needs to review, approve, or sign something produced by a Gora app.

Test against the live testnet

The iOS and Android source builds are preconfigured with the live bridge:

https://gora-bridge.74.241.248.103.nip.io

The wallet, GORA faucet, app directory, signing, and validator screens target the live testnet. Build the iOS project at apps/ios/Gora.xcodeproj in Xcode, or the Android project at apps/android in Android Studio. Simulator/emulator acceptance does not imply a published store/TestFlight release or signed Android distribution. Use a disposable testnet wallet, not a production key. Endpoints and deployed contract IDs are listed in Connect to the testnet.

Wallet-owned apps and autonomous bots

Open an app from the native app directory. Its deployed multi-file UI is served by Gora on its own HTTPS origin, while images and video may load from external HTTPS CDNs. The native wallet establishes an app-scoped session; neither the frontend nor the WASM program receives its private key.

For a trading bot, the customer flow is:

1. Configure a strategy and create a wallet-owned instance with a stable did:gora:testnet: identifier. The instance pins the deployed program version.
2. Create the on-chain vault, fund it with test collateral and native fees, and review the native approval sheets for the allowed venue, methods, amounts and budgets. This setup requires owner signatures.
3. Run the bot from its UI. Gora executes the deployed WASM, makes a structured LLM call and collects stake-backed validator replay signatures. The managed relayer submits an approved callback within the vault’s on-chain policy; the customer need not sign each trade. A runtime success alone is not proof of a trade: check the confirmed settlement and on-chain position.
4. Revoke automation whenever desired. The owner can still close an existing position while revoked and withdraw the remaining collateral. Disabling the app instance is useful but is not a substitute for on-chain revocation.

These Bigman vault callbacks settle on Algorand testnet. Base and Solana apps use a different path: separately approved managed agent signers write to the developer’s own contracts/programs. They do not require a Gora Base/Solana gateway. See Build a Base or Solana AI app. All three chains also support testnet validator staking. The mobile wallet retains the owner key; this phase’s Gora execution, validator hosting, agent custody and relayer infrastructure are centrally operated on one VM.

The flow below documents the separate per-action mobile-signing inbox. An autonomous bot uses the bounded vault authorization above instead of asking the owner to sign every decision.

Per-action mobile signing

When an app deployed to the live node returns a mobile_signing_request, the node publishes it to the live bridge with POST /mobile/signing-requests. The mobile app reads the same inbox through GET /mobile/signing-requests and shows the pending request for review and signing.

Quick checks against the live bridge:

curl https://gora-bridge.74.241.248.103.nip.io/health
curl https://gora-bridge.74.241.248.103.nip.io/mobile/signing-requests

There are two related flows:

Flow	Meaning
Mobile approval	User approves or rejects an app action
Mobile signing	User signs a native chain payload or transaction

Neither flow gives Gora the user’s private key.

When to use mobile

Use mobile for:

• transfers
• wallet actions
• smart-wallet approvals
• gateway fulfillment signatures
• any result that moves value or changes chain state

For pure off-chain results, mobile is optional.

App output shape

A mobile-signing app can return:

{
  "type": "agent_mobile_signing",
  "schema_version": 1,
  "app_id": "my_agent",
  "chain": "base",
  "decision": "approve_native_transfer",
  "mobile_signing_request": {
    "schema_version": 1,
    "chain": "base",
    "kind": "native_transfer",
    "from": "user_wallet_address",
    "to": "recipient_wallet_address",
    "amount": "1000",
    "amount_unit": "wei",
    "human_summary": "Transfer 1000 wei on Base Devnet"
  }
}

The Gora node can fill missing request metadata such as request id, app id, and timestamps before publishing to a signing surface.

Local Dev Bridge (secondary path)

Use this only when you run your own local devnet instead of the live testnet.

During development, a bridge service may expose pending actions to the mobile app.

Gora result → pending mobile inbox → user approves/signs → signed response → submitter/gateway

The bridge is a development helper. It is not a replacement for contract checks.

gora devnet up starts the bridge by default and exposes it through your public tunnel (ngrok, Caddy, or any HTTPS tunnel works):

VM-local bridge: http://127.0.0.1:8787
Mobile URL:      https://YOUR-BRIDGE-URL

Gora publishes signing requests to the VM-local bridge URL. The mobile app, running on another computer, should point at your public bridge URL in the app settings instead of the preconfigured live bridge.

If you start gora node serve manually, configure a signing-request sink with:

gora node serve \
  --http 127.0.0.1:8080 \
  --signing-request-sink http://127.0.0.1:8787

Or set one of:

GORA_SIGNING_REQUEST_SINK_URL=http://127.0.0.1:8787
GORA_DEV_BRIDGE_URL=http://127.0.0.1:8787

What users should review

Mobile should show:

• app name and app id
• chain
• sender
• recipient
• amount and unit
• policy or package hash
• attestation/result hash when available
• risk notes

Users should reject anything unexpected.

Dev keys

For local devnet tests, import only dev-only keys:

• Base hex private key
• Solana JSON/base58/base64/hex keypair
• Algorand 25-word mnemonic or raw key format

See Devnet wallets and keys.

Never import production keys into a local test build.

After approval or signing

After mobile signs, the signed response still needs to be submitted or fulfilled.

Common submission modes:

Mode	What happens
mock	Devnet records a mock tx/proof for tests
evm_raw	Raw signed EVM tx is sent with eth_sendRawTransaction
solana_raw	Serialized Solana tx is submitted with sendTransaction
algorand_raw	Signed Algorand tx bytes are submitted to algod

Your contract or gateway should still verify:

• Gora result or attestation
• app id
• output hash
• user signature
• policy limits
• replay protection

Quick test flow (live testnet)

This gateway-based example targets Algorand testnet, so use --chain algorand. For Base/Solana application writes, follow the separate managed-agent example; validator staking is independent of either application path.

Configuration is per project, not inherited from the parent directory. The token-generation command below is for a new developer identity; if you already have a developer token, supply that existing token through gora config set api.token --stdin instead. Keep a secure backup and never put the token in frontend code or published artifacts.

gora init mobile-test --template agent-mobile-signing --chain algorand --yes
cd mobile-test

gora config set node.url https://gora-bridge.74.241.248.103.nip.io
openssl rand -hex 32 | gora config set api.token --stdin
gora contract build --chain algorand
gora contract deploy --chain algorand --node https://gora-bridge.74.241.248.103.nip.io
gora contract link --chain algorand

gora build
gora validate
gora deploy
gora invoke --app mobile_test --input fixtures/request.json

Then open the mobile app, review the pending request, and sign with a testnet key. Treat all testnet keys and funds as disposable.

Next: Troubleshooting.