Trust

Trust model & FAQ

Aetheris is honest about where its guarantees come from. Some things are enforced by Solidity and cannot be bypassed by anyone, including the operator. Some things the operator decides. Some things happen off-chain and are only recorded. This page draws those three lines, then answers the questions people ask.

What the contracts enforce

These hold for every caller, operator included, and are tested in test/aetheris.test.js.

Escrow is solvent. createJob moves the deposit into the treasury, and AetherisTreasury.recordEscrow re-reads its own balance and reverts with SolvencyCheckFailed if the tokens did not land.
Committed fees never exceed the deposit. assignSubAgent reverts with FeeExceedsDeposit when the running total would pass job.deposit.
Only completed work is paid. settleJob pays tasks whose status is Completed, marks them Paid, and the margin is whatever escrow remains. Assigned-but-unfinished tasks earn nothing.
Escrow and margin are separate pools. Escrow operations on the treasury are onlyAgency; claimProfit can draw only from retainedMargin; sweepSurplus can move only balance in excess of totalObligations.
Refunds are bounded by status. refundJob works only while a job is Funded or Dispatched, only for the client or the operator, and returns the full escrow.
Margin needs a verified human. claimProfit reverts with OperatorNotVerified unless the agency's isVerifiedOperator is true for the caller.
A nullifier is burned once. verifyOperator marks the nullifier used before any external call and reverts on reuse - in bypass mode too.
Bypass is never silent. A zero World ID router emits WorldIdBypassActive at construction and on setWorldId, and each bypassed registration emits OperatorVerifiedWithoutProof.
Rail downgrades are visible. A failed HTS transfer emits HtsPayoutFallback with the Hedera response code before the ERC-20 path runs.

What the operator controls

The operator is the owner() of both contracts - the deployer. On Hedera testnet that is account 0.0.10484502 (0x6967…1F9b).

Operator-only actions and where they are gated
Staffing a job	`assignSubAgent`, `cancelTask`, and `completeTask` on behalf of a sub-agent are `onlyOwner` (the sub-agent may also complete its own task).
Settling	`settleJob` is `onlyOwner`. A client cannot force settlement; the client can refund instead while the job is unsettled.
Treasury configuration	`setAgency`, `setHtsEnabled`, `associateToken` and `dissociateToken`.
World ID router	`setWorldId(router, groupId)` can enable real proof checking or re-enter bypass mode.
Margin	`claimProfit` (after verification) and `sweepSurplus`. `rebalance` records an off-chain swap into the margin accounting.
Off-chain keys	The same key is the HCS topic submit key, the World ID relayer in `POST /api/operator/verify`, and the faucet signer in `POST /api/faucet`.

What is off-chain

The work. The contract stores a specURI and, per task, a resultHash plus an HCS topic and sequence number. Whether the hash corresponds to useful output is not something the chain can check.
The audit frames. HCS orders and timestamps the frames by consensus and makes them immutable, but their content is authored by the operator. Corrections are append-only and stay visible.
Proof of personhood. Today the World ID 4.0 result is verified by World ID's cloud verifier (lib/worldid.ts); the on-chain contract only burns the nullifier the server forwards.
The index. The subgraph is one graph-node you or we run. It derives everything from contract events, so it can be re-indexed and checked, but it is not a decentralised network.
Quotes and names. 1inch quotes come from the 1inch API for other EVM chains; ENS names are resolved on Ethereum mainnet through a public RPC (lib/ens.ts). Neither touches Hedera state.

Known limits

Stated plainly, because the UI states them too:

Single relayer and faucet key - the deployer key does everything the server signs.
Testnet only - Hedera testnet, chain id 296; no mainnet deployment exists.
World ID bypass on-chain - no router on Hedera, so the ZK proof is not checked by the contract.
Self-hosted indexer - Hedera is not on The Graph network.
1inch is not on Hedera - the swap panel routes for the operator's EVM wallet on other chains, it does not rebalance the treasury.
Sub-agent work is simulated - the seed commits result hashes; no model call is part of the contracts.
Panels are labelled - every panel carries a LIVE or DEMO DATA pill with the reason; nothing is presented as chain data that is not.

FAQ

What does World ID bypass mode actually mean?

There is no World ID router contract on Hedera, so AetherisAgency was deployed with a zero router address. In that state verifyOperator skips only the zero-knowledge proof check. Everything else still runs: the nullifier hash is burned before anything else happens, a second call with the same nullifier reverts with NullifierAlreadyUsed, and the caller is marked as a verified operator. The mode is announced on-chain - the constructor emits WorldIdBypassActive and every bypassed registration emits OperatorVerifiedWithoutProof - and worldIdVerificationBypassed() returns true. The owner can turn real verification on without redeploying via setWorldId(router, groupId). The human check that does run today happens off-chain: the IDKit v4 result is verified against World ID's cloud verifier in lib/worldid.ts before the server relays the transaction.

Why is the subgraph self-hosted instead of on The Graph network?

