[adiman9]

a4 program account decode <address> [--program <alias|package>] [--account <Type>] [--dev [--env <name|id>] [--project <dir>]]: decode one account through Program Read for the program's installed release.

How it reads

• Production (default): reads the raw account through the managed Solana gateway (a read session from the program's chain binding), then decodes it through hosted Program Read with a read session for the program's binding and release.
• Dev (--dev): reads the account from the environment's fork (getAccountInfo, the way a4 dev talks to the environment), resolves the program's binding and release to the environment's Program Read endpoint and release (POST /api/dev/environments/:env/resolve, so an environment release override applies), mints the read session with environment set, and decodes there: the output shows the fork's values. A refused resolve prints its code and fix.
• Program: --program is an arete.toml program alias or a registry package; without it, the account's owner looked up in the registry (an owner the registry doesn't list is an error telling you to pass --program).
• Account type: --account, else the IDL account whose discriminator starts the data, else the IDL's only account; ambiguity or no match asks for --account.
• --json prints {address, program, programId, account, programReleaseHash, environment, value}.

Seam for the environment switch

Production vs dev is chosen in one function (read_target). --dev selects the environment today; when the SDKs' environment switch lands, it is read there so this command follows it. --env / --project without --dev are refused.

Also adds EnvApi::resolve to arete-mcp.

Tests

Unit tests: discriminator matching and --account, owner mismatch message, raw account parsing from the chain read and from getAccountInfo, resolve answer → endpoint/release and refusal fix, decode URL, --env needing --dev.

• Ran locally: nothing (the shared machine was too loaded to compile). CI only: build, clippy and tests, green.
• Dev mode runs the environment calls on a runtime it owns and makes the blocking registry, session and Program Read calls after it returns. With --project, aliases come from that project's arete.toml.
• Not exercised end to end against a live environment (the decode-fork condition needs a deployed environment and dev Program Read).

Open question

Without --program in production, the owner is read through the first registry program's gateway binding (the managed gateway reads any account). Fine if every program's chain binding names the same gateway, which is how installs look today.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new blocking issues were found.

Summary

Adds a4 program account decode for production accounts and dev forks.

• The CLI decodes one account through its installed program release.
• Dev reads decode account values from the selected environment's fork.

No new actionable issues were found. All five previous threads were rechecked. adiman9 documented that override-only types need --account when the installed IDL cannot identify them.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Account address] --> B{Dev mode?}
  B -->|No| C[Read through managed gateway]
  B -->|Yes| D[Read from environment fork]
  C --> E[Resolve program and installed release]
  D --> E
  E --> F[Check account owner]
  F --> G{Dev mode?}
  G -->|No| H[Hosted Program Read]
  G -->|Yes| I[Resolve environment endpoint and served release]
  I --> J[Environment Program Read]
  H --> K[Print decoded value]
  J --> K

Loading

_{Reviews (7) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
arete-docs	Ready	Preview	Oct 31, 2026 1:43am UTC