Roundhouse AI

‍

‍BROKER NOTE BY JONATHAN PLANT

September 2026

‍

Core proposition: Roundhouse AI is being funded via the proposed £1.5m Build Stage raise to prove whether it can become the trusted data and scoring layer for autonomous-agent activity. The immediate ask is not to buy a finished revenue story; it is to fund the proof window for a potentially important market-infrastructure position.

‍

[This note is intended for release after the relevant transaction announcement and should be read alongside the deal deck / placing materials].

‍

Cover framing: The valuation should be read as a conditional 12–18 month range, not a single-point target. The Proliferation case implies a broad c.12p–31p range, with 20p used as a sensible midpoint reference if POC delivery, AIM progress, early score/API traction, partner validation and Commercialisation Stage financing improve the evidence base. A higher 40p-plus style outcome should be discussed only as a success case: Roundhouse would need to move beyond Proliferation toward accepted trust-source status, with credible score/API usage, enterprise scoring/index contracts, premium aGDP demand and controlled dilution.

‍

How to read this note: Roundhouse AI is pursuing a four-layer architecture comprising the x402 Facilitator, Indexed Reputation Graph, Agent Reputation Scores and the aGDP Index.

This is the long-form investment note supporting the proposed transaction. The note should be read as a milestone-led framework for assessing whether Roundhouse can move from Build Stage (proof of concept POC, AIM listing) through Go-to-Market (dashboard goes Live & First revenue)  to a Commercialization stage (Score API full launch, aGDP Index & EU expansion)

‍

Company description: ETHL / Roundhouse AI is an Aquis-listed technology company repositioned around AI infrastructure for autonomous-agent activity. The Company is no longer being evaluated as an Ethereum-treasury or DATCO-style strategy and should instead be assessed against delivery of its proposed trust, scoring and data architecture for the agent economy.

‍

Quick-read extract: the core investment case

One-line thesis: Roundhouse AI is a listed option on becoming the trust, scoring and system-of-record layer for autonomous-agent activity.^E1 Its target role is the record of who acted, under whose authority, against which endpoint, with what payment proof and with what outcome.^{D2, G1}

The simple version: AI agents are beginning to move from answering questions to doing things: they can call APIs, access software, retrieve data and initiate payments.^{B1, C1} Once agents act at scale for users or organisations, the market needs a trusted evidence layer showing whether an agent was authorised, whether the action was genuine, whether the counterparty was legitimate and whether the outcome can be audited.^{D1, D2}

In plain terms: Roundhouse is trying to observe agent activity, turn that activity into a reliable evidence record, score the trustworthiness of that activity, and package the resulting data for counterparties that need to manage risk.^{B1, B2, D1, D2}

‍

‍

The four-layer model

1. x402 Facilitator: the payment and data-intake layer. It helps agent payments happen and gives Roundhouse visibility over who paid, what was accessed and which activity may be worth recording.^{B1, B2}
2. Indexed Reputation Graph: the evidence record. It organises agent activity into a structured record of agents, users or principals, endpoints, counterparties, payments and outcomes, so the market can distinguish useful activity from noise.^{B3, D2}
3. Agent Reputation Scores: the decision signal. These are intended to help platforms, enterprises or infrastructure providers decide whether to allow, block, price, review or investigate an agent action.^{D1, E1}
4. aGDP Index: the market-data layer. If machine-led activity becomes economically meaningful, institutions may want cleaned data on where agent transactions are happening, which categories are growing and whether the activity is real or experimental.^{F7, F8}

‍

How Roundhouse turns agent activity into revenue

The commercial logic is deliberately staged: Roundhouse should not be valued as if all revenue arrives immediately. The first job is to prove that the rails can observe useful activity; the second is to turn that activity into a trusted data asset; the third is to sell decision-useful scores and premium data once counterparties have a reason to trust the record.

‍

In simple staging terms: The Build Stage funds the first proof window; the Go-to-Market Stage is where Roundhouse needs data-infrastructure and distribution validation and will look for partners; the Commercialisation Stage should only become an expansion raise if the proof base is strong enough to justify higher expert costs in engineering, data infrastructure, security, compliance, partnerships and enterprise delivery.

‍

‍

What the current raise is intended to prove

The proposed £1.5m Build Stage raise should be presented as proof capital, not growth capital. The working split is £800k for POC / working prototype, £350k for AIM listing costs and £350k for marketing, partnerships and protocol integrations. Investors should judge the raise by visible proof points: live rails, useful telemetry — meaning observable activity data from agents, payments, endpoints and outcomes — dashboard delivery, design partners, score/API proof and evidence that the graph can separate useful activity from noise.^I3

‍

Valuation framing

A single-point target is the wrong way to read Roundhouse. The cleaner framework is milestone-led and dilution-sensitive. The current price should be treated as a funded option on proof.^I5 A c.20p reference case belongs in the Proliferation scenario of a 12-31p milestone-led range, where the POC works, AIM progress is visible, score/API traction begins and Commercialisation Stage capital can be raised on better evidence.^I3 A 40p-plus style outcome should be discussed only as a Moat case, where Roundhouse begins to look like an accepted trust source rather than a dashboard or early-stage tool. See the full valuation framework in Section 9.^H2

‍

Why this extract exists

This extract is designed to let investors absorb the core case quickly before entering the full diligence note. It can also stand as the content base for a shorter investor-facing version where a concise note is more appropriate than the full evidence pack.^I3 It is a summary only and should be read together with the full note, including the assumptions, risks, valuation framework and source notes.^{H1, H2}

‍

1. Investment summary

Section hook: This section answers the investor’s first question: what is the investment case, what is Roundhouse trying to become, and why does the raise matter now?

Roundhouse AI is being positioned as a listed infrastructure play on the emerging agent economy. The central investment question is whether the Company can become the trusted data and scoring layer for autonomous-agent activity: recording what agents do, building a reputation graph from that activity, and later selling decision-useful scores and machine-economic data to counterparties that need to manage agent risk.

The model is deliberately narrow. The first two layers — the x402 Facilitator and Indexed Reputation Graph — are the data-capture wedge. The second two — Agent Reputation Scores and the aGDP Index — are the first planned commercial products. That is the discipline of the note: prove the rails and graph first, then commercialise scoring and premium data after the Commercialisation Stage. Later product extensions sit in the appendix as valuation sensitivity, not in the base investment case.

The Company’s investor materials have used a Bloomberg-style comparison to describe the role Roundhouse hopes to play in the agent economy. That comparison should be used carefully. It is not a product-suite comparison and should not imply that Roundhouse is building a Terminal, media business or Bloomberg-style bundle today. It is a market-position analogy: Bloomberg became valuable because market participants trusted it as a neutral reference source. Roundhouse is attempting a much earlier, much riskier version of that idea for agent trust and autonomous economic activity. x402 facilitators are described as payment-verification and settlement infrastructure for agent payments.^{B1, B2} Market commentary around x402, ERC-8004 and agent trust also shows a developing need for identity, reputation, verification and trusted machine-to-machine settlement infrastructure.^J6

