Skip to content
ORIZON_AGENTS
Launch App ▸

Evidence

Orizon Agents: evidence index for the Stellar Instaward

As of
Network
Stellar testnet
SOW
v4, dated

This index follows the approved SOW v4, dated 2026-08-01. Section 6.1 says what evidence each deliverable owes, section 6.2 is the checklist the Ambassador Chapter Lead marks (Present, Partial or Missing), and section 6.3 lists the eleven success metrics. Each deliverable below repeats the SOW's Evidence Type and Description word for word. Every piece of evidence has a status and a link you can open, and anything missing or partly done says why in plain words.

How to use this page

Each row below shows a claim and the links that prove it; click a link to see the proof on Stellar Expert, the public ledger explorer, or on the page it names. You do not need an account, a wallet or any software. Start with the checklist summary, which suggests a marking for each deliverable, then open that deliverable’s items to check them yourself.

How this snapshot was taken: Every on-chain link was re-read on 2026-09-30, after the Epic 5 frontend and backend deploys of 2026-09-29, from Stellar's public testnet record (Horizon, horizon-testnet.stellar.org). Each transaction was confirmed successful, and the date beside it is the day the ledger recorded it, in UTC. Contract activity was cross-checked on Stellar Expert. Every web link was opened without logging in and returned a working page. A wallet counts as the team's when it is in the team wallet register (backend repository, app/data/team_wallets.json) or holds a platform role on the contracts. The metrics were re-measured the same day by the backend's read-only generator (scripts/sow_metrics). An outside operator's agent ids, wallet and transaction hashes appear here only once that operator's consent to publish them is recorded. Nothing was signed, paid or submitted to make this snapshot.

Checklist summary (SOW §6.2)

For each deliverable, the Ambassador Chapter Lead marks the evidence Present, Partial or Missing. The Chapter Lead decides; this page only suggests a marking.

How the suggestion is worked out: If every item is present, the suggestion is Present. If at least one item is present or partial, it is Partial. If none is, it is Missing.

Suggested SOW §6.2 marking for each deliverable, worked out from its items below.
DeliverableSuggested markingItems
Deliverable 1: Permissionless Agent RegistrationPartial2 present, 1 partial, 0 missing (of 3)
Deliverable 2: Reputation-Gated RoutingPartial1 present, 1 partial, 1 missing (of 3)
Deliverable 3: Automated Dispute Window + Partial-Credit RefundMissing0 present, 0 partial, 3 missing (of 3)
Deliverable 4: Ecosystem Validation PackagePartial2 present, 1 partial, 2 missing (of 5)
Repositories & DeploymentsPresent6 present, 0 partial, 0 missing (of 6)

Evidence by deliverable (SOW §6.1)

Each deliverable as the SOW lists it: its evidence type and description, quoted, then each item with its status and proof.

Deliverable 1: Permissionless Agent Registration

Evidence type (SOW §6.1)
Repo PR(s) · live URL · tx hash
What the SOW asks for (§6.1, quoted)

“Merged PRs for the registration flow, the live "Register an Agent" URL on the deployed dApp, and an externally owned agent's registration tx hash on Stellar Expert (testnet).”

SOW v4, §6.1, Description
Suggested marking
Partial

  1. The registration flow is built and merged: the Register an Agent page, signing in the operator's own wallet, and the backend endpoints that build, check and list a registration.

    Status: Present

    Item 6.1-D1-a

    Note: The contract's register call was already open to any wallet. Story 1.01 audited it and needed no contract change, so there is no contracts pull request for this item.

  2. The Register an Agent page is live on the deployed app and opens without logging in.

    Status: Present

    Item 6.1-D1-b

  3. An agent registered by a wallet the team does not control, with its transaction on Stellar Expert.

    Status: Partial

    Item 6.1-D1-c

    Why: Partial. Outside wallets have registered agents: one outside operator's trial registration of one agent, and a second outside operator who registered five agents, all on 2026-09-29 (see Deliverable 4). No outside agent has a working endpoint, a dispatch or a settlement yet: the trial agent is bound to a parked web page, and the five are not bound to any endpoint. Their agent ids, wallets and registration hashes are held back from this index until each operator's consent to publish them is recorded; the platform's public ecosystem page, linked here, lists outside operators by design. The other 13 agents on the registry were registered by wallets the team controls, so none of them counts. The five team registrations linked here were signed by team keys other than the contract admin. They show that registering needs no permission from Orizon, but they are not outside operators. This item becomes present when an outside agent has a working endpoint and its registration can be linked with its operator's consent.

