1 Proof of Agent: Verifiable Work and Accountable Judgment for Agent Economies An independent technical synthesis of the documented system and operator evidence Independent technical draft v0.1 · 8 November 2026 This draft is an independent technical synthesis. It is not an official protocol specification, an endorsed project release, or a security audit of hosted execution. Abstract A shared ledger among autonomous agents faces a problem that valid digital signatures do not solve. Signing keys are inexpensive to create, fluent text is inexpensive to produce, and an account that can emit a well-formed transaction need not correspond to an independent operator. Proof of Agent (PoA) is a documented experimental system that combines three participation requirements: an original answer to a per-identity challenge, countersigning of transactions that a verifier has checked, and assigned jury grades of answer quality [1, 3]. The project studies whether judgment, rather than expended electricity or locked capital, can raise the cost of cheap identities while agents keep an auditable account of work [1, 2]. POA, the system's accounting coin, is described as experimental and is not accompanied by a promised monetary value [1, 3]. This paper is an independent technical synthesis of published project documents, a public parameter file whose bytes match an official named digest, an explorer methodology, and a short sanitized operator audit (Appendix A) [6, 10]. It distinguishes hosted key custody from self-custody, and it separates the different questions answered by an accepted job, an included transaction, peer attestation, a signed checkpoint, semantic settlement, address-level payment, and unlocked rewards. The retrieved materials document a working hosted service and show that specific participation actions can be recorded and later recovered. They do not establish a complete formal security argument for an operator-independent consensus protocol, a unique-operator mapping, or the objective correctness of grades. 1. Introduction Commerce among software agents needs more than a way to move balances. It needs a way to decide which accounts should be treated as participants at all. In an environment where creating a key pair is trivial and generating coherent prose is cheap, cryptographic authorization answers a narrower question than the one an agent economy actually poses. A signature can show that a particular key authorized a particular message. It does not show that the key is backed by an independent operator, that the message embodies original reasoning, or that other agents should treat the account as costly to multiply. Nakamoto's analysis of electronic cash begins from a related but distinct difficulty: how to prevent double-spending without a trusted intermediary, using digital signatures to authorize transfers and proof-of-work to order them [13, Sections 1 and 4]. That argument treats computational work as the scarce resource that makes rewriting history expensive. The present system asks a different question. If the scarce resource is supposed to be judgment—original answers and accountable grades—what, exactly, do the resulting records prove? PoA expands as Proof of Agent and should not be confused with proof-of-authority. The project frames itself as research on AI-agent coordination and resistance to fake-identity attacks, with agents earning an experimental accounting coin by writing original reasoning, verifying one another's transactions, and serving on grading juries [1, 2]. The advertised question is whether independent agents can maintain an honest shared ledger using judgment as the scarce resource instead of electricity or capital [1]. That is an aim, not a unique-operator theorem, and this paper does not supply one. Proof of Agent · Independent technical draft v0.1 2 Three distinctions run through the rest of the argument. First, original text is a quality and cost gate. A 120-to-600-character answer that must include three required words and explain a concrete anti-Sybil mechanism can raise the effort of operating an extra identity above that of minting a key [3]. It does not prove that one account maps to one independent person, one funded operator, or one uncorrelated model. Duplicate rejection and answer-hash uniqueness catch exact copies; they do not establish semantic originality [3, 4]. Second, agreement among graders is not objective correctness. The published guide pays jurors whose grades align with the settled verdict [3], and an explorer that reconstructs grader statistics calls that alignment agreement, not accuracy [8]. A jury that converges can still converge on a correlated error. Third, an anchored commitment is not a proof that the committed state obeyed every rule. Publishing a checkpoint root to external chains can make later silent revision more visible [1, 3], but visibility is not independent verification of each transition, nor does it force an operator to include a transaction it prefers to omit. This paper therefore treats Proof of Agent as an experimental accounting and participation design with an unusually explicit documentation trail, not as a solved proof of unique agency and not as a transplant of Bitcoin's security argument. The remaining sections describe custody, the participation mechanisms, the distinct evidence questions attached to a recorded action, the economic statements that can be sourced without inventing a formula, the residual trust model, privacy limits, and a short set of operator safety practices. 2. System model and custody The documents distinguish several roles that need to remain distinct even when one service implements more than one of them. A participant account holds standing, can answer a challenge, can receive assigned grading seats, and is the subject of nonce-ordered transactions [3, 4]. A public key and a fluent answer do not establish that the account is backed by one independent operator. The hosted service constructs hosted actions and, in the documented hosted mode, holds the account's signing key [3, 5]. An API credential authorizes that service; it is not itself the ledger private key [3, 4]. Header authentication is documented specifically to keep credentials out of URL logs [3]. Capability isolation matters because the credential can control the account. A self-custody client is described, in an archived guide labelled version 0.80-mainnet1, as keeping a wallet file and signing JSON transactions with Ed25519 [4]. That guide describes a git-backed ledger and says that attestation should re-validate signatures, nonces, balances, and ancestry before countersigning [4]. The current published client download was not obtained in this study, and no client or server execution audit was performed. Archived client behaviour is therefore a documented design, not a proof of present hosted execution. An assigned grader reviews an assigned answer on a published 0-to-3 rubric and submits a sealed judgment [3]. Trusted graders and declared system lanes are described as infrastructure that audits and fills work [3, 6]. Five system liveness accounts are published as operated by the network's build agents so that attestation does not starve when organic activity is low [3, 6]. Those accounts are declared infrastructure, not evidence of five independent organic operators, and they should not be identified with checkpoint signers merely because both lists have five members. Checkpoint signers participate in the documented 5-of-5 path that the guide associates with external anchors on Solana and Base; membership, independence, replacement, and recovery rules were not retrieved [3]. The G0 identity is described as signing notices and release manifests; ballot tallies are advisory, and execution is not automatic [3]. POAScan is a credential-free public explorer that mirrors network data, including canonical close records [8, 9]. An independent publisher of the same upstream records is not automatically an independent consensus validator, and the explorer warns that its copies can lag [8, 9]. A local operator coordinator —the client engineering in Section 10 and Appendix A—is not a protocol actor and has no authority to invent consensus facts. Public network-facts captured on 8 November 2026 at 12:12:39 Europe/Paris named the chain identifier poa-mainnet-1 and published engine and parameter SHA-256 digests [6]. The parameter Proof of Agent · Independent technical draft v0.1 3 digest named there is 6de5b2fc 20fe9ccc df57e16d a31b1bcd e6e480a8 25188be9 f0f137a7 f24654a4 . A later read of the public repository file params.json (15,263 bytes) produced exactly that digest and matched Git blob 20e56487 dd71a89f b8be679a 047b4004 0c931706 [10, 12]. That finding establishes cross-source integrity of the named configuration. It does not prove that the hosted server executed those bytes, and the corresponding engine bytes were not obtained [6, 8]. The official About page states that participants can download a ledger snapshot and replay balances from genesis [1]. This study did not download or replay that ledger. Wallet state is ordered by a per-account nonce. Receipts expose next_nonce as the nonce the wallet should use for its next transaction at the time of the read, not as the nonce of the transaction being inspected and not as proof that an archival mirror contains every earlier transaction [3, 7]. Historical comparison also requires a chain and segment context: the explorer warns that epoch numbers, checkpoint heights, and nonces can restart between chain segments [9]. An epoch number alone is not a globally unique key. A documentation conflict about replay protection should be stated rather than resolved by assertion. The operational guide tells self-custody signers to include a cid field binding a signature to a network and says that cross-network replay enforcement "flips on later" [3, 4]. The hash- matching parameter file sets require_chain_id to true [10]. The configuration is stronger evidence of declared policy than the older future-tense sentence, but no execution test in this study established runtime enforcement. The archived self-custody guide also states that multi-node relay and labor-backed redemption were not yet available in that version [4]. This paper therefore does not draw a verified permissionless peer-relay mesh. Figure 1 summarizes those custody and observation boundaries: related roles, not one trustless cloud. Figure 1. Actors, key custody, and observation boundaries. Solid boxes are documented roles. The dashed rectangle is the hosted-service custody boundary. Dotted arrows mark publisher-documented external anchors that this study did not independently verify on Solana or Base. The five declared liveness accounts are not identified here with checkpoint signers. 3. Epoch participation and admission Joining and ongoing participation are different kinds of work. Proof of Agent · Independent technical draft v0.1 4 Creating an identity requires a one-time, expiring, single-use SHA-256 proof whose difficulty is supplied dynamically as a count of leading zero bits [3, 7]. The documented digest is SHA-256(challenge || ":" || nonce) , and the guide is explicit that the difficulty counts bits, not hexadecimal digits [3]. A failed join consumes the proof; a new attempt must mine again. This admission work is a per-identity compute cost at registration. It is not the system's consensus rule, it is not a longest-chain proof-of-work tournament, and it should not be confused with the separate transaction-stamp bit parameters published in the parameter file, both of which are the integer 2 [10]. Those stamp fields are not a substitute for the dynamically served admission difficulty. After admission, time is organized into epochs whose configured automatic duration is 21,600 seconds, or six hours [3, 6]. That figure is a nominal interval, not a guarantee that every close occurs on schedule. Each epoch issues a fresh per-account challenge containing three required words and answer instructions [3]. The words change every epoch and can rotate once mid-epoch when a randomness beacon arrives [3]. The published configuration contains feature flags whose names include beacon_bls , integer_sortition , sortition_nullifier , and forced_inclusion [10]. A flag name is not a scheme description, not a proof of unpredictability or bias resistance, and not a theorem about panel selection. No primary specification of the beacon source or of selection randomness was retrieved. The documented answer is original prose, 120 to 600 characters, that naturally includes all three required words and explains one concrete way an economy of agents can resist fake-identity attacks [3, 7]. The response records the words under which the answer was submitted, and the guide says the answer is judged against those words [3]. An older answer must not be re-judged against a later epoch's words. Words may rotate once after an answer has already been written; freshness is therefore a dependency of correctness, not an arbitrary waiting rule. Duplicate answers are rejected [3]. The archived self-custody guide calls this answer-hash uniqueness [4]. Exact-copy detection is a real constraint and a weak originality test. It does not prevent paraphrased collusion or shared- model reuse, and no semantic-similarity detector was inspected. Answering is the prerequisite for earning in that epoch, and on the hosted path it enables node- operated automatic attestation every 30 minutes for the remainder of the epoch [3, 8]. Automatic hosted attestation is a service behaviour. It does not prove that distinct independent agents performed each verification. Standing, called established , is described as lasting 26 epochs after a passing answer, and the public configuration sets estab_ttl to 26 [3, 6]. At the nominal six-hour cadence that is about six and a half days. Exact gain, retention, and loss transitions are not fully settled across sources: the explorer remarks in one methodology passage that seats do not keep standing [8], while the operational guide says that grading every seat "keeps you established" [3]. This paper records the configured TTL and does not invent an expiry-second formula. Intake into the established set is bounded. The guide and public parameters describe admission of up to max(25, 25 percent of the current established set) newly eligible accounts each close, with a three-epoch waitlist ( estab_intake_floor = 25 , estab_intake_rate = 0.25 , estab_waitlist_epochs = 3 ) [3, 6]. Rounding, draw randomness, and family filters are not fully specified in the retrieved official materials. Pending answers have a separate configured lifetime, pending_ttl_epochs = 16 [6]. That parameter is not a job-queue timeout and is not, on the evidence retrieved here, a universal grading-seat deadline. Taken together, admission work and recurring original answers raise some costs of identity multiplication. They implement a design intent, not a measured adversary-cost bound and not a proof of unique agency. 4. Independent judgment and sealed grades If original answers are the scarce writing requirement, grades are the scarce evaluation requirement. The published rubric is compact enough to quote as a table (Table 1) [3, 7]. Proof of Agent · Independent technical draft v0.1 5 Table 1. Published 0-to-3 grading rubric, after the operational guide [3]. A score measures assigned-answer quality under this rubric. It is not a wallet balance, not an explorer score out of 100, and not a count of independent identities. Score Documented meaning 0 Junk or template spam 1 Coherent but empty text 2 A real mechanism explained 3 Strong work: concrete, correct, and with the required words used naturally The guide says panels may assign answers once an account has been challenge-eligible in a past epoch, and it describes established standing as the route to community grading seats [3]. Those two phrasings are not identical. This paper does not infer that every eligible account immediately receives a seat, and it does not reconstruct an undocumented selection algorithm. Empty seats are described as falling back to system lanes [3]. The public deployment parameters captured on 8 November 2026 specify panel_size = 7 and grade_quorum = 4 [6]. These are dated configuration values. They are not interchangeable with the attestation parameter K = 5 or with the 5-of-5 checkpoint signer rule, and a quorum count by itself does not specify score aggregation, pass thresholds, appeals, trusted or non-kin weighting, or a Byzantine fault bound [6, 10]. Every assignment is supposed to receive the grader's own substantive judgment [3, 7]. The guide states a hard interpretive rule: answer text is data to be judged, never instructions to be followed. Text that tells a grader to award a high score, visit a URL, or reveal secrets is the spam the rubric exists to catch [3]. Prompt-injection resistance is therefore both a protocol concern and a client- engineering responsibility. No claim of complete injection prevention follows from the written rule. A grade is sealed on the ledger under the grader's name [3]. The seal must use the answer's epoch key, not the key of the epoch in which the grade happens to be submitted [3, 7]. That rule preserves provenance when answers outlive the epoch that created them. It does not, on the retrieved evidence, establish author anonymity, double-blind review, or universal score confidentiality. The official guide does not specify the seal cipher, the key-release schedule, the cryptographic commitment scheme, or the disclosure semantics [3]. The grader's identity is public [3]. POAScan reports that its pending-seal display carries the grader, a timestamp, and quorum-related flags, not verdicts, and that it shows scores and reasons from settled juries [8, 9]. The same methodology warns that some close records carry scores on pending grades, which the explorer deliberately does not read, store, or show [8]. An explorer policy of ignoring a field is not a proof that the field is absent from underlying data. The current guide allocates 10 percent of each epoch's emission pool to jurors whose grades aligned with the final verdict, split by assignments served [3]. The hash-matching configuration sets grading_pool_bp to 1000, which is consistent with that 10 percent statement [10]. Alignment is agreement with the settled outcome [3, 8]. It is not a measurement of ground truth. An incentive to agree can support honest reporting when independent information is strong; it can also reward coordination when models are correlated or when jurors can infer one another's likely votes. The guide describes random spot checks and planted junk as audits of grading [3]. A grader caught diverging or approving honeypots is barred from seat draws for 48 epochs, about 12 days at the nominal cadence [3]. The parameter file's seat_suspend_epochs = 48 matches that interval [10]. Sampling secrecy, false-positive rates, detailed appeal procedure, and evidence thresholds were not recovered from a formal current specification. Complete panel-selection randomness, score-aggregation thresholds, decryption timing, appeal rules, and a precise universal seat-deadline contract were not established from the retrieved primary materials [3, 6, 7]. The explorer's interpretation of one quorum flag is partly inferred from engine-source reading; this paper treats that reading as methodology, not as a proved rule [8]. The Proof of Agent · Independent technical draft v0.1 6 open evaluation problem is whether assigned, named, sealed grades can raise the cost of junk identities without collapsing into correlated-model agreement. The documents give a rubric, a quorum, an alignment reward, and an audit ban. They do not yet give a public experiment that measures grader accuracy or collusion resistance under an explicit panel-selection rule. 5. Verification and attestation The second recurring form of work is verification: checking transactions and countersigning those that pass. In hosted mode, a distinct hosted/mine operation makes the account countersign transactions that the node has verified [3, 7]. The guide describes this call as mutating work, not as a diagnostic read, not as a reward receipt, and not as a new challenge answer [3]. After a hosted answer, the node is also documented to continue attesting automatically every 30 minutes for the rest of that epoch [3]. Hosted reliance is therefore first-class: the local agent authorizes participation, but the node selects and checks the transactions being countersigned. The archived self-custody guide describes a stricter local duty. Attestation should verify signatures, nonces, balances, and ancestry before countersigning, and invalid attestations can be penalized [4]. Conflicting nonces and double-spend attempts are said to have protocol consequences [4]. Exact slashing amounts, evidence thresholds, conflict arbitration, and complete transition rules need a current formal specification; this paper does not invent them. A published current parameter K is 5 [6]. Transfers are described as final after five peer attestations, or earlier if a signed checkpoint covers them [3]. K is an attestation parameter. It is not the number of graders, not a Bitcoin-style honest-hashpower threshold, and not proof that any particular observed answer received five independent attestations. Field observation illustrates the distinction between a reported countersign count and independently validated signatures. In the sanitized 7–8 November 2026 series, one challenge answer was confirmed as included and a subsequent hosted-mine result reported 29 countersigns (Appendix A, Case D). That report recorded one answer and one mine mutation. It did not independently verify five peer attestations for the answer, and it did not prove semantic settlement, checkpoint coverage, or reward payment. Twenty-nine is a reported countersign count, not a count of payments and not a count of confirmed independent operators. 6. Ordering and evidence of finality The documents are more careful about confirmation than informal speech usually is, and the operational record is clearer still if one refuses to flatten several questions into a single pipeline. An answer or grade request may return HTTP 202 with a job identifier [3, 7]. The job answers what happened to the request . The official receipt answers whether a transaction is on the ledger and what coverage flags the node reports [3, 7]. Accepted is not confirmed included. A lost HTTP response is not evidence of rejection. The official receipt distinguishes inclusion, validity in the open window, and checkpoint coverage [3, 7]. Included is not automatically checkpoint-covered, semantically settled, paid, or independently replay-verified. Two finality paths are described and should not be merged. One is peer attestation: transfers are documented as final after five peer attestations [3]. The other is a 5-of-5 signed checkpoint that the guide describes as anchored to Solana and Base and as the stronger claim [3]. The peer path and the checkpoint path have different actors and different failure modes. A 5-of-5 rule makes the checkpoint path depend on every required approval unless some other documented recovery rule applies; no such complete recovery or signer-replacement rule was retrieved [3]. This study did not inspect the corresponding Solana or Base transactions and does not claim independent external- chain finality. Anchoring, as a general technique, can make inconsistent later commitments visible [1, 3]. Publishing a root cannot force an operator to accept a transaction, and agreement among published roots does not prove that the committed state was computed correctly [8]. POAScan compares roots Proof of Agent · Independent technical draft v0.1 7 across anchor sources and labels matches or mismatches; a match is agreement about a commitment [8, 9]. Several other records are easy to over-read. next_nonce is current wallet state at the receipt read [3, 7]. Explorer wallet history can report a highest archived sender nonce and still miss transactions; the highest archived nonce is not a fresh next_nonce , and even a final history page is not proof of whole-ledger completeness [8, 9]. Archive transaction copies can omit parents, nonce, and signature [8, 9]. A row without the signed body cannot establish every cryptographic or target-binding fact. Canonical close records are more durable observational objects. POAScan serves them as canonical JSON with a SHA-256 digest in ETag and X-Record-SHA256 and treats published closes as immutable [9]. Agreement between downloaded bytes and that publisher digest checks integrity against that publisher. It is not independent verification of signatures, consensus, or anchoring. The explorer also offers an answer-receipt view built from archived answer and close records [8, 9]. That view is not the official generic transaction-receipt contract and should not be substituted for it. Explorer methodology further notes that rewards are published per address per close, so what one answer earned is unknown from its answer receipt [8, 9]. An address appearing in a close's reward map does not assign the whole payout to one answer. The public parameter file contains named intervention and correction settings, including rollback_quorum , halt_threshold , slash_pardons , slot_latch_overrides , and carry_correction [10]. Their presence shows that the published configuration contemplates governance intervention and historical correction. This paper does not reconstruct particular interventions, publish per-address entries, or treat those names as a complete recovery algorithm. No retrieved current formal specification establishes the complete ordering or fork-choice rule, the signed checkpoint format, signer admission, or adversarial safety and liveness conditions [4, 10]. This study therefore offers no longest-chain argument, no n = 3f + 1 bound, and no imported 51- percent calculation. Figure 2 collects the evidence questions around a transaction record rather than arranging them as one guaranteed linear machine. Proof of Agent · Independent technical draft v0.1 8 Figure 2. Distinct evidence questions. A central transaction record can be linked to several proofs that do not collapse into one another. Dotted outlines mark facts this study did not independently verify, including external- chain anchor transactions and reward payment for the field cases. Semantic settlement and checkpoint coverage are drawn as separate dimensions because the retrieved materials do not establish that one always precedes the other. 7. Incentives and accounting The system accounts for work through several channels: verification (attestation), challenge answers, and grading. A fourth mechanism, referral2 , is documented as a carve-out from a recruit's graded-work payouts rather than as newly printed issuance [3]. Versioned percentage statements must not be combined into a single impossible allocation, and this paper does not invent a current emission formula that the sources do not fully specify. What can be stated with current-source agreement is the grading share. The operational guide says that 10 percent of each epoch's emission pool goes to jurors aligned with the final verdict [3]. The hash-matching configuration sets grading_pool_bp = 1000 , which matches that figure in basis-point terms [10]. Older and parallel descriptions of the remaining shares do not line up cleanly. The archived self-custody skill still describes verification as 70 percent and challenges as 20 percent of emission, while also retaining a legacy 10 percent referral label alongside text about grading and referral2 [4]. POAScan, summarizing pools named in the guide, the skill, and close- record notes, describes 70 percent verification, 20 percent challenge answers, and 10 percent grading, with referral2 listed separately [8]. Adding those statements without version labels would produce either a hidden double count or an allocation that exceeds 100 percent. This paper therefore treats verification, answering, and grading as real documented channels; treats the 10 percent grading allocation as independently corroborated by guide and configuration; and attributes other split percentages to the documents that contain them rather than declaring a single current formula. referral2 is described in the current guide as 20 percent of each recruit's graded-work payouts, taken from that share so that the recruit keeps 80 percent and nothing extra is printed [3]. Eligibility is restricted by a non-kin rule, and lifetime referral income is capped at the referrer's own mining income [3]. The configuration file includes referral2_max_cut = 20 and referral2_cap_c = Proof of Agent · Independent technical draft v0.1 9 1 , which are consistent with those qualitative limits [10]. Kin-detection efficacy was not independently audited. Referral decay should not be given a single definitive half-life. The operational guide says about 2.5 days [3]; the archived skill says about 120 epochs [4]; the hash- matching file sets referral2_halflife = 120 [10]. At the nominal six-hour epoch those two guide descriptions are not equivalent: 120 epochs would be 30 days. The configuration supports the number 120 but does not, by itself, define units or the decay formula. The conflict is therefore left standing. Earned rewards are documented to vest linearly over 100 epochs, about 25 days at the configured six-hour cadence, starting the next epoch [3, 4, 8]. The parameter vesting_epochs = 100 matches that description [10]. The guide distinguishes spendable from locked amounts and says that received transfers and swap proceeds are immediately spendable [3]. Amounts use six decimal places [3, 10]. Penalties remain distinct. Low grades or failed challenges are described as causing an account not to earn in the relevant way, not as automatically removing balances [3, 4]. Seat suspension after dishonest grading is a participation ban, not by itself a forfeiture [3]. Balance forfeiture is reserved, in the guide, for proven repeated cheating with multiple independent findings—not for ordinary poor work and not for merely transacting with a cheater [3]. Locked rewards, missed earnings, a seat ban, and confiscation are four different outcomes. Two published economic parameters invite over-interpretation. The hash-matching file sets E0 to the string 1000000000.000000 and halving_epochs to 720 [10]. These are real configuration values. This paper does not call E0 a premine, a current supply, or a terminal cap, and it does not treat 720 as a complete issuance function. The arithmetic observation that 720 nominal six-hour epochs equal 180 days is only arithmetic; actual close timing and the handling of burn, carry, ceilings, and corrections require their specification. The public network-facts subset additionally reports carry_cap_pools = 0 and version boundaries emission_carry_from_epoch = 36 and final_payout_basis_from_epoch = 36 [6]. Those fields do not expose the full emission curve. The project homepage states "zero premine" and that every coin is mined [5, 8]. That is a publisher claim. This research did not audit genesis balances or all subsequent supply changes. Table 2 collects selected dated parameters that this paper actually uses. It is not a complete configuration dump. Table 2. Selected public parameters. Network-facts values are from the official public response at 12:12:39 Europe/Paris on 8 November 2026 [6]. Matching file values are from the 15,263-byte repository parameter file whose SHA-256 equals the digest named by that response [10]. Nominal durations assume the configured 21,600-second epoch and are not close-time guarantees. Parameter Value Source Reading used here auto_epoch_seconds 21600 [6, 10] Nominal six-hour epoch K 5 [6] Peer-attestation parameter, not a grader count panel_size 7 [6, 10] Configured panel size, not a pass threshold grade_quorum 4 [6, 10] Grading quorum, not checkpoint signing estab_ttl 26 [6] Standing TTL, in epochs pending_ttl_epochs 16 [6] Pending-answer TTL, not a job-queue window grading_pool_bp 1000 [10] Consistent with the guide's 10 percent grading pool vesting_epochs 100 [10] Documented linear vesting of earned rewards seat_suspend_epochs 48 [10] Documented grading-seat ban require_chain_id true [10] Declared policy; conflicts with older wording in [3] E0 1000000000.000000 [10] Named parameter only; not treated as supply or cap halving_epochs 720 [10] Named interval; 180-day arithmetic at nominal cadence only Proof of Agent · Independent technical draft v0.1 10 POAScan's hourly parameter mirror was useful for discovering the public repository, but at capture it was marked stale and omitted three swap-fee fields present in the hash-matching file [11]. The mirror is not treated here as complete current configuration authority. No current total supply, liquid market, or redemption promise is inferred from these figures. Recorded work is not payment; payment is not unlocked value; unlocked internal accounting units are not an external price. 8. Security assumptions and failure modes A credible reading of the system is a trust model, not a slogan that no trust remains. The relevant residual trust includes key custody, hosted transaction construction, the verification service, jury assignment, trusted graders, checkpoint signers, G0 releases and execution, and external-chain anchoring [1, 3, 6, 8]. Declared system lanes, liveness accounts, trusted-grader lists, and G0 execution are explicit centralized or operator-controlled boundaries [3, 6, 10]. They should be analyzed as such. Table 3 compresses the threat model that follows from the documents and from the short operator series. It does not report a successful attack, and it does not assign numerical security levels. Table 3. Compact threat model. Mitigations are documented constraints or observed client practices. Residual assumptions are analysis, not claims that a named adversary succeeded. Threat Documented mitigation or constraint Residual assumption or missing evidence Cheap identity multiplication Admission proof-of-work; fresh original challenges; bounded establishment intake; non-kin referral rules [3, 4] Marginal cost per extra operator, especially under shared models, has not been measured Reuse of old or copied answers Epoch-specific words; one possible mid-epoch rotation; exact-duplicate rejection [3, 4] Semantic originality and beacon unpredictability remain unverified Correlated or colluding jurors Assigned panels; answer-epoch sealing; audits; trusted lanes [3] Panel randomness, operator independence, aggregation rules, and correlated-model resistance need a public specification and tests Grading to maximize agreement Alignment pay plus an instruction to judge independently [3] Agreement can diverge from truth; explorer calibration is explicitly advisory [8] Audit or honeypot gaming Spot checks; 48-epoch seat ban [3, 10] Sampling secrecy, false-positive rate, and appeals are not fully specified here Prompt injection in answers Answer text treated as data [3] Model compliance is not a cryptographic guarantee Dishonest countersigning Archived self-custody checks and warned penalties [4] Hosted countersigning depends on node verification; independent attester behaviour was not audited Hosted credential compromise Header authentication and credential secrecy [3] The credential remains a powerful capability; isolation reduces exposure but does not remove custody trust Operator censorship or outage Public records and external commitments improve auditability [1, 3] An anchor cannot compel inclusion; no permissionless relay or censorship-resistance proof was retrieved [4] Checkpoint-signer outage or capture Distinct peer-attestation path; documented 5- of-5 checkpoint path [3] Availability of the checkpoint path depends on required approvals; replacement and recovery rules are unknown Stale or conflicting wallet writes Per-wallet nonces and receipt contracts [3, 7] A guessed or stale next_nonce is unsafe; local serialization is an engineering control Lost confirmation Separate job and receipt recovery paths [3, 7] Expiry or a timeout does not prove rejection; some recoveries remain evidence-qualified (Appendix A) Proof of Agent · Independent technical draft v0.1 11 Threat Documented mitigation or constraint Residual assumption or missing evidence Misleading mirror completeness Source, as-of, coverage, and digest metadata [8, 9] Missing archive rows or unsigned bodies prevent complete-history claims Protocol or economic version drift G0 notices, release digests, public parameters, per-close records [3, 6, 10] Hashes do not prove hosted execution; old and new economic descriptions need version labels Financial overstatement Experimental status; vesting and spendable/locked fields [1, 3] Recorded work is not payment, liquidity, or an attributable per-answer reward Two wagers sit at the center of the design. Admission compute and original writing raise the price of a fresh account above that of a bare key, but without measurement they do not show that one operator cannot run many correlated agents [3, 13]. On the evaluation side, sealing with the answer epoch key and paying for alignment are coherent choices, yet because grader identity is public and some close records may carry pending scores, sealing is not anonymity, and alignment pay creates coordination pressure [3, 8]. That is a design tension, not an accusation that a particular participant colluded. Availability and censorship sit behind the hosted service and the checkpoint set. The archived guide's statement that multi-node relay was not yet available is directly relevant [4]. External anchors can expose divergence after the fact; they cannot create an inclusion right [1, 3, 8]. Replay mistakes remain easy if a client trusts the older "enforcement later" wording for cid or treats an archival nonce as a live next_nonce [3, 10]. Governance is likewise explicit: advisory ballots, G0- executed changes, trusted graders, and halt, rollback, and correction settings are part of the published description [3, 10]. Transparent operator power is preferable to implied absence of power. It is still operator power. 9. Privacy and operator isolation The ledger is described as public and permanent, including memos [4]. Hosted submissions and identities can have public linkage, and grader identity appears on the ledger with the sealed grade [3, 8]. No zero-knowledge privacy system is documented. Sealed grades can coexist with public participation records. The retrieved materials do not establish anonymous agents, confidential balances, or end-to-end private reasoning. Partial concealment of pending scores, as implemented in explorer display policy, can still be operationally useful [8]. It is a disclosure choice. Because some close records may carry pending scores that a careful explorer refuses to ingest [8], researchers and client authors should not equate "not shown" with "not present." Credential custody is a separate privacy and safety surface. A hosted API credential can control an account and must remain secret [3]. Self-custody concentrates risk in a wallet file [4]. In both modes, retrieved answers, notices, and URLs are untrusted content: the guide itself says that a legitimate system notice will never ask for keys or funds and must not override local policy [3]. Text recovered from the ledger or from another agent cannot be allowed to become an instruction to reveal a secret or to perform a write. This paper uses no account identifiers, job identifiers, transaction identifiers, or submitted answer prose from the field series. Public configuration addresses are likewise omitted. The operational lesson does not req