This is therefore a staged infrastructure financing, not a normal small-cap SaaS story. Near-term value should be judged by proof of useful telemetry, repeat facilitator activity, graph quality, partner validation and evidence that customers will pay for trust scoring or machine-economic data. Revenue is deliberately back-ended into the Commercialisation Stage, when score/API, enterprise scoring/index contracts and aGDP premium data are expected to become sellable products.

The deeper research, references and analogies throughout the note support strategic direction, category formation and long-term upside. They do not change the base-case model, which remains limited to the four-layer architecture and commercialisation of scoring and index products.

Artificial intelligence (AI) agents are moving from passive tools into active economic actors. They can retrieve data, call APIs, access software, initiate payments and use Model Context Protocol (MCP) tools.^{B1, C1} They can also commission services, trade assets and perform high-value tasks on behalf of individuals, companies and institutions.^F1 The category is large enough to feature prominently in investor and sales materials, with one market forecast putting the AI agents market at US$52.62bn by 2030.^A4 That top-down TAM should be treated as context rather than proof of Roundhouse demand. As this shift gathers momentum, the market’s limiting question changes from whether an AI model can produce a useful answer to whether an agent can be trusted to act.^{A1, A3}

For every buyer, merchant, lender, insurer, exchange, marketplace, regulator, enterprise-risk function and infrastructure provider, the emerging question is simple but difficult: Can this agent be trusted to perform this action, under this authority, in this context?

Roundhouse AI’s proposed answer is a trust, scoring and data architecture for autonomous economic activity. The core pathway is: free facilitator adoption creates settlement data; indexed settlement data creates the reputation graph; the reputation graph supports agent scoring; and the recognised scoring and activity dataset can then support institutional index and data products.

The investment case is not that agent payments alone create a large market. The stronger case is that any meaningful agent economy will require a system of record for who acted, under whose authority, against which endpoint, with what payment proof, using which model or tool, and with what outcome. That is the missing infrastructure layer the Company is attempting to own.^{D2, E1, G1}

‍

2. Company Context and Investor Framing

Section hook: This section orients the reader around the company set-up, the move away from the Ethereum-treasury frame, and the staged investor logic behind the proposed raise.

Roundhouse AI Ltd is an Aquis-listed technology company that has moved away from its earlier Ethereum-treasury context and is now being positioned as an AI infrastructure company for the agent economy. The investor case should therefore be assessed around operational execution, product proof, data capture and staged financing rather than treasury exposure. The move to AIM should widen the investor reach.^{I4, I5, I6}

The Company is presenting a clean Build Stage / Go-to-Market Stage / Commercialisation Stage path. The Build Stage is the live / shipping facilitator and graph foundation. Go-to-Market is partner and distribution validation, alongside build and testing of the first Agent Reputation Score API. The Commercialisaton Stage is the funded commercial launch of Agent Reputation Scores and the aGDP Index. The important fundraising point is that Commercialisation Stage should be evidence-triggered rather than calendar-led.

That framing keeps the investor conversation honest. The question is not whether Roundhouse can monetise a wide product suite in year one. It is whether the free facilitator can capture differentiated agent-settlement data, whether the graph becomes a trusted reference dataset, and whether counterparties will pay to query scoring and machine-economic intelligence once the Commercialisation Stage products are live.

The Bloomberg reference is therefore best treated as a sequencing analogy sourced from Company materials: first establish trusted infrastructure, then monetise scoring and data products, with any broader workflow or media layer treated only as later optionality. The relevant point is that a neutral reference layer can become valuable when market participants need a common source of truth before they transact, rank, price, insure, audit or allocate capital.

The model leaves room for later product expansion but does not rely on it. Workflow, media/research and merchant/service scoring can be considered in the appendix only after the reader accepts the Y2 commercial evidence case. The base note is intentionally narrower: prove a credible route to scoring dominance and trusted data-reference status first.

‍

2.1 Team capability and operational fit

The team presentation is important because the investment case is operational rather than purely financial-engineering led. Roundhouse should not be framed as a DATCO-style model whose primary investment appeal is balance-sheet exposure to digital assets. The stronger case is that the team has been working at the intersection of agentic AI, crypto infrastructure, public markets and deployment tooling, and that those skills map directly onto the four-layer trust, scoring and data architecture.

For investors, execution credibility matters as much as the idea. The first raise has to buy enough delivery to show live rails, useful telemetry, a credible graph, partner engagement and a ommercialisation financing story that can be priced on evidence rather than aspiration.

‍

2.2 Management and execution pedigree

The management case is important because Roundhouse is still at concept-to-proof stage. Investors are being asked to fund a thesis that depends on the team’s ability to combine public-market execution, digital-asset infrastructure, AI product positioning, enterprise relationships and staged capital formation. Public Company materials present the board and management as having experience across technology company-building, digital assets, Asia-based capital formation, finance, governance and enterprise operations.^{K1, K2}

The relevant question is not whether the team has already commercialised this exact four-layer product. The relevant question is whether their career base plausibly fits the required execution path: raise proof capital, build working rails, secure partner validation, create a public-market platform, and then raise Commercialisation Stage acceleration capital if the graph and scoring logic show traction.^{K1, I3}

Management pedigree: Roundhouse’s investor materials present a team with public-market, digital-asset, technology-building and execution experience relevant to the proposed four-layer agent-trust architecture.

‍

3. The Problem: Agents Can Act, but the Market Cannot Yet Trust Them

Section hook: This section defines the pain point: agents can act, pay and call services, but the market still lacks an evidence layer for authority, provenance, behaviour and outcome.

The current internet and enterprise software stack was built around human users, employee accounts, API keys, cookies, IP addresses, passwords, payment cards and manual approvals. It was not designed for autonomous agents acting across tools, services and payment rails at machine speed.

‍

3.1 Identity is necessary but not sufficient

Knowing that an agent exists or has a credential does not prove that it is authorised to perform a specific action. The central issue is delegated authority: whose authority is the agent acting under, what is the scope of that authority, when does it expire, and who is accountable if the agent exceeds the mandate?^{D1, D2}

This distinction matters in compliance, payments, capital markets, enterprise AI and public-sector deployments. An agent that can access a dataset, initiate a payment, send information externally or interact with trading infrastructure needs more than a login token. It needs action-scoped permissioning and evidence.^{D1, F1}

‍

3.2 Raw activity can be misleading

Agent-payment and x402 activity may grow quickly, but raw volume alone is not a reliable signal. Early activity may include testing, self-dealing, leaderboard gaming, speculative behaviour, protocol experimentation or human-led transactions. The valuable product is not a public dashboard of raw flows; it is cleaned, classified and scored activity that customers trust.^B3

‍

3.3 Websites need to distinguish agents from crawlers

Useful agents and unwanted crawlers can look similar at the request level. A website may be able to detect automation without knowing whether the request represents a crawler harvesting content at scale or an agent acting for a specific user or enterprise. The market therefore needs selective proof: enough information to establish authority, accountability and access rights without turning every web request into a full identity checkpoint.^D2

In this note, x401 refers to an emerging identity-and-authorisation pattern for agentic web requests. Where x402 deals with payment for access, x401 deals with proving who authorised the agent, what authority is being asserted and whether the requested action is within scope. The distinction matters because payment evidence may show that an agent can pay, but it does not by itself prove that the agent is authorised to act for a particular user, enterprise or workflow.^D2