Deliverable 2: Reputation-Gated Routing

Evidence type (SOW §6.1)
Screen recording · screenshots · code link
What the SOW asks for (§6.1, quoted)

“A short recording/screenshots of the decompose plan card showing on-chain reputation per agent, plus a routing example where a sub-floor agent is excluded, and a link to the routing code.”

SOW v4, §6.1, Description
Suggested marking
Partial

  1. Screenshots or a recording of the plan card showing each agent's on-chain reputation before the buyer pays.

    Status: Partial

    Item 6.1-D2-a

    Why: Partial. A screenshot of the live plan card exists, taken on 2026-09-19. It shows a reputation score on every step and the 2.75 routing floor. But every agent in it still had the starting estimate (about 3.50 out of 5), not a score earned on-chain, because the platform only began writing ratings later that day. No recording exists yet. Since then the platform has written 33 ratings on-chain, two of which are linked here, so the live plan card now shows earned scores for rated agents. Those ratings came from live test runs whose payments did not settle (see the disclosures). A new screenshot or recording would make this item present.

  2. A routing example where an agent below the reputation floor is left out of the plan.

    Status: Missing

    Item 6.1-D2-b

    Why: Missing. No agent on the live registry is below the floor today, so there is no live exclusion to show. The lowest is the team's test agent uat624_ext_op, with an on-chain average of about 2.07 out of 5. But every agent starts from an estimate of 3.50, and a few small test ratings are not yet enough evidence to pull it under the 2.75 floor. The exclusion logic is merged and tested (the pull requests here, and the code in the next item). The only frame showing an exclusion so far used a plan written by a test, so it is not offered as evidence. This item becomes present with a recording of a live plan that leaves out a below-floor agent.

  3. A link to the routing code that applies the reputation floor.

    Status: Present

    Item 6.1-D2-c

    Note: The code links are pinned to the backend merge of 2026-09-18 (pull request #58), when this routing shipped. The floor check itself is unchanged in the later build the live API runs. The floor is judged on a cautious lower estimate of each agent's on-chain average, so a new agent with few ratings is not over-trusted or over-punished.

Deliverable 3: Automated Dispute Window + Partial-Credit Refund

Evidence type (SOW §6.1)
tx hash · screen recording
What the SOW asks for (§6.1, quoted)

“A dispute tx hash and the corresponding partial-refund tx on Stellar Expert (testnet), plus a recording of the dispute UI on the trace/receipt view.”

SOW v4, §6.1, Description
Suggested marking
Missing

  1. A dispute transaction on Stellar Expert: the negative on-chain rating written when a buyer's dispute is upheld.

    Status: Missing

    Item 6.1-D3-a

    Why: Missing. No dispute has been raised on the live deployment. A buyer can dispute a step only after its payment settles, and no payment has settled during the sprint (see the disclosure on how payment works). All 34 ratings on the live ReputationLedger are ordinary ratings; none is a dispute. The dispute path is merged (the pull requests here). A test run on a separate drill ledger proved the mechanism, but it is not offered as evidence (see the notes).

  2. The matching partial-refund transaction on Stellar Expert.

    Status: Missing

    Item 6.1-D3-b

    Why: Missing. No refund has been paid on the live deployment. There is nothing to refund yet, because no payment has settled, and refunds ship switched off until one does. A refund is a credit the platform sends from its own balance (see the disclosures). The 0.054 XLM transfer of 2026-09-12 that the Week-1 bundle showed as a refund was a test transfer and is not this evidence (see the corrections note).

  3. A recording of the dispute controls on the trace and receipt view.

    Status: Missing

    Item 6.1-D3-c

    Why: Missing. The Dispute button and the refund receipt are merged, but they appear only for a settled payment, and the live deployment has none, so no live recording can be made yet. The Week-3 bundle's dispute screenshots were taken on a local copy with test data. They show the design, not a live dispute, so they are not offered as evidence.

Deliverable 4: Ecosystem Validation Package

Evidence type (SOW §6.1)
Demo video · integration guide · tx-hash list
What the SOW asks for (§6.1, quoted)

“A 3–5 minute demo video (operator + buyer perspectives), the public "List your agent on Orizon" integration guide, and a list of ≥ 2 external registration tx hashes plus ≥ 3 settlement tx hashes on Stellar Expert (testnet).”

SOW v4, §6.1, Description
Suggested marking
Partial

  1. A 3–5 minute demo video showing both an operator and a buyer.

    Status: Missing

    Item 6.1-D4-a

    Why: Missing. The video has not been recorded. Its script is merged, and the public page that will host it, orizons.xyz/demo, is live but says the video has not been published yet. The video needs a working outside agent and settled payments to show, so it waits for those. The one-minute video in the frontend README predates the sprint and is not this video.

  2. The public "List your agent on Orizon" integration guide.

    Status: Present

    Item 6.1-D4-b

    Note: The guide is public at orizons.xyz/guide/list-your-agent, with every sample in it checked.

  3. At least 2 registration transactions by outside operators, on Stellar Expert.

    Status: Partial

    Item 6.1-D4-c

    Why: Partial. 2 outside operators have registered 6 agents, all on 2026-09-29, from wallets that are not in the team register and hold no platform role. That is more than the 2 registrations asked for, but the transactions are not listed here yet. The first operator's is a trial registration of a single agent, bound to a server address that is a parked web page, not a working agent. A second outside operator registered five agents, none bound to an endpoint yet. None of the six has had a dispatch or a settlement. The platform's own readiness check reports the trial agent ready only because that check accepts any page that answers. Their agent ids, wallets and registration hashes are held back from this index until each operator's consent to publish them is recorded, so the transactions are not linked. The platform's public ecosystem page, linked here, lists outside operators by design. The live adoption counter counts 6 outside agents and 2 outside operator wallets, which meets both targets, and 0 settled outside workflows against a target of 3 (see metrics 1 to 3).

  4. At least 3 settlement transactions on Stellar Expert, each with its on-chain receipt and attestation.

    Status: Missing

    Item 6.1-D4-d

    Why: Missing: 0 of 3. No payment has settled on the live escrow during the sprint, and no workflow has been sealed. The deployed PaymentEscrow cannot move a buyer's funds to a different wallet (defect D-039, found in QA), so none of the payment authorizations made since 2026-09-07 has been charged (the escrow has issued 30 authorizations in all, as of 2026-09-30). The escrow's Events tab does show 8 'charged' events, but all are from May and June 2026, before the sprint, and in each the team's admin wallet paid itself. They do not count (see the notes). A fixed escrow, v2, is merged in the contracts repository and the live backend can settle through it, but the v2 contract is not yet deployed to testnet.

  5. The protocol litepaper, with its §6 updated for open registration, public on orizons.xyz (SOW §5.1, Week 4 output).

    Status: Present

    Item 6.1-D4-e

    Note: Version 0.5 of the litepaper is written, with §6 updated for open registration, reputation-gated routing and the dispute window, and every format is regenerated from its source. The page offers the litepaper as a PDF, a web page, a Word document and Markdown, with no account needed.

Repositories & Deployments

Evidence type (SOW §6.1)
GitHub repos · live deployments · on-chain proofs
What the SOW asks for (§6.1, quoted)

“GitHub repositories (all MIT): frontend github.com/ALGOREX-PH/Orizon-Agents-FE-Stellar, backend github.com/ALGOREX-PH/Orizon-Agents-BE-Stellar, contracts github.com/ALGOREX-PH/Orizon-Agents-Smart-Contract-Stellar. Deployments: dApp orizons.xyz, API orizon-agents-be-stellar.onrender.com. On-chain proofs: every registration, settlement, and attestation is viewable on Stellar Expert (testnet) under the four live contract IDs.”

SOW v4, §6.1, Description
Suggested marking
Present

  1. Frontend source code is public on GitHub and released under the MIT licence.

    Status: Present

    Item 6.1-RD-a

    Note: The repository is public, and GitHub detects its MIT licence. The SOW's address on github.com/ALGOREX-PH redirects to this repository.

  2. Backend source code is public on GitHub and released under the MIT licence.

    Status: Present

    Item 6.1-RD-b

    Note: The repository is public, and GitHub detects its MIT licence. The SOW's address on github.com/ALGOREX-PH redirects to this repository.

  3. Smart-contract source code is public on GitHub and released under the MIT licence.

    Status: Present

    Item 6.1-RD-c

    Note: The repository is public, and GitHub detects its MIT licence. The SOW's address on github.com/ALGOREX-PH redirects to this repository.

  4. The dApp is live at orizons.xyz and runs on Stellar testnet.

    Status: Present

    Item 6.1-RD-d

    Note: orizons.xyz points at testnet for this sprint and is due to switch back to mainnet afterwards, so a visit after the sprint may show mainnet (see the notes).

  5. The API is live at orizon-agents-be-stellar.onrender.com and reports testnet.

    Status: Present

    Item 6.1-RD-e

    Note: The API runs on a free plan, so the first request can take up to a minute while it wakes. It is updated by a manual deploy and was last deployed on 2026-09-29 (see the notes).

  6. Every registration, settlement and attestation is viewable on Stellar Expert (testnet) under the four live contract IDs.

    Status: Present

    Item 6.1-RD-f

    Note: These four contracts are the live set the API reports. Each contract page has an Events tab that lists everything it has recorded. They show real activity, but no settlement or attestation from the sprint yet (see Deliverable 4). A fifth contract, escrow v2, is merged but not deployed.

Success metrics (SOW §6.3)

6 of 11 met.

Each target is the SOW’s own. Where a target was missed, the reason is given in its row.

SOW §6.3 success metrics: 6 of 11 met. Target, achieved value, status and proof for each.
MetricTargetAchievedStatusProof
Adoption targetsExternally-operated agents registered on Testnet≥ 2
6How measured: Read every agent the AgentRegistry contract lists, with its owner, straight from testnet. An agent counts only if its owner is neither one of the team's wallets (the committed register) nor a key the platform runs (network admin, dispatch signer, ratings signer and scorer, registry admin, escrow settler and admin, ledger scorer, attestation sealer).
Met

Met on registrations, which is what the SOW counts: 6 agents registered from 2 outside operators' wallets. No external agent is bound to a working endpoint: one outside operator's single agent is bound to a parked web page, the other operator's five agents are not bound to any endpoint yet, and none has run or settled (see metric 3). Their ids and registration hashes are held back here until each operator's consent to publish them is recorded.

Adoption targetsUnique external operator wallet addresses≥ 2
2How measured: The distinct owner wallets of the registered agents, each checked the same way as the row above. A wallet counts only if it is neither one of the team's wallets (the committed register) nor a key the platform runs (network admin, dispatch signer, ratings signer and scorer, registry admin, escrow settler and admin, ledger scorer, attestation sealer).
Met

Met on registrations, which is what the SOW counts: 2 outside operators' wallets own agents, one owning 1 agent and the other 5. No external agent is bound to a working endpoint: one outside operator's single agent is bound to a parked web page, the other operator's five agents are not bound to any endpoint yet, and none has run or settled (see metric 3). Their addresses are held back here until each operator's consent to publish them is recorded.

Transaction targetsWorkflows routed to external agents & settled on Testnet≥ 3
0How measured: Walked every id each escrow contract has issued (its id counter numbers every authorization and receipt, so this does not depend on how long the network keeps events) and read each receipt and the payer that authorized it. A v1 charge and each payout of a v2 settle count as one charge. A charge is excluded when it is a self-payment (the payer owns the agent, is the escrow's settler, or is a platform key) or settled before the sprint began on 2026-09-07. Testnet settles in native XLM, not USDC: the escrow's payment asset is the native XLM asset contract. A workflow counts when at least one of its counted charges paid an agent run by an outside operator; several charges of one job are one workflow.
Not met

Why: 6 agents owned by outside operators are registered, but none is bound to a working endpoint, and no workflow paid to one has settled since the sprint began on 2026-09-07.

Transaction targetsOn-chain USDC settlements (charges) recorded≥ 3
0 (the escrow's 8 older 'charged' events do not count)How measured: Walked every id each escrow contract has issued (its id counter numbers every authorization and receipt, so this does not depend on how long the network keeps events) and read each receipt and the payer that authorized it. A v1 charge and each payout of a v2 settle count as one charge. A charge is excluded when it is a self-payment (the payer owns the agent, is the escrow's settler, or is a platform key) or settled before the sprint began on 2026-09-07. Testnet settles in native XLM, not USDC: the escrow's payment asset is the native XLM asset contract.
Not met

Why: None of the 8 charges on record counts: all 8 were the agent's owner paying itself and all 8 were settled before the sprint began (2026-05-13 to 2026-06-09). No payment from a buyer to a different agent owner has settled since the sprint began.

Transaction targetsDispute → partial-refund settlements≥ 1
0How measured: Read the dispute ratings the platform wrote to the ReputationLedger (from its keys' full transaction history) and traced each back, through the derived job id the backend records a dispute under, to the charge it disputes. A refund counts only when that charge counts and the platform then paid its payer back over the asset contract, no more than the charge. A transfer with no dispute behind it (such as a refund drill) does not count. The ledger's lifetime dispute count for every agent is read as a cross-check.
Not met

Why: No dispute has been refunded yet. The reputation ledger holds 34 ratings (34 of kind auto) and no dispute rating; its lifetime dispute count is 0 across all 19 agents. No charge has settled since the sprint began on 2026-09-07 that a dispute could refund. The only transfer out of a platform key on record, on 2026-09-12, went to a team key with no dispute behind it.

Technical milestonesPermissionless AgentRegistry.register flow live on the dAppYes
Yes: the Register page is live and open to any wallet. Two outside wallets have registered agents (see metric 1).How measured: Opened the /app/register page on the live dApp with no login, and checked the live backend publishes the route that builds an unsigned registration transaction for the owner's own wallet to sign. The registry contract's register needs only the owner's signature, no admin.
Met
Technical milestonesReputation-gated routing (reads avg_bps, applies a floor) liveYes
Yes: the planner reads each agent's on-chain reputation and applies a floor of 2.75 out of 5. No agent is below the floor today, so no live exclusion can be shown (see Deliverable 2).How measured: Read the live reputation settings the router applies (whether the floor is on, and its value) from the deployed API. The router scores each agent from the ReputationLedger's on-chain average and leaves out any agent below the floor.
Met
Technical milestonesAutomated dispute window + partial-credit refund liveYes
Partly: the dispute routes are deployed, but no dispute window can open until a payment settles, which needs escrow v2, and refunds are switched off.How measured: Checked that the live backend publishes the dispute routes (open, read, uphold, reject); that a dispute window can open at all, which needs a settled payment, and so the escrow v2 contract live; that its readiness report shows refunds switched on (disputes.reconcile.enabled, true only when refunds and the refund sweep are both on); and that at least one dispute has been refunded on-chain (the dispute refund row above). Yes when all hold, Partly when the routes are deployed but the rest does not, and No when the routes are not.
Not met

Why: No dispute window can open until a payment settles, which needs escrow v2, and refunds are switched off.

Technical milestonesPublic "List your agent on Orizon" integration guide publishedYes
YesHow measured: Opened the /guide/list-your-agent page on the live dApp with no login; published means it answers there.
Met
Technical milestones3–5 min demo video publishedYes
NoHow measured: Opened the /demo page on the live dApp with no login and read the published marker the page renders (data-demo="published") and the video's running time, which must be 3 to 5 minutes.
Not met

Why: The /demo page is live but says the video has not been published yet.

Technical milestonesAll source code released under MIT LicenseYes
YesHow measured: Asked GitHub which licence it detects on each repository: the frontend, backend and smart contracts the SOW names, and the example agent. Each must be MIT.
Met

Disclosures

The limits of what this evidence shows, stated plainly.

  • Testnet only

    SOW §3.6: "Testnet: all Instaward work is built and validated on Stellar testnet for this sprint — no mainnet funds are at risk. Orizon's contracts are also deployed on Stellar mainnet outside this award; none of that deployment is funded by, or in scope for, this Instaward." Every Stellar Expert link in this index points at the testnet explorer. Testnet money has no real value.

    SOW reference: §3.6

  • Anyone can register; payment is still run by the platform

    SOW §3.8: "Deliverable 1 makes registration permissionless; it does not make settlement permissionless." Any wallet can register an agent without asking Orizon. Paying agents, writing ratings and deciding disputes are still done by keys the platform holds.

    SOW reference: §3.8

  • Payments are released by a single platform key

    SOW §3.8: "the settler is not permissionless. The settler (the role that executes charge and will operate this sprint's dispute/partial-credit path) is a single platform-held backend key, fixed at contract deployment; the contract exposes no settler-rotation function." This is still true of the live escrow: one team-held key releases payments, with no multi-signature or threshold control.

    SOW reference: §3.8

    Changed since the SOW: Two changes. First, the SOW says one keypair also holds the admin, scorer and sealer roles. On 2026-09-19 the rating (scorer) and sealing (sealer) roles moved from the admin wallet GA7AI…5OQV to a separate production key, GDB4N…CDHP; the two transactions are linked under Repositories & Deployments. The admin wallet still holds the admin role and is the settler on the live (v1) escrow. The dispute credit is not paid by that settler: the production key GDB4N…CDHP pays it, and that key becomes the escrow's settler once escrow v2 is deployed. Both keys are held by the team. Second, escrow v2 adds a set_settler function, so the settler can be replaced. v2 is merged (contracts pull request #4, 2026-09-28) but not deployed to testnet, so the live escrow still cannot rotate its settler.

  • How payment works, and why no payment has settled

    SOW §3.8: "the settler executes charge, which moves USDC directly from the buyer to the agent owner's wallet through the Stellar Asset Contract, the platform never takes custody of funds." On the live escrow (v1) this does not work: charge cannot move funds from a buyer who is not also the settler (defect D-039, contracts issue #3). No payment between two different wallets has ever settled on it.

    SOW reference: §3.8

    Changed since the SOW: Escrow v2 fixes this by holding the buyer's authorized amount from the moment the buyer authorizes, then paying each operator at settlement. That means the platform's contract does hold funds for a while, which changes the SOW's "never takes custody" statement. v2 is merged in the contracts repository (pull request #4), and the backend deployed on 2026-09-29 can settle through it (pull request #88), but the v2 contract is not deployed to testnet.

  • Refunds are credits paid from the platform's own funds

    When a dispute is upheld, the platform sends the buyer a credit from its own balance. It is not taken back from the agent's owner, and it is not drawn from the buyer's authorization. The platform's signing key (GDB4N…CDHP) pays dispute credits, writes ratings and seals attestations, and it becomes the escrow's settler once escrow v2 is deployed. The deployed v1 escrow's settler is the admin key (GA7AI…5OQV). The credit is the price of the disputed step, capped by what the payment actually moved. A credit above the per-refund ceiling (MAX_REFUND_USDC) is refused outright, not reduced to the ceiling, and nothing is paid. Refunds ship switched off, and none has been paid on the live deployment.

    SOW reference: §3.8, §4.1 (Deliverable 3)

    Changed since the SOW: The SOW says the refund is executed by the settler "within the buyer's envelope" (§3.8) and "against the buyer's authorization envelope" (§4.1). The live escrow has no refund function and never holds funds, so there was nothing inside the envelope to return. The refund became a separate transfer funded by the platform (backend decision records ADR 0002 and ADR 0008).

  • An agent's server address is stored off-chain

    The on-chain agent record holds its owner, id, name, skills and price. It has no field for the address of the operator's server. The operator links that address to their agent in Orizon's database, proving they own the agent by signing a message with the owner wallet (backend decision record ADR 0001). So where Orizon sends an agent's work is decided by Orizon's database, not by the chain.

    Changed since the SOW: Not in the SOW. It was chosen in Week 1 (decision spike 1.06) instead of redeploying the registry, which would have changed the published contract addresses.

  • Ratings and dispute decisions are made by the platform

    SOW §3.8: "reputation ratings can only be submitted by the platform's scorer key. Settlement, rating submission, and dispute resolution are therefore trusted, permissioned operations today." This is still true. Only the platform's production key writes ratings, and disputes are decided by the platform's operator.

    SOW reference: §3.8

    Changed since the SOW: The SOW says a rating is recorded once per settled job. The platform now rates every paid run whether or not its payment settles, so that failed deliveries are also recorded (backend pull request #57). The 33 ratings written during the sprint all come from runs whose payment did not settle.

Notes

  • How to read the links

    Stellar Expert (stellar.expert) is a free public website that shows everything recorded on the Stellar network. A transaction link opens one recorded action, with its date and a 'Successful' mark. A contract link opens a program on the network; its Events tab lists everything it has recorded. An account link opens a wallet and its history. Every such link here uses the testnet explorer. GitHub pull request links show 'Merged' or 'Open' at the top of the page. Nothing needs a login.

  • USDC in the SOW, XLM on testnet

    The SOW describes payments in USDC. On testnet, Orizon's escrow is set up with Stellar's native asset, XLM, through its standard asset contract (CDLZF…GCYSC). So every payment and refund amount in this index is in testnet XLM. The code does not depend on the asset; metric 4 is measured on that basis.

  • How an outside operator is told apart from the team

    The team keeps a public register of every wallet it controls, in the backend repository (app/data/team_wallets.json). An agent counts as outside only when its owner is not in that register and holds no platform role. 13 of the 19 registrations so far are by team wallets, and each is labelled that way here. The other 6, all on 2026-09-29, are by 2 outside operators: one operator's trial agent, bound to a parked web page, and a second operator's five agents, not yet bound to any endpoint (see Deliverable 4).

  • The 8 'charged' events on the escrow do not count

    The live PaymentEscrow's Events tab shows 8 'charged' events and the AttestationRegistry shows 8 seals. All 16 are from 2026-05-13 to 2026-06-09, months before the sprint began on 2026-09-07. In each, the team's admin wallet was the buyer, the settler and the agent's owner, so it paid itself and no money changed hands. They are linked under metric 4 so you can check them, and they are not counted toward any target.

  • Corrections to evidence submitted earlier

    1. The Week-1 bundle presented transaction 9b8ffaa4…9a68 (2026-09-12, 0.054 XLM) as "a real refund landed on testnet", and a backend record called it the SOW §6.1 Deliverable 3 artifact. It was a test transfer from the admin wallet to a team key (GBI2I…ADBH), tied to no dispute and no payment. It shows only that the platform key can send a transfer. It is not Deliverable 3 evidence. 2. The Week-1 bundle marked Deliverable 1 as met using two registrations: dan_w1_probe, signed by the team's admin wallet, and sign_probe_bb5c12, signed by a team probe key. Both are team wallets, so neither is the externally owned registration Deliverable 1 asks for. 3. The Week-1 bundle said the refund record was on the backend's main branch. It was removed on 2026-09-22 (backend pull request #42), so that link no longer works. 4. The Week-2 technical document called the 40-second Week-2 build clip on X a demo video. It is a build update, not the 3–5 minute demo the SOW asks for.

  • Test runs are not deliverable evidence

    QA proved the dispute path by running the real backend against a separate drill ReputationLedger (CAFZB…5CRP) and a test asset (CCW66…GUENL), signed by a QA drill key (GA45I…EGZ2), on 2026-09-25 and 2026-09-26. Those transactions are real, but they are a mechanism test on a separate drill ledger, not deliverable evidence, so none is linked here. Likewise, the only frame that shows the reputation floor excluding an agent (QA frame RF-17) used a plan written by the test.

  • Targets come from SOW v4

    An earlier SOW, v3 (2026-06-11), set lower targets: at least 1 outside agent, 1 outside wallet and 2 settled workflows. The approved v4 (2026-08-01) raised them to 2, 2 and 3. This index measures against v4. Today they stand at 6, 2 and 0, which meets the first two v4 targets and misses the third. The first two count registrations only: no outside agent is bound to a working endpoint yet (see Deliverable 4).

  • Repository addresses

    The SOW names the repositories under github.com/ALGOREX-PH. They moved to the Bl0cksmiths organisation, and the old addresses redirect to the new ones, so this index links the new addresses directly.

  • The live API is updated by hand

    The live API on Render does not update itself when code merges; the team deploys it by hand. It was last deployed on 2026-09-29, with everything merged to the backend's main branch up to pull request #94, including the adoption counter (backend pull request #89). Settlement through escrow v2 (backend pull request #88) is in that build but cannot run yet: the escrow v2 contract is not deployed to testnet, so the live escrow is still v1. No merged backend work is waiting for a deploy.

  • orizons.xyz switches back to mainnet after the sprint

    For this sprint orizons.xyz was switched to Stellar testnet. After the sprint it is due to switch back to mainnet. This index is a snapshot of 2026-09-30; if the site shows mainnet when you open it, the testnet evidence here is still on the testnet explorer links.

  • How long testnet keeps this evidence

    Stellar's testnet was last reset on 2025-12-17, and its public record keeps full history since then, so every link here still opens. The Stellar Development Foundation resets testnet from time to time. A reset would erase this history, and the links would stop working.

Where else to look

  • List your agent on Orizon — the public operator guide, step by step, readable with no account.
  • Demo — the demo video page, and how to verify each deliverable yourself.
  • Ecosystem — who runs agents on Orizon besides the team, read from the chain.
  • Litepaper — the protocol litepaper, with §6 updated for open registration, to read or download.
  • Frontend source code (opens GitHub) — the repository on GitHub.
  • Backend source code (opens GitHub) — the repository on GitHub.
  • Smart contracts source code (opens GitHub) — the repository on GitHub.