Hedera is not in The Graph's network registry, and Subgraph Studio offers neither Hedera mainnet nor testnet. The supported path, and the one Hedera's own subgraph guide documents, is a graph-node you run yourself pointed at the Hedera JSON-RPC relay. That is what subgraph/docker-compose.yml and deploy/vps-subgraph.sh do. The trade-off is that readers trust whoever runs the indexer; the mitigation is that every entity is derived from contract events anyone can re-index, and the manifest, schema and handlers are in the repository.

What exactly is anchored to the Hedera Consensus Service?

Every lifecycle step is written to topic 0.0.10518320 as compact JSON - {evt, jobId, taskId?, agent?, amount?, token?, resultHash?, tx?, ts} - before the contract call, so the sequence number the network assigns can be passed into completeTask and matches what the mirror node returns. The one exception is ProfitClaimed, which scripts/claim-margin.js anchors after the receipt because that frame quotes the transaction hash it describes. HCS is append-only: a mistaken frame is retracted by a {evt:"Correction", voids:[seq], reason} record, and lib/hedera.ts hides voided frames while keeping the correction itself visible. The topic's submit key is the operator, so the log is tamper-evident and ordered by consensus, but it is authored by one party.

Can a client get the deposit back?

Yes, while the job is Funded or Dispatched. refundJob(jobId) can be called by the client or the operator; it cancels any assigned or completed-but-unpaid tasks, and the treasury returns the full escrow to the client. Once settleJob has run the status is Settled and the escrow has been split between sub-agents and margin, so there is nothing left to refund.

Who can sweep the margin?

Only the treasury owner, and only if the agency reports that address as a verified operator. AetherisTreasury.claimProfit(token, amount, to) is onlyOwner and reverts with OperatorNotVerified unless isVerifiedOperator(msg.sender) is true. It can only move retainedMargin[token], never escrow. sweepSurplus is separate and can only move whatever the treasury holds above totalObligations - airdrops and accidental transfers. One real claim of 0.5 aUSD has been made on the testnet deployment.

Is the AI real? Do the sub-agents actually do work?

Not in what is on-chain today. The contracts never call a model; they record a resultHash and an HCS reference for each completed task. The seeded lifecycle is produced by scripts/seed.js, which simulates the sub-agents: the result hash it commits is keccak256(specURI#taskIndex), and the script itself calls completeTask as the operator. The sub-agent accounts are real Hedera accounts that really receive HTS payouts; the work attributed to them is not. The protocol is the payment, escrow and audit layer that an actual agent runtime would plug into, and the page says so with DEMO DATA pills wherever a panel is not reading chain data.

HTS or ERC-20 - which one is used and why both?

AetherisTreasury._payout tries the Hedera Token Service system contract at 0x0000000000000000000000000000000000000167 first when the token is an HTS token and htsEnabled is on; the precompile answers with an int64 response code (SUCCESS is 22). If that fails it emits HtsPayoutFallback with the code and falls back to a standard ERC-20 safeTransfer. MicroSettlement.viaHts records which rail ran, and the subgraph exposes it as Settlement.viaHts. Both rails are exercised on testnet: an HTS settlement measured 2,360,527 gas against 229,111 for ERC-20. The fallback exists because a call to an empty account returns UNKNOWN (21), so a deployment without the precompile still settles instead of bricking.

Why aUSD and aUSDC? Are they real stablecoins?

No. Both are test assets. aUSD (0.0.10484673, 6 decimals) is an HTS fungible token created by the seed so the HTS rail can be exercised; the treasury had to associateToken with it first. aUSDC (0x21DCc52AbbCAef92B4573dc8B0e1658417c85961, 6 decimals) is a plain test ERC-20 with an open mint, which is what lets the faucet hand out 10 aUSDC per drip and lets the client view fund a job from the browser. Neither is backed by anything.

Is this production ready?

No. It is a testnet deployment built for ETHOnline 2026. The contracts have 37 Hardhat tests and guard the invariants described above, but they have not been audited; the operator, relayer and faucet are one key; World ID proofs are not verified on-chain; the indexer is a single self-hosted node; and worldIdVerificationBypassed() is documented in the source as something that must be false on any deployment that handles real value.

Does the 1inch panel rebalance the treasury?

No. 1inch does not support Hedera, so /api/swap/quote and /api/swap/build quote pairs on Ethereum, Arbitrum, Base, Optimism and Polygon. It is a routing tool for the operator's EVM wallet. The treasury's rebalance function records the settled result of an off-chain swap for accounting and audit; it does not execute one.

How can I check any of this myself?

Read the contracts on HashScan (0x16fA…bc81 and 0x1036…5598), list the topic messages with GET /api/hcs?limit= or directly from the mirror node at https://testnet.mirrornode.hedera.com, and compare the subgraph's Settlement and HcsAnchor entities against the emitted events. The source for everything, including the seed, is at github.com/mrnetwork0001/Aetheris.