‍

3.4 Five decision moments that need a trust record

The deck’s most useful operational framing is that Roundhouse should be open before important agent decisions, in the same way that financial-market participants open a trusted terminal before significant market decisions. The examples below are illustrative decision points, not current customer commitments.^I3

‍

3.5 Enterprises need governance before mass deployment

Large organisations will not allow thousands of agents to operate freely across files, applications, payment systems and external endpoints without visibility. They need an inventory of agents, owners, approved tools, permitted actions, logs, exception workflows, data boundaries, cyber controls and audit evidence. The enterprise buyer may sit in AI operations, cyber, compliance, audit, risk, transformation or finance, but the underlying need is the same: govern the agent, evidence the outcome, and preserve human accountability.^{D1, D3}

‍

4. Proposed Solution: Four-Layer Trust, Scoring and Data Architecture

Section hook: This is the central product section. Read it as the architecture of the investment case: data capture first, proprietary graph second, commercial scores and premium data later.

The proposed solution is framed as a four-layer architecture rather than a broad product suite. The x402 Facilitator captures settlement activity and payment-verification evidence.^{B1, B2} The Indexed Reputation Graph normalises that activity into a defensible dataset; Agent Reputation Scores convert the graph into a commercial decision signal; and the aGDP Index turns aggregate machine economic activity into a public benchmark and premium institutional data feed.^{F7, I3}

‍

4.1 Core four-layer architecture

Section 4 is the core product framing for the note. It should be read as a deliberately staged four-layer architecture, not a broad product suite. The first two layers create the data moat; the second two layers are the planned commercial products. Roundhouse first has to observe useful settlement activity, then normalise it into a reputation graph, then turn that graph into decision-useful scores and data products.^I3

‍

4.2 Layer 1 — x402 Facilitator: free settlement rail and data-capture wedge

The x402 Facilitator is the entry point. It is free, open-source and multi-chain, and should be understood as a loss-leader rather than a direct revenue product. Its strategic value is that it can make agent payments easier while giving Roundhouse a privileged view of settlement activity, counterparties, endpoints, payment proofs and usage patterns.^{B1, B2}

This matters because agent payments are becoming practical across APIs, MCP tools, datasets and web resources.^{B1, B2} The facilitator gives Roundhouse a way to participate in that formation phase without asking the market to buy a heavy enterprise product before the category is ready.^B4

‍

4.3 Layer 2 — Indexed Reputation Graph: proprietary data asset

The Indexed Reputation Graph is the key moat. Every useful facilitator settlement can be normalised into a queryable graph of agents, principals, counterparties, endpoints, cashflows, outcomes and exceptions.^B3 The commercial value is not raw payment volume; it is the cleaned record of who acted, under what authority, against which endpoint, with what payment proof and with what outcome.^{D2, G1}

This layer is also where Roundhouse can distinguish useful economic activity from noise. Early x402 activity may include tests, experiments, self-dealing, leaderboard behaviour or low-quality flows. A defensible graph should therefore rank data quality, persistence, counterparty diversity, endpoint legitimacy and outcome evidence, not merely headline transaction count.^{B3, E2}

‍

4.4 Layer 3 — Agent Reputation Scores: commercial decision signal

Agent Reputation Scores are the primary commercial product. They should be positioned as evidence-backed confidence signals, not guarantees.^{E1, E2} Platforms, lenders, insurers, marketplaces, exchanges, payment networks and enterprise systems could query an agent score before allowing, blocking, pricing, insuring, reviewing or logging an action.^{B1, D1}

The Agent Score API is the machine-scale distribution layer. Seats may matter later, but the larger revenue logic is automated score-query demand.^B3 If autonomous workflows require repeated trust checks at high volume, per-query pricing, API subscriptions and enterprise packaging can become more valuable than a human-facing dashboard.^{D2, H2}

‍

4.5 Layer 4 — aGDP Index: benchmark and premium data feed

The aGDP Index is the planned institutional data product. If agent activity becomes economically meaningful, investors, regulators, exchanges, platforms and enterprises may want a cleaned data feed measuring agent transaction volume, micropayment density, service categories, wallet behaviour, endpoint types, compute-linked activity and cross-protocol flows.^{F7, F8}

The index should be positioned carefully: not as a grand macroeconomic claim before the data supports it, but as a benchmark for machine economic activity that can develop from a free public tier into a premium data feed.^F7 Broader sources on autonomous finance and agent treasuries support the long-term logic for such a product.^{F1, F2} Tokenised infrastructure and broader agent-economy measurement provide additional context rather than base-case revenue proof.^{F5, F6}

A concise way to frame aGDP is as the benchmark layer for machine economic activity: if agents, token routing, stablecoin settlement and pay-per-call services become material flows, aGDP gives investors and enterprises a cleaned measure of where that activity is occurring, which categories are growing and whether the activity is economically persistent rather than experimental noise.

‍

5. Why Now?

Section hook: This section explains why the category may be forming now: agent payments, delegated authority, enterprise governance, public-sector registries and fraud-control needs are converging.

The timing is attractive because multiple independent trends are converging:

agent payments are becoming practical, identity and authorisation standards are forming, public-sector agent registries are emerging, enterprise security teams are identifying the authorisation gap, and agent-native services are appearing.^{B1, D1}

‍

• Agent payments: HTTP 402 Payment Required-style (x402) flows and stablecoin settlement make it possible for agents to unlock resources, APIs, datasets and tasks programmatically.^{B1, B2}
• Delegated authority: emerging identity discussions focus not only on which agent is acting, but on whose authority, for what purpose and with what liability chain.^D2
• Enterprise governance: security commentary increasingly separates authentication from action-level authorisation, creating demand for inventory, policy and evidence tools.^D1
• Public-sector validation: registry-like approaches show that large organisations may need to track agent owners and activities before deployment scales.^D3
• Early services: specialised agent-callable services demonstrate how payment, delivery evidence, reputation and scope limits can combine in real workflows.^C2
• Investment-cycle framing: the technology infrastructure story is still in formation. The investment opportunity is to identify required layers early, not to wait until the category is already obvious.

‍

External category validation — Stripe / OpenRouter: Stripe’s August 2026 OpenRouter commentary is useful because it frames the same market-structure shift from the perspective of a major financial-infrastructure platform. The most relevant point for Roundhouse is Stripe’s observation that AI growth is creating new forms of theft and fraud, including token fraud, which extends the need for fraud prevention, evidence and risk infrastructure from financial transactions into machine/intelligence workflows. 

That supports the core Roundhouse claim that the agent economy will need a system of record: who acted, under whose authority, against which endpoint, with what payment proof, using which model or tool, and with what outcome. Stripe also argues that agents are close to becoming economic actors in their own right and that stablecoins may become a native currency of the AI economy. 

That second point strengthens the aGDP case: if agent/stablecoin activity becomes a meaningful economic flow, investors, platforms and institutions will increasingly need cleaned measurement, benchmarks and premium data feeds.^A4

‍

‍

6. Commercial Model: Data Moat First, Commercial Products Later

Section hook: This section explains how the business could make money without pretending the free facilitator is the revenue product: data moat first, scoring and premium data later.

