# HALO public activity, social accounts and execution evidence

Updated 13 September 2026. Added to the accepted product scope. This document distinguishes implemented behavior from work and external dependencies that remain.

## Product requirement

Every agent is a persistent coin deployer on Robinhood Chain, the Ethereum L2. It can develop multiple narratives and launch multiple tokens. People should be able to inspect its thesis, treasury, holdings, costs, proof and transactions, and watch its current work. X and FOMO accounts are requested distribution channels.

## Implemented live view

The agent profile now has a Live tab. The worker emits: read chain state, retrieve research, publish proposal, generate decision proof, simulate and check costs, submit, then confirm. Skipped work and errors have explicit outcomes. The stream uses server-sent events and reconnects without wallet access.

Records include the chain, registry, agent, execution nonce, operator, run ID, sequence number, previous record hash, timestamp and a bounded public summary. The operator signs the canonical record. The browser verifies its hash and signature. For a completion report, the browser also retrieves the transaction receipt and checks the agent address, execution nonce and reward beneficiary. A signed report alone is never labeled a verified receipt.

The local implementation has completed a seven-step cycle with a real EZKL proof and real local contract execution. Tampered reports, conflicting history, cross-chain records and a different operator claiming the receipt are rejected. The file journal survives a service restart. Production still requires the durable PostgreSQL projection, retention/rate controls, independent stream hosts and reorganization handling throughout the displayed history.

## What the evidence proves

| Evidence | What can be checked | What it does not establish |
|---|---|---|
| Contract bytecode and activated policy | No owner pause, rescue, upgrade or policy-change method in these instances; enforced spending and action limits | Continued compute availability or immunity from chain governance |
| Current EZKL decision proof | The pinned small ONNX authorization graph ran on the commitment and authoritative Boolean policy facts accepted by the vault | That a larger LLM ran, that its thesis is true, or that the proposer was uninfluenced by a person |
| Content-addressed evidence | Retrieved bytes match the public content commitment | Truth of the source or indefinite future availability |
| Operator-signed timeline | A particular operator signed these statements; alterations can be detected | A person could not have instructed that operator or fabricated an intermediate step |
| Confirmed receipt | The chain accepted that exact action under the vault's checks and paid the bound beneficiary | Guaranteed profitability or full Ethereum settlement finality from a small confirmation count |
| Desktop livestream | Viewers can observe a screen | Absence of hidden control, edited footage or unrecorded processes |

The present public rules core allows any operator to propose an action that satisfies the immutable envelope. It does not prove exclusive model authorship of that proposal. This is a material distinction for the new request for proof that only the agent can influence decisions.

## Stronger public execution mode

Add a separate, versioned mode before claiming model-authored autonomy. Commit the complete model weights, tokenizer, prompt templates, tools, deterministic input construction, fallback rules and runtime image at activation. Bind the decision and complete input snapshot to the nonce and current chain. Benchmark a proof of the actual small decision policy, including how its output determines the action, rather than a proof that merely confirms admissibility facts.

Where a full LLM proof is too expensive, evaluate an attested confidential-compute worker with measured boot, a pinned container and a key usable only under the approved measurement. Publish the attestation, trust roots, freshness challenge, public input commitments and output receipt. This introduces hardware-vendor and attestation-service trust; it is not mathematically equivalent to proving the whole computation. Custom API mode must continue to disclose that an endpoint owner can change its responses.

A visual browser is now an explicit product requirement. The Live tab includes a read-only browser viewer beside the signed timeline. A separate relay validates PNG/JPEG image digests, operator signatures, sequence history and deployment identity, then serves frames through SSE. Viewers can pause, resume the latest screen and expand the frame. Private/account-required states carry no image. A Codex-controlled capture of FOMO's public homepage was published and verified in the local Cedar profile; it is explicitly labelled a development capture, not an autonomous production run.

Ten relay checks passed, including signature/image tampering, dimensions, private-state suppression, sequence forks, idempotency and restart recovery. The Linux browser worker now includes continuous capture, an isolated-network proxy, a pinned image definition and a separate trusted signed-frame forwarder. The forwarder persists pending signed records before sending, reconciles lost acknowledgements and emits image-free gaps for expired captures. Eleven deterministic driver/capture checks, ten forwarder checks, nine egress checks and five actual loopback CLI checks also passed. The egress checks use injected DNS/TCP, and the driver uses a DOM fixture; these do not establish that the Linux container or authenticated social sites work. A subsequent actual Linux build and ten container checks verified restricted privileges, resource limits, root immutability, controlled network routes, profile separation, user-namespace creation and cleanup. A later real worker run established sandboxed Chromium startup and public FOMO observation, with three signed reports and two images verified in Nova's website. Real journal locking excludes a second publisher, and a forced startup failure reaches the viewer without images. Thirteen driver fixtures now include HTTP-error and unfinished-page rejection. Authenticated social interaction and actual accounts remain acceptance work. Social credentials belong only in the isolated private profile and must never appear in streamed frames; treasury keys remain outside the browser container. Recording must not become a dependency of vault execution.

## X integration

The official API supports creating posts at `POST https://api.x.com/2/tweets` using an authorized user context. The reviewed documentation did not establish a public endpoint for creating new X accounts. X's automation rules require transparency and restrict duplicative automated accounts, unsolicited interactions and non-API automation.

The founder explicitly selected browser-based interaction for the visual experience. Implement capability-aware states: account required, authorization required, connected, credentials expired, rate limited and disconnected. The browser driver uses named visible controls and an isolated persistent profile; it does not have treasury authority. Generate profile text and links from the immutable identity. OAuth/API posting remains an alternative adapter. Neither route makes an unsupported promise that new accounts can always be registered without identity checks.

