Skip to main content

​
Validators and consensus

Gora’s current public testnet is deliberately managed on one VM. Validator stakes and execution signatures are real, but hosting, coordination and key custody are not independently distributed. Do not interpret a receipt with several signatures as evidence of several independent operators or machines.

​
Stake and participation

Validator staking is deployed on Algorand testnet, Base Sepolia and Solana devnet. The mobile app signs with the user’s wallet on the selected chain; the manager admits validators only after checking the relevant stake and owner authorization. See Connect to the testnet for canonical staking contracts and test GORA assets. There are two distinct keys: An app’s managed agent wallet is a third, separate authority. Its trading or transaction permission does not follow from validator stake. See Agent identities and signing.

​
The managed execution path

  1. The node authenticates the caller and loads the pinned WASM, isolated state and current chain-verified validator membership.
  2. The coordinator executes the program, recording external HTTP/model inputs.
  3. Managed validator workers replay the program in fresh WASM stores using those captured inputs. They do not make a new paid AI call per vote.
  4. Workers sign votes binding the proposal, transcript and observed outcome. The node validates the required vote count and stake-weighted quorum.
  5. The node commits the accepted result/state and retains the receipt and attestations. A proposed chain action still needs separate policy checks, submission and confirmation.
Membership is based on manager admission and verified stake, not merely on which private-key files happen to be available. The current managed committee limit is 64 admitted validators; this is not the application/agent limit. Recent functional receipts contain six verified votes and six attestations, not a guaranteed fixed committee size for future requests. The managed path is distinct from the repository’s legacy gossip/VRF round implementation. Its centralized coordinator and in-process replay workers must not be described as a live coordinator-free distributed network. Actual validator child-process health is monitored separately; loaded managed signers alone are not evidence that those child processes are healthy.

​
What a receipt proves—and does not

Verify the exact request/app/program binding, transcript commitment and signatures against the recorded committee. Signed replay establishes agreement on execution over the captured inputs. It does not prove source-data truth, independent inference, model quality, fault isolation or honest custody by a compromised VM operator. Chain delivery has its own trust model:
  • The managed Algorand gateway uses an operator settlement signer following off-chain quorum. It is not on-chain threshold verification of every vote.
  • Base/Solana managed agents sign under the separately approved policy and call the application’s own contracts/programs. Those contracts do not automatically verify Gora committee signatures.
Check the finalized execution receipt, confirmed settlement and actual chain state separately. A signed result is not proof of a trade or transfer.

​
Current operating limits

There is no claim of independent hosting, threshold key custody, an external security audit or enforced slashing. VM/RPC/provider outages can stop progress; quorum and freshness failures must not be bypassed to keep an app running. The dedicated load test was waived, so hundreds/thousands-of-agents throughput is unmeasured. These are bounded testnet capabilities, not mainnet assurances.