The commercial model follows the four-layer architecture. Layer 1 is free and generates no direct revenue; it exists to drive data coverage. Layer 2 is the data moat and is measured through quality, coverage and usefulness rather than revenue. Revenue comes from the layers built on that data: API subscriptions, per-query pricing and enterprise contracts for Agent Reputation Scores and the aGDP Index once those products are live at the Commercialisation Stage.

Enterprise revenue in the base model means enterprise contracts for the scoring and index products once live at Commercialisation Stage. It is not a separate Enterprise Trust Platform. Any broader workflow, media, merchant/service-score or enterprise-platform line is treated only in the Appendix as optional upside sensitivity.

‍

6.1 From first raise to Commercialisation Stage readiness

H2 Y1 should focus on proof metrics and Commercialisation Stage readiness rather than implying that Roundhouse is already monetizing a broad product suite. Recognised revenue before Commercialisation Stage should be minimal unless management confirms pilots or preparatory contracts.

• Build Stage value markers: facilitator live, dashboard live, per-entity data visible, settlement coverage, repeat usage and quality of indexed graph.
• Go-to-Market Stage value markers: cornerstone partner negotiation, distribution validation and reference-data access.
• Commercialisation Stage value markers: funded launch of Agent Reputation Scores and the aGDP Index as commercial products.

The valuation upside can remain attractive because the revenue curve may steepen sharply if the graph becomes an accepted reference source. The investment case shifts from many early product lines to data moat first, commercial scoring and index products later, with any additional product economics kept outside the base case as optionality.

‍

‍

7. Financial Model: Four-Layer Architecture and Commercialisation Stage Revenue

Section hook: This section frames the financial model as an evidence test: what has to be true for Roundhouse to move from proof asset to commercial data infrastructure?

The financial model is built around one question: what must be true for Roundhouse to move from proof asset to commercial data infrastructure? Build Stage and Go-to-Market Stage are proof and validation. Commercialisation Stage is where revenue should begin to matter. The model therefore excludes near-term workflow, media, merchant/service-score or separate enterprise-platform revenue and focuses on the two commercial products the architecture is designed to support: Agent Reputation Scores and the aGDP Index.

‍

7.1 Stage logic

‍

‍

7.2 Core revenue streams

Enterprise contract mechanics: enterprise revenue is modelled as contracted access to Commercialisation Stage products, not a full enterprise platform. A contract could combine: (i) a fixed annual platform/data fee for access to Agent Reputation Scores and the aGDP premium feed; (ii) an included score-check allowance; (iii) overage fees for additional score queries; and (iv) implementation / integration support where appropriate. The base formula is: enterprise customers × annual contract value + excess score checks × price per check. If a contract includes premium aGDP data, the data component should be allocated to the aGDP line rather than counted twice.

‍

7.3 Revenue mechanics and indicative ARR

The Y2 ranges are intentionally broad because they are not Company guidance. They are the first commercial evidence test: can Roundhouse convert proof into score queries, enterprise scoring/index contracts and premium data demand? If the answer is no, the valuation case remains a funded option. If the answer is yes, the model can move quickly because usage is machine-led rather than seat-led.

Appendix A2 sets out the first commercial-year numerical assumptions behind these ranges. Appendix A3 then shows how those same variables could extend into Y3-Y5 if the Commercialisation Stage products begin to show customer traction. The appendices are therefore a model bridge, not a separate product roadmap.

Appendix A4-A7 provide the supporting optionality transition, formulae, scenario interpretation and cost/runway assumptions behind the model.

These Y2 ranges are management-reviewed scenario mechanics rather than guidance. They should be used to frame the evidence required for Commercialisation Stage rather than as forecast commitments.

‍

7.3A Revenue assumption evidence bridge

‍

7.3B Evidence hierarchy for moving revenue assumptions into valuation

The Y2 revenue ranges should not all carry equal weight. Investors should treat the model as a staged evidence hierarchy:

‍

Product proof first: live facilitator, indexed activity, per-entity dashboard, working score/API proof and evidence that the graph can separate useful activity from noise.

Usage proof second: repeat activity from credible counterparties, live or scoped workflows generating recurring score-query demand, and enough density to show that score checks can be machine-led rather than seat-led.

Pricing proof third: evidence that counterparties will pay for a score signal, either through usage fees, bundled allowances, overages, enriched evidence requests or enterprise access contracts.

Contract proof fourth: signed pilots or advanced commercial discussions showing how scoring, graph evidence and aGDP data are bought in practice.

Reference-layer proof last: evidence that Roundhouse data is used before counterparties allow, block, price, rank, insure, audit or scale autonomous-agent activity.

‍

Until the first three layers are visible, the model should be treated as a funded option. Proliferation requires product, usage and pricing evidence to improve together. The Moat case requires a higher bar: scoring must become embedded in real decision workflows, and Roundhouse’s graph or aGDP data must begin to look like a reference layer rather than a dashboard.

‍

7.4 Pricing and volume rationale

The pricing bridge is designed to stop the model looking like guesswork. x402 and agent-payment sources support the prospect of repeated machine-to-machine payments and service calls.^{B1, B2} Identity, authorisation and trust sources support the need for third-party scoring before counterparties allow or price an action.^{D1, E1} Plaid-style data/API pricing structures support the use of mixed access fees, usage allowances and overage pricing.^L3 Bloomberg-style data-feed benchmarks support the premium institutional data-feed analogy for aGDP, while making clear these are benchmarks rather than Roundhouse pricing evidence.^{L5, L6}

‍

7.4A Worked volume-build examples

The table below shows how the score/API revenue cases build from customers, checks and pricing. It is deliberately mechanical: the question for investors is whether Build Stage/Go-to-Market Stage proof can justify moving from Proof-Case assumptions into Proliferation or Moat volumes.

‍

Score-query volumes. The Y2 score-check ranges are deliberately wide because they depend on whether Roundhouse remains in proof mode or becomes embedded into automated workflows. Proof-Case assumes a handful of early customers making tens of thousands of monthly checks. Proliferation assumes enough integrations for hundreds of thousands of checks per customer per month. Moat assumes score checks are embedded into high-frequency agent workflows, giving large customers hundreds of thousands to low millions of checks per month. These are scenario mechanics derived from the machine-scale nature of agent payments and service calls, not observed Roundhouse volumes.^{B1, C1}

Price per scored check. The core per-check price range is £0.002-£0.010 because the base model assumes automated, high-volume API usage rather than full identity verification or human-seat pricing. Fraud and risk-scoring benchmarks support the concept of event-based pricing for risk decisions.^L1 Identity and KYC verification benchmarks show that richer verification workflows can price materially above lightweight score checks, which is why £0.015/check is retained only as an outer enriched-score sensitivity.^{L2, L6}

The £0.015/check assumption is retained only as an outer enriched-score sensitivity. The core model remains anchored at lower automated score-query pricing until the Company has evidence that evidence bundles, governance reporting or decision-critical use cases can support premium pricing.