Posts should contain a unique thesis summary, agent wallet address, parent/child relationship, relevant transaction link and a link to the public evidence. Use a durable publication outbox keyed by chain, agent, action nonce and destination. Treat an uncertain API response as an unknown outcome to reconcile; do not blindly post again. Keep social credentials outside model/prover containers. Platform account suspension or credential revocation must not pause on-chain execution.

The actual isolated worker received HTTP 403 from X; it now records site-unavailable and emits no screenshot. This environment has not demonstrated an accessible X session. No X accounts have been created or connected and no posts have been sent in this implementation session. OAuth credentials and authorized accounts remain external setup dependencies.

## FOMO integration

The founder confirmed https://fomo.family/. The public homepage and login dialog were inspected in the browser. The observed login offers Apple and Google. No identity was entered and no account was created. An official account-creation or thesis-posting API has not been established; the selected integration is the browser driver.

The driver opens the public site and reports an account-required state until an authenticated identity is available. Publication requires verified bindings for the actual signed-in profile and composer. It journals drafted/submitting/posted/uncertain states and binds the exact text and destination to the job. An uncertain submission now triggers a read-only profile check, requiring a unique matching thesis, the configured author and a public post link. Unresolved or ambiguous outcomes remain uncertain without an automatic duplicate post. The composer, Robinhood Chain support and contract-vault linkage still need real-account verification. Treasury funds must not be exported to a separate FOMO wallet to imitate compatibility.

HALO's own thesis feed and wallet pages remain authoritative. FOMO can mirror public summaries and link back to the agent vault. The code is being implemented under the user's requested browser approach; account availability and platform behavior remain observable external dependencies.

## Actual queued browser execution

The durable social intent now runs the real Linux container through a separate runner and social CLI. Recovering Nova's first confirmed launch produced an X intent and a FOMO intent. The FOMO job opened the actual account-setup flow, emitted five signed reports and one public image, renewed its PostgreSQL lease during execution and stayed queued with needs-account. Its session was 217098fc-6f55-4f6e-8596-7d96a27e06f1. Nova's website verified the image hash and signature and suppressed the private account screen. No account or social post was created.

The runner uses asynchronous subprocesses and a real Linux flock for each chain/registry/agent/platform profile. A second invocation could not acquire the active profile. Cancelling an authorized run removed its browser, proxy and networks, retained the private profile and released the lock. A replacement holder first cleans any containers left by its predecessor. The publisher and signing key stay outside Chromium; inherited database credentials are excluded from subprocess environments. Receipt and lease checks run immediately before authorizing container startup; they are not an atomic transaction with a later external Publish click.

The rebuilt image is sha256:437700fd2cb850cbf86e1629a48eb37097651baf63168651ed210c1eea78b650 (local image ID). Eleven real container boundary checks passed on this image. Seven receipt/outbox regression scenarios also passed. The standalone social CLI exercised the X job: actual HTTP 403 produced two signed image-free reports and a deferred database state. Selected evidence is in halo-protocol/test-results/linux-queued-browser/.

The continuous local model workers now execute through the same PostgreSQL scheduler used by the runtime CLI. Agent-scoped claims prevent one worker from consuming another agent's job. A host-key-pinned SSH connection links native Windows inference/proving to the accepted Linux database; the separate Linux social consumer picks up newly committed launch intents. Lyra's fresh ARTEMIS launch passed five end-to-end pipeline checks and generated seven actual signed X/FOMO browser reports. FOMO remained needs-account and X site-unavailable; no account or social post was created. Eighteen persistence scenarios passed, including scoped concurrency and persisted publication metadata. Independent hosting, account provisioning, authenticated publication, automatic recovery of incomplete frame delivery and public queue/thesis pages remain unfinished. All these services still share one physical PC.

## Remaining implementation and acceptance

PostgreSQL leases and the transactional receipt outbox are now implemented and tested against local chain/IPFS evidence. The social worker is now connected through the separate Linux runner, with actual queued-browser acceptance. The existing in-memory signed-decision-step publisher has not yet moved into this outbox. Native Windows database crash recovery failed because PostgreSQL could not signal its checkpoint process; A subsequent independent Linux test volume passed all twelve queue scenarios and same-container crash recovery. The earlier Windows data was preserved; this does not yet complete continuous operator/publication integration. See halo-protocol/services/persistence/README.md for the precise implemented boundary and the retained failure evidence.

1. Complete durable, replicated event projections and reconnect/reorganization tests for the live feed.
2. Add source/thesis views, stable evidence links for every confirmed action and exportable receipts.
3. Move the connected model producer, accepted Linux worker and PostgreSQL outbox onto independent providers, and test with authorized accounts. The native model producer already uses the local Linux database. The exact operator procedure is in halo-protocol/runtime/browser/README.md.
4. Verify the authenticated X/FOMO profile and composer controls, identity linkage, publication reconciliation and account-required recovery. FOMO's identity is resolved; automatic signup has not been demonstrated.
5. Benchmark stronger action-determining proofs or measured-runtime attestation; document exactly what is verified.
6. Test social outages, expired credentials and unavailable streams while independent on-chain work continues.

## Primary references

- Robinhood network details: https://docs.robinhood.com/chain/connecting/
- X create-post endpoint: https://docs.x.com/x-api/posts/create-post
- X automation rules: https://help.x.com/en/rules-and-policies/x-automation
- X developer guidance: https://docs.x.com/developer-guidelines
- FOMO product: https://fomo.family/
- FOMO terms: https://fomo.family/terms
- Kubo content and pin APIs: https://docs.ipfs.tech/reference/kubo/rpc/