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-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. 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, 0 partial, 1 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 PackagePartial0 present, 2 partial, 3 missing (of 5)
Repositories & DeploymentsPartial3 present, 3 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: Missing

    Item 6.1-D1-c

    Why: Missing. No outside operator has registered an agent yet. All 12 agents on the registry were registered by wallets the team controls, so none of them counts. The five 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 developer registers from their own wallet on orizons.xyz/app/register.

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 27 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 28 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 and the public /demo page that will host it are in frontend pull request #97, which is open and not deployed, so orizons.xyz/demo shows 'not found' until it merges. The video needs a real outside registration 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: Partial

    Item 6.1-D4-b

    Why: Partial. The guide is written, and every sample in it was checked, in frontend pull request #97. That pull request is open, so the public page (orizons.xyz/guide/list-your-agent) shows 'not found' today. It goes live when #97 merges to main and Vercel redeploys the site.

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

    Status: Missing

    Item 6.1-D4-c

    Why: Missing: 0 of 2. No outside operator has registered an agent yet (see metric 1). The adoption counter that lists outside registrations is merged in backend pull request #89 but not deployed, so its public address (/api/ecosystem/adoption) does not work yet. It goes live with the next manual backend deploy on Render.

  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 all 37 payment authorizations made since 2026-09-07 were left uncharged. 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 and backend repositories but 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: Partial

    Item 6.1-D4-e

    Why: Partial. 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. Its public page, orizons.xyz/litepaper, is in frontend pull request #97, which is open, so the page shows 'not found' today. It goes live when that pull request merges to main and Vercel redeploys the site. Until then, the PDF and the updated §6 are linked here on GitHub. 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
Partial

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

    Status: Partial

    Item 6.1-RD-a

    Why: Partial. The repository is public, but it has no licence file yet, so GitHub shows no licence. The MIT licence is added by the open pull request linked here. 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: Partial

    Item 6.1-RD-b

    Why: Partial. The repository is public, but it has no licence file yet, so GitHub shows no licence. The MIT licence is added by the open pull request linked here. 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: Partial

    Item 6.1-RD-c

    Why: Partial. The repository is public, but it has no licence file yet, so GitHub shows no licence. Its Cargo.toml says MIT, but only as package metadata, which GitHub does not count. The MIT licence is added by the open pull request linked here. 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 currently runs a build from before 2026-09-25 (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)

2 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: 2 of 11 met. Target, achieved value, status and proof for each.
MetricTargetAchievedStatusProof
Adoption targetsExternally-operated agents registered on Testnet≥ 2
0How 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).
Not met

Why: No outside operator has registered an agent yet; all 12 registered agents belong to 4 wallets the team controls.

Adoption targetsUnique external operator wallet addresses≥ 2
0How 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).
Not met

Why: No outside operator wallet owns an agent yet; the 12 registered agents belong to 4 wallets the team controls.

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: No agent run by an outside operator exists yet, so no workflow could be routed to one and settled. None of the 8 charges on record paid one.

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 28 ratings (28 of kind auto) and no dispute rating; its lifetime dispute count is 0 across all 12 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. No outside wallet has used it yet (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 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).
Not met

Why: The dispute routes are deployed, but a buyer's 24-hour dispute window opens only when a payment settles, and none has: settling a payment needs escrow v2, which is merged but not deployed. The live backend does not report refunds as switched on (its readiness report predates the refund switch), and no dispute has been refunded on-chain (see the dispute refund row).

Technical milestonesPublic "List your agent on Orizon" integration guide publishedYes
No: the guide page is not live yetHow measured: Opened the /guide/list-your-agent page on the live dApp with no login; published means it answers there.
Not met

Why: The /guide/list-your-agent page answers HTTP 404: it has not been deployed yet.

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 answers HTTP 404: it has not been deployed yet.

Technical milestonesAll source code released under MIT LicenseYes
No: 1 of 4 public code repositories has an MIT licence fileHow 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.
Not met

Why: 3 of the 4 repositories have no MIT licence that GitHub recognises: the frontend (no licence detected), the backend (no licence detected) and the smart contracts (no licence detected).

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 (pull request #4) and backend (pull request #88) repositories but 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 27 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. Every registration so far is by a team wallet, and each is labelled that way here.

  • 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 all three stand at 0, which misses either version.

  • 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 currently runs a build from before 2026-09-25. Merged work waiting for the next deploy includes settlement through escrow v2 (backend pull request #88) and the adoption counter (backend pull request #89).

  • 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-29; 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.