Enterprise contracts for scoring and index products. Enterprise contract value is modelled as a Commercialisation Stage access contract for Agent Reputation Scores and/or the aGDP premium data feed. Plaid-style API pricing supports the use of fixed access fees, included allowances and overage structures.^L3 Sift-style fraud/risk enterprise contracts support the broad annual-contract value range, subject to Roundhouse validation.^{L4, L6}

aGDP premium data feed. The aGDP price and customer ranges are framed as institutional data-feed economics, not a consumer subscription or dashboard line. Bloomberg B-PIPE, real-time market data and pricing-data sources support the premium enterprise data-feed structure.^L5 The agent-economy measurement sources support the category logic, but not Roundhouse-specific demand.^{F7, L6}

The aGDP commercial model should separate the free public headline benchmark from the paid product. Revenue should come from the underlying dataset, query access, premium feed and enterprise data contracts; the public index level is category-building rather than revenue-generating.

The Y2 case is the fulcrum for the investor. It is not the mature-state case; it is the first year in which Commercialisation Stage commercial evidence could be visible. If investors accept that score/API usage, enterprise contracts for scoring/index products and aGDP data demand can begin to emerge after Commercialisation Stage, Appendix A3 sets out how the model could extend into Y3-Y5 and Appendix A4 through A4.2 explain where optional future product lines could become relevant. If the Y2 evidence is not accepted, the optionality should be ignored for valuation purposes.

The forward bridge is therefore variable-led rather than forecast-led. Beyond Y2, the principal drivers are API customer count, monthly score-query density, enterprise contract value, aGDP premium data adoption and evidence that Roundhouse’s graph is becoming a recognised trust reference. Proof-Case growth remains modest; Proliferation assumes faster Commercialisation Stage conversion; Moat assumes data-network effects and reference-layer status.

Optionality only matters if the base model starts working. Workflow interfaces, research/media, merchant/service scores and enterprise-contract uplift should not be used to justify the initial case. They become relevant only if Y2 evidence shows that customers are beginning to use, pay for and trust the four-layer scoring/index architecture. In valuation terms, optionality is a follow-on upside layer, not a foundation for the base case.

‍

‍

7.5 Scenario bridge

The three cases describe different speeds of acceptance for the four-layer architecture rather than a conventional five-year SaaS ramp. Agent-trust infrastructure may need to form quickly if autonomous agents, payment rails and governance standards scale, but it could also stall if proof, buyer urgency or reference-data access do not materialise. The cases are therefore evidence-led: Proof-Case, Proliferation and Moat / accepted trust source.

The preferred scenario labels are Proof-Case, Proliferation and Moat / accepted trust source. They should be read as evidence-led stages of acceptance, not formal Company guidance.

• Proof-Case: Build Stage and Go-to-Market Stage prove technical usefulness, but Commercialisation Stage commercial adoption is slower. Revenue is limited and mainly proof-led API, enterprise-contract and early aGDP activity.
• Proliferation: the graph becomes sufficiently credible for partner-led distribution and early Commercialisation Stage score/API adoption. Revenue steepens after the Commercialisation Stage raise.
• Moat / accepted trust source: Roundhouse becomes a recognised reference layer for agent trust. Revenue is driven by high-volume score queries, institutional data demand and reference-status economics.

‍

8. Funding Requirement and Milestones

Section hook: This section turns the story into measurable proof points. The question is not whether the idea is interesting, but what the £1.5m raise may visibly prove.

The initial raise should be framed as a £1.5m Build Stage equity placing. The deck allocation is £800k for POC / working prototype, £350k for AIM listing costs and £350k for marketing, partnerships and protocol integrations. This is broadly consistent with the memo’s previous £1.15m operating-proceeds framing, but the more precise presentation should separate product build from go-to-market and partnership activity.^I3 Public sources corroborate the Company’s Aquis trading status, public-company information and AI infrastructure positioning, but not the detailed private-deck allocation.^{I4, I5, I6}

Build Stage share-count bridge: the Roundhouse investor page shows 250.2m current ordinary shares and 22.0m warrants at 4p. A £1.5m Build Stage raise at the 5.3p spot price would issue c.28.3m new shares, taking basic shares from 250.2m to c.278.5m before any raise-related warrants or options. The model’s c.278.5m Build Stage basic share count is therefore an illustrative working number and should be reconciled to the final placing price, issue size, expenses and any warrants issued as consideration for executing the raise. On the same basis, Build Stage fully diluted would be calculated as post-Build Stage basic shares plus the current 22.0m warrants, before options and any new warrants issued with the raise.

Externally, Build Stage proof should be measured through concrete activity metrics: agents observed, settlements processed, counterparties touched, merchant/service coverage and transaction value. Data quality and graph uniqueness remain important internal proof points, but the investor-facing evidence should start with observable adoption and economic activity.

‍

8.1 Six-month POC milestones

1. Build the narrow Build Stage rails: x402 payment facilitator, indexer and event schema around the question “Can this agent be trusted to perform this action?”
2. Capture the core event schema: agent identity, principal, delegated authority, endpoint, payment proof, model/tool provenance, action, outcome and exception.
3. Launch the Build Stage live public dashboard showing agent identity, activity history, endpoint legitimacy and authorisation status, with aggregations limited to per-entity data only. No global or economy-wide metrics.
4. Begin build and testing of the first Agent Reputation Score API in a live machine-to-machine workflow, as part of Go-to-Market Stage validation, ahead of Commercialisation Stage commercial launch. Secure 3-5 design partners and credible infrastructure-partner discussions or integration paths; any named strategic partner should be treated as a target until independently announced.
5. Demonstrate differentiated telemetry and detection of noisy, gamed or low-quality transaction activity.

‍

‍8.2 Cost progression and funding discipline

The funding strategy should be read through the cost progression. Build Stage funds proof; Go-to-Market Stage validates demand and partner readiness; Commercialisation Stage only makes sense if evidence justifies a larger operating platform. The question is not whether Roundhouse can raise more money, but whether the proof base is strong enough to justify scaling into Proliferation.

‍

Cost scaling and operating leverage

Revenue upside should not be read without cost scaling. The model assumes that costs rise materially after POC if Roundhouse pursues Proliferation or Moat outcomes. The point is not to avoid higher costs; it is to ensure that recurring revenue, data value and API usage scale faster than the operating build-out required to support them.

‍

‍

The operating-leverage analysis assumes blended gross margins improve as the revenue mix shifts from early implementation and support work toward score/API revenue, enterprise contracts for scoring/index products and premium aGDP data feeds. 

Indicatively, blended gross margin could move from c.70%-80% in the Proof-Case to c.75%-85% in Proliferation and c.80%-90% in the Moat case, provided scoring, ingestion and data-infrastructure costs are controlled.

Gross-profit assumption note: these gross margins are not based on current Roundhouse trading evidence. They are scenario margins for a data/API business if Commercialisation Stage products launch successfully. The Proof-Case assumes more services, implementation, support and under-utilised infrastructure, so margin is lower. Proliferation assumes a higher mix of recurring score/API and data-feed revenue. Moat assumes stronger data-network effects, higher query density and better infrastructure utilisation. The assumptions remain sensitive to cloud, indexing, scoring, compliance, support and data-acquisition costs.

‍

Cost progression and funding discipline

The cost base is the main gating issue between Proof-Case and Proliferation. Build Stage should fund proof as cheaply as possible: live rails, usable telemetry, graph quality, partner engagement and early pricing evidence. Proliferation spend should begin only when objective evidence shows that additional cost is buying speed, distribution and infrastructure depth rather than merely extending the story.

The planned hiring waves are already embedded in the Proliferation and Moat cost bands. They include backend engineering, commercial and partnership coverage, full-stack capability, data/ML, compliance/security and a second product squad. No separate cost uplift is required in the model; the control point is sequencing those hires against proof gates, revenue evidence and financing progress.

‍

Indicative profitability impact

The revenue scenarios should be read against the cost base required to achieve them. The table below gives a simplified operating-impact view. It is not an EBITDA forecast; it shows whether the revenue trajectory could absorb the cost base implied by each stage.

POC-year rationale: the POC year should be deliberately loss-making because the initial raise is buying evidence rather than revenue. The priority is to prove the facilitator, indexed graph, data quality, per-entity dashboard, first scoring logic, partner interest and pricing evidence. Any pilot fees or preparatory commercial payments should be treated as validation signals, not as a revenue base. This keeps the Proof-Case Y2 range coherent: Y1 proves the wedge; Y2 tests whether adoption and pricing begin to convert.

‍

‍

Proof-Case revenue note: the c.£0.05m low end is annualised Y2 revenue, not monthly revenue. It is built from c.£3k of score/API usage, c.£50k of small enterprise validation contracts and no aGDP revenue. It is therefore a proof-survival scenario: Build Stage/Go-to-Market Stage evidence exists, but Commercialisation Stage commercial conversion has not yet scaled.

‍

8.3 Commercialisation Stage financing and dilution sensitivity

Commercialisation Stage financing should be presented as evidence-led acceleration capital. The deck frames the process as opening around December 2026 and targeting a substantial Singapore-led institutional fundraising round to close in Q1 2027, but this should be treated as a management target rather than a committed financing event. The trigger should be evidence: live dashboard delivery, credible telemetry, repeat API usage, signed or highly advanced customer discussions and strategic-partner validation.

The logic is simple: the Build Stage raise buys proof; Commercialisation Stage capital buys speed only if proof is working. Its purpose would be to fund the broader Proliferation operating build-out identified in Section 8.2: deeper integrations, infrastructure partnerships, enterprise sales, API reliability, security hardening, data acquisition, compliance assurance, customer success and partner-led distribution.

‍

Sequencing clarification: the initial Commercialisation Stage launch, targeted for December 2026, is intended to be funded from the proceeds of this placing rather than the second raise. The institutional raise is expected to support deployment of the Commercialisation Stage products at scale once early commercial traction is established, not the initial launch itself.

The strongest Commercialisation Stage trigger would be evidence that the four-layer architecture can become an accepted source of agent trust and machine-economic data: live telemetry, repeat API usage, signed pilots, infrastructure-partner validation and agent or service-side incentives to be scored. If those proof points emerge, a Singapore-led institutional raise becomes easier to justify because investors can see a potential trust-infrastructure opportunity rather than only a useful tool with long-dated optionality.

Strategic-partner validation could be important to this Commercialisation Stage logic. The Company's historical relationship with a leading global digital-asset exchange demonstrates prior commercial engagement with a recognised infrastructure participant, and Company materials refer to a potential founding-partner milestone with an infrastructure participant of this kind. However, that should be treated as a target or illustrative validation point unless independently announced. The model should therefore value this relationship as an example of the type of infrastructure-partner proof point that could support Commercialisation Stage, not as a confirmed future participant.^{I3, I6}

‍

Commercialisation Stage dilution scenarios

The funding logic must be viewed through both cost quantum and dilution. Section 8.2 shows why a move from POC into Proliferation could require a materially broader operating platform, with monthly costs rising toward c.£500k-£900k. 

The £10m case is therefore used as an illustrative modelling convention rather than Company guidance: it provides a practical acceleration-capital example while forcing discipline on hiring, customer evidence and commercial proof. The £7.5m case represents a narrower rollout; the £15m case only makes sense if partner validation, customer evidence and financing terms support a more ambitious category-capture plan.

Note: Commercialisation Stage dilution is calculated as new Commercialisation Stage shares divided by post-Commercialisation Stage basic shares, before options and any warrants issued with the Build Stage or Commercialisation Stage raises.

‍

The dilution point is important. If evidence is strong and the share price improves before Commercialisation Stage, a substantial institutional raise can fund acceleration with manageable dilution. If the share price does not re-rate but the Company still attempts to raise a full growth round, dilution becomes materially heavier. That may still be rational if the strategic opportunity is exceptional, but it would require clearer evidence of partner validation, revenue acceleration and a route to operating leverage.

Positive dilution logic: Commercialisation Stage dilution is positive only if the new capital is raised after evidence has improved the valuation basis. If proof is weak, a larger round simply extends the story and increases dilution. If proof is strong, the same dilution can be value-accretive because it funds the operating capacity required to turn product proof into Proliferation: score/API adoption, enterprise contracts, premium aGDP demand and partner-led distribution.

‍

8.4 Commercial flywheel

More facilitator adoption creates more settlement telemetry. More telemetry improves the Indexed Reputation Graph. A stronger graph supports better Agent Reputation Scores. Better scores increase query demand, enterprise-contract potential for Commercialisation Stage scoring/index products and premium data-feed credibility, which in turn reinforces the graph.

‍

8.5 Current Financial Position, Runway and Funding Logic

The interim accounts provide the starting point for the cash bridge. The table converts key Singapore-dollar figures into sterling and uses the reported 18-month operating outflow to estimate historical monthly burn.^I6

‍

The S$2.42m operating outflow implies historical burn of approximately S$135k per month, or c.£79k per month at the 31 March 2026 exchange rate. This is a historical reference point, not the forward POC budget.

After the reporting date, the Company sold its Ethereum holdings and repaid the US$350,000 Kraken-linked loan facility. The key investor issue is therefore post-disposal net cash plus the proposed £1.5m raise, not the earlier treasury balance.^{I5, I6}

‍

‍Estimated cash bridge to 17 July 2026

The bridge below estimates cash as at 17 July 2026 by adding ETH sale proceeds, deducting loan principal, three months’ interest at 9% p.a. and operating burn since 31 March. It is analytical and should be reconciled to management records.

‍

‍

The bridge suggests only modest residual cash before any new fundraising. That supports the conclusion that the £1.5m raise is required for POC runway and AIM transition rather than being surplus capital.

‍

‍

9. Valuation Framework: Milestone-Led, Dilution-Sensitive

Section hook: Valuation should be read as a milestone ladder, not a single target. The key issue is whether proof, adoption and dilution allow the case to move from option value to Proliferation or Moat.

‍

The previous 40p-style upside case was partly supported by an Ethereum-treasury / DATCo-style flywheel that no longer drives the investment thesis. 

The current valuation framework should therefore be rebuilt around trust-agent infrastructure milestones, revenue evidence, gross-margin potential and dilution. 

At a current share price of 5.3p, the equity should be viewed as a funded option on Roundhouse proving that it can move from listed concept to credible agentic-AI trust infrastructure.

‍

9.1 Current position and valuation reset

The valuation question is now whether the Company can deliver a working x402 Facilitator, Indexed Reputation Graph, per-entity dashboard, Agent Reputation Score API proof, differentiated telemetry, design-partner engagement and credible Commercialisation Stage financing. Until those milestones are delivered, valuation should remain milestone-led rather than based on aggressive long-range revenue multiples.

‍

‍

‍

9.2 Milestone valuation gates

The cleanest 12-18 month framework is a sequence of valuation gates. Each gate changes the basis on which the market can value the Company.

‍

‍

9.3 Valuation metrics once evidence exists

Revenue multiples and gross-profit multiples become more useful only once there is evidence that the Company has repeatable usage, pricing power and data defensibility. Until then, they should be used as scenario tools, not as a single-point target.

‍

The gross-profit references make the valuation framework more conservative and internally consistent. In the Proof-Case, gross profit is too small to justify a revenue-multiple valuation; the case remains a funded-proof option. In Proliferation, the upper end of the range becomes the first point at which gross profit can support a more conventional software/data multiple. In the Moat case, valuation sensitivity remains substantial because high-volume score queries and premium data-feed revenue can produce strong gross profit if margins hold; however, the outer case still depends on validating enriched-score pricing and Commercialisation Stage execution.

‍

9.4 Dilution-adjusted 12-18 month scenario ranges

The valuation ranges should be read against the Section 8 revenue mechanics. Proof-Case revenue is deliberately modest because the model assumes little recognised revenue before Commercialisation Stage. Proliferation requires Commercialisation Stage scoring/index products to convert into repeat API usage, enterprise contracts and premium data revenue. The Moat case is wide because it includes both high-volume score/API economics and enterprise/institutional data-feed adoption; the £0.015/check outcome is treated only as an outer enriched-score sensitivity, not the core revenue case.

The cost-revenue gate is central to the valuation. Proof-Case revenue is not sufficient to carry the implied post-POC cost base, so valuation remains option-led. Proliferation only becomes investable if early revenue, score-query demand and enterprise/customer evidence justify the higher Commercialisation Stage cost base. The Moat case requires not just higher revenue, but revenue that scales faster than cloud, indexing, data acquisition, compliance, security, enterprise sales and customer-success costs.

Any target range must be dilution-adjusted. After the Build Stage raise, basic shares are modelled at c.278.5m. Commercialisation Stage scenarios can move the share count to c.338.5m-c.411.8m depending on raise size and price, before options and any new warrants issued with Build Stage or Commercialisation Stage. A 12-18 month target should therefore be presented as a conditional range, not a single number.

‍

9.5 Valuation conclusion

A single-point price target is the wrong way to read Roundhouse at this stage. The valuation should be presented as a conditional 12-18 month scenario range, with 20p used only as a Proliferation reference case rather than a formal target. On the current framework, the Proof-Case supports limited upside if Roundhouse funds the POC but commercial evidence remains thin; the Proliferation case supports a materially higher c.12p-31p range if POC delivery, AIM progress, early usage, pricing evidence and Commercialisation Stage funding at improved terms are achieved; and the Moat case represents broader upside only if the market begins to treat Roundhouse as emerging trust infrastructure for autonomous-agent activity.

This framing preserves the upside while removing false precision. The old 40p-style case cannot be carried by Ethereum treasury mechanics or by a standalone dashboard narrative. It can only re-emerge as an evidence-led infrastructure outcome: POC delivered, dashboard and graph live, score/API traction visible, credible infrastructure-partner validation, Commercialisation Stage capital raised at materially better pricing and growing belief that the Indexed Reputation Graph and Agent Reputation Scores can become a system of record for agent activity. Until those proof points are visible, the right investor language is range-based, milestone-led and dilution-sensitive.

‍

10. Competitive Landscape

Section hook: This section should be read as category validation and risk mapping, not as proof that the opportunity is uncontested.

The competitive landscape is already forming across payment networks, cloud platforms, identity providers, cyber vendors, crypto-native protocols and agent-payment infrastructure. This should be treated as category validation, not ignored. The key point is that many players solve parts of the trust problem, while few appear to offer a neutral, cross-rail scoring and observability layer for autonomous economic activity.

‍

10.1 Payment-network trust layers

Visa, Mastercard and Cloudflare-style initiatives show that counterparties want to distinguish authorised agents from crawlers and bots. That validates the category, but Roundhouse should not claim to replace payment networks. Its stronger role is as a neutral evidence, scoring and observability layer across card networks, stablecoin rails, x402-style flows, wallets, exchanges, marketplaces and enterprise workflows.^{J1, J2}

‍

10.2 Enterprise identity, governance and security vendors

Enterprise identity and cyber-security vendors are extending access-control, governance and runtime-security products toward AI agents. Microsoft Entra Agent ID, Okta/Auth0-style identity platforms and agent-security vendors validate the need to manage non-human identities, permissions and runtime risk. These are credible adjacent competitors but mostly address internal enterprise control. Roundhouse’s sharper claim is to combine governance with external payment/action telemetry, endpoint legitimacy, behavioural scoring and market-data-style observability.^{J3, J4}

‍

10.3 Agent-payment and x402 infrastructure companies

Agent-payment and x402 infrastructure companies are closest to the rails layer. AWS AgentCore Payments, Alchemy, AgentLux and similar efforts may generate the raw flows that make the category visible, but raw activity is not the same as trusted economic data. Roundhouse should position itself as the layer that cleans, classifies, scores and contextualises those flows for enterprises, platforms, exchanges, analysts and institutions.^J5

‍

10.4 Decentralised agent identity and reputation protocols

Decentralised identity and reputation approaches, including ERC-8004, are emerging around agent identity, provenance, consent and reputation.

x401 should be treated as the identity-and-authorisation counterpart to x402: x402 concerns payment for a resource; x401 concerns who authorised the agent, what authority is being asserted and whether the action is within scope.^J6

KYA, Trulioo / Worldpay Digital Agent Passport and similar approaches reinforce both the commercial opportunity and fragmentation risk. Roundhouse should remain standards-neutral, scoring across protocols rather than depending on one standard winning.^J6

‍

10.5 Strategic implication

Competition weakens any claim that the opportunity is uncontested but strengthens the claim that a new category is forming. Fragmentation across x402, x401, ERC-8004, KYA and payment/identity systems may itself create the need for a neutral aggregation layer.

‍

If Roundhouse can secure differentiated telemetry and prove that its scoring is decision-useful, competition becomes evidence of category momentum rather than a reason to dismiss the thesis. Payment-network and identity-platform activity validate the category.^{J1, J3} x402 infrastructure and agent-reputation protocols reinforce the need for a neutral aggregation layer.^{J5, J6}

‍

11. Principal Risks and Offsets

Section hook: This section is the Fin Prom and serious-investor safety check: what can go wrong, what evidence reduces that risk, and where the case should avoid overclaiming.

‍

‍

12. Bottom Line

Section hook: This is the closing investment judgement. It should leave the reader with the disciplined version of the bull case: proof first, dilution controlled, trust-source credibility earned.

Roundhouse can be a credible fundraising story if it is pitched with discipline. The Company is not yet being valued on current revenue; it is being valued on whether it can prove a required trust, risk and fraud-control layer for autonomous-agent commerce. Recent Stripe / OpenRouter commentary strengthens the category backdrop by showing that major infrastructure platforms are now treating agentic commerce, stablecoin settlement, model routing, metered usage and intelligence allocation as strategic infrastructure, but it should be used as external validation of the market, not as proof of Roundhouse demand.^A4 

The investor case is strongest where payments, token routing and usage management are not enough: counterparties also need to know whether an agent is authorised, whether its activity is genuine, whether it is behaving consistently and whether fraud, gaming or low-quality activity is polluting the signal.^{D1, D2}

The first raise should prove the wedge: a working x402 Facilitator, Indexed Reputation Graph, per-entity dashboard, initial settlement telemetry, partner validation and evidence that counterparties will pay for Commercialisation Stage scoring/data products.^{B3, I3} The second raise should be presented as category-capture capital only if proof points justify it. Strategic-partner validation, including the type of infrastructure proof point referenced in the deck, may support the case, but named partner milestones should be treated as targets until independently announced.^H1

The Company should avoid over-indexing on raw x402 volume, top-down TAM forecasts or a near-term workflow-interface assumption. The more investable case is that proof of product, proof of paid demand, partner validation and defensible data access can justify staged financing before profitability is fully visible.^{E1, I3} The old 40p-style upside can no longer be justified by Ethereum treasury mechanics, and indeed the company has exited from the Ethereum holdings strategy; it can only be justified if Roundhouse delivers POC, wins credible validation, raises Commercialisation Stage funding at improved pricing and demonstrates that the four-layer architecture can become an accepted trust source rather than a dashboard product.^H2

That risk/fraud emphasis matters. A future agent economy will not be constrained only by wallet access or payment rails; it will also be constrained by trust failures, spoofed agents, unauthorised delegation, endpoint abuse, artificial volume and token or usage fraud. Roundhouse’s more defensible positioning is therefore not “agent payments are growing”, but “agent payments and intelligence flows will need a neutral evidence layer before serious counterparties can price, allow, insure, audit or scale them.”

The risk-reward is concentrated in the valuation gates. If Roundhouse only reaches the Proof-Case, upside from 5.3p is likely limited. If it reaches Proliferation, a 12-31p range becomes possible if dilution is controlled and Commercialisation Stage capital is raised on better evidence. A 40p-plus style outcome requires the Moat case: accepted trust-source credibility, high-volume score queries, enterprise scoring/index contracts and premium data demand. A 20p reference case is therefore best read as a Proliferation-weighted outcome, not a base-case promise.

‍

Appendix A. Financial Model Assumptions

This appendix supports the four-layer architecture and provides model inputs for confirmed product lines. Commercialisation Stage+ optionality is shown separately so it can be added or removed without changing the core model.

‍

A1. Core model drivers

‍

‍

A2. Y2 / first commercial year numerical assumptions

The core model is built from activity and query economics rather than a top-down TAM percentage. These assumptions should be read as Y2 / first commercial year mechanics after Commercialisation Stage products begin to be sold, not as a mature-state forecast. The numerical logic is bottom-up: first estimate facilitator coverage and graph quality, then estimate score-query demand, enterprise contracts for scoring/index products and aGDP premium data demand.

The ranges are illustrative and should be tightened with management. The important point is that the four-layer model can still produce meaningful first-commercial-year upside without adding extra product lines: high-volume score/API customers can produce recurring usage revenue, while enterprise contracts for scoring and premium aGDP data provide larger-ticket institutional revenue if the graph becomes trusted. Enterprise contract ranges should be cross-checked against enterprise data, API and premium-feed benchmarks rather than treated as Company guidance.^{H1, H2}

‍

A3. Illustrative Y3-Y5 growth bridge — not Company guidance

The Y2 model is the first commercial evidence year, not the end-state. Investors will naturally ask what happens beyond Y2. The answer should not be a precise five-year SaaS forecast, because the product is still at concept-to-proof stage and the market may not develop seat-by-seat. Instead, the bridge below shows how the Y2 mechanics could extend if the investor accepts the Y2 commercial argument: customer count, score-query density, enterprise contract value and aGDP adoption are the key variables.

‍

‍

A4. Optionality transition — when Commercialisation Stage+ lines become relevant

The optionality module should be read only after the investor accepts the Y2 commercial argument. In other words, workflow interface, media/research, merchant/service scoring and larger enterprise-contract uplift are not needed to justify the base model. They become relevant only if the four-layer architecture begins to work: scoring demand emerges, the graph becomes trusted, enterprise customers ask for workflow/reporting layers and aGDP data gains institutional credibility.

‍

‍

A4.1 Commercialisation Stage+ optionality module — outside the base case

The base model stops at the four-layer architecture: facilitator, indexed graph, Agent Reputation Scores and the aGDP Index. The optional lines below suggest some commercial thinking but should be read only as Commercialisation Stage+ sensitivities. They are not needed to justify the Proof-Case, Proliferation or Moat scenarios. They become relevant only if the scoring and index products show customer traction, the graph becomes trusted and customers ask for broader workflow, reporting or service-side scoring.

‍

‍

A4.2 Optionality revenue sensitivity — not Company guidance

The sensitivity below is deliberately separated from the core model. Its purpose is to preserve valuation upside from earlier work without implying that Roundhouse is currently building these lines. 

‍

This optionality sensitivity should not be added to the base revenue case. It is a separate upside layer for valuation discussion if the four-layer model begins to show evidence. The main model remains driven by score/API revenue, enterprise contracts for scoring/index products and aGDP premium data.

‍

‍

A5. Revenue formulae

Agent Reputation Scores: API customers × monthly score checks × price per scored check × active months. Enterprise scoring contracts should be modelled as annual contract value plus any overage score checks above the included allowance.

aGDP premium data feed: data customers × annual licence price × recognition period, plus any separately priced query access to the underlying dataset. The free public headline benchmark is category-building and should not be counted as revenue.

Enterprise contracts for scoring and index products: enterprise customers × annual contract value × recognition period, where the contract is explicitly built around Agent Reputation Scores, score-query allowances, graph evidence and premium aGDP data rather than a separate Enterprise Trust Platform. If aGDP access is separately priced, allocate that component to the aGDP premium data-feed line to avoid double-counting.

‍

‍

A6. Scenario interpretation

• Proof-Case: score/API usage develops slowly; aGDP remains early; enterprise contracts for scoring and index products are limited.
• Proliferation: Commercialisation Stage funding accelerates score/API adoption and aGDP institutional data demand.
• Moat: Roundhouse becomes an accepted trust reference, creating machine-scale scoring queries and premium data-network effects.

‍

‍

A7. Cost and runway assumptions

The cost model should remain staged. Build Stage/Go-to-Market costs fund facilitator, graph, dashboard, data infrastructure, partner work and AIM transition. The Commercialisation Stage costs, will if this raise stage is reached and confirmed, fund commercial scoring, premium data feeds, integrations, security, compliance, enterprise sales and customer success. Proliferation and Moat cases require Commercialisation Stage capital to be raised because costs must scale ahead of revenue, as shown in Section 8.2.

‍

‍

‍

‍