> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.
# Self Hosted x402 Agentic Payment Gateway
> Self hosted x402 facilitator and agentic payment gateway: settle x402, MPP and AP2 on seven chains (Arc from 16 Sep 2026) with post quantum receipts an auditor verifies offline.
## What it is
The **Payment Gateway** is a self-hosted x402 facilitator and agentic payment gateway that
takes a stablecoin payment from intent to a signed, offline-verifiable proof across seven chains (Arc from 16 Sep 2026). You
run it on your own infrastructure: it holds no account with us, makes no outbound call to us,
and never phones home.
It does three things end to end:
1. **Creates a payment intent** for a specific network, asset, amount, recipient, and your own
order reference, and hands back the receive address to show your customer.
2. **Watches that chain** for the matching settlement, applying the **finality rules of that
specific network**, and resolves the intent to a clear status.
3. **Emits a no-PII settlement receipt** that is content-addressed and signed with the operator's own
Falcon-1024 key, verifiable offline against a published key, and folds straight into the
[Compliance Command Center](/compliance-command-center) evidence chain.
It is built on the same **Substrate 2** crypto core as the rest of the suite, so a settled
payment becomes evidence that is unforgeable today and stays unforgeable after the migration to
post-quantum cryptography.
A single gateway engine and a single service port. All seven chains ship in the one bundle and are
discovered automatically when the engine starts; enable the networks you settle on and leave
the rest idle.
Confirms a payment is included, succeeded, reached the right recipient, for the right amount,
in the right asset, with each network's distinct finality model applied, not a one-size "is
it mined".
Each settlement produces a no-PII receipt carrying amounts, refs, and hashes but never personal
data; every receipt is post-quantum signed with the operator's own key and verifies offline with no service running.
Runs as one process on your infrastructure. Bring your own chain RPC endpoints. Nothing
leaves your network, and the receipts verify long after the service is switched off.
## Agentic payment protocols
The gateway settles three agentic payment protocols on the same verify-then-prove engine across the
seven chains, so a payment negotiated by an agent settles and is receipted the same way a direct
payment is:
* **x402.** `POST /v1/x402/requirements` returns a spec-v1 `402 Payment Required` body for an intent;
`POST /v1/x402/verify` confirms settlement and returns the receipt as proof. The settlement is signed
with the operator's own Falcon-1024 key on the evidence ledger, verifiable offline against the published key, with no shared secret.
* **MPP.** The x402 `intent` extension (`charge` or recurring `subscription`).
* **AP2.** Renders a merchant CartMandate's price as a W3C Payment Request and binds the `cart_id` into
the receipt, so the settlement proof commits to the cart it paid.
In every case the gateway is the settlement-proof layer beneath the protocol: it verifies the on-chain
settlement and records the evidence to a hash-chained ledger, signed with the operator's own Falcon-1024
key and verifiable offline. Mandate bounds, consent, and agent negotiation stay in the protocol layer.
### A2A discovery, and where agent-to-agent settlement lives
The gateway is also an **A2A-compatible payment agent** (Google Agent2Agent, serving both **v0.3 and
v1.0.1** clients from the same endpoint via `A2A-Version` negotiation, over HTTP+JSON, JSON-RPC, and the gibberlink data-over-sound transport): other
agents discover it at `/.well-known/agent.json` and send it verify-payment, create-checkout, or
check-status tasks, which settle over x402, MPP, or AP2 on one of the seven chains exactly as above. The
public AgentCard is served on your own domain and can be signed with a key you control (A2A spec section
8.4), so a counterparty verifies the card is really yours against your own JWKS. This is an agent asking
your gateway to run a payment.
Genuine **agent-to-agent settlement between two peer agents**, where the two agents are themselves the
counterparties and no operator settles on their behalf, is [agent-to-agent settlement](#agent-to-agent-settlement-you-allocate): included in this
bundle and federation-allocated (see [Agent-to-agent settlement you allocate](#agent-to-agent-settlement-you-allocate)
below). The settlement engine runs x402, MPP, and AP2 across seven chains (Arc from 16 Sep 2026); peer settlement between two agents is part of the same bundle. The same signed A2A payment message can also arrive over the gibberlink data-over-sound transport, verified identically.
### A2A over gibberlink: enrollment and anchored auth
Before an agent calls a skill over the gibberlink transport you issue it a passport bound to its
`did:key`: `POST /v1/passport/issue` with `agent_did` set to the agent's Ed25519 `did:key`, the
`scopes` (skill ids) it may call, and a `spend_limit_microusd` with an optional `spend_window`.
Issuance returns a signed passport credential, but the gibberlink transport does not require the agent
to present it on the wire — the passport is recorded on your side, binding the key to a tenant and its
authority, and the transport authenticates by the anchored signature alone (below).
**Anchored, secretless auth.** The gibberlink envelope's `keyid` *is* the agent's DID, so the
identifier itself commits to the public key. The gateway verifies the envelope signature against the
key it parses out of that DID: a `did:key` is resolved inline and offline, and a `did:web` DID is
resolved through an SSRF-hardened resolver that fetches only once an enrolled passport for that DID
already exists — an unknown DID can never trigger an outbound fetch — behind a per-process cache and a
kill switch. There is no bearer token, API key, or shared secret on the wire, so nothing secret is
transmitted and the channel is sound even over real speaker-to-mic audio. An agent cannot present
another's identity without changing the `keyid`, which would then no longer match the key that signed.
**Authority from the passport, not the caller.** The tenant is never asserted by the caller; it is
resolved from the passport that binds that DID, and an ambiguous binding (the same DID enrolled by more
than one tenant) is refused. A message that names a skill is refused unless the passport's `scopes`
grant it.
**Spend and replay.** For fund-moving skills the passport's spend limit is enforced before dispatch.
With no window (or a per-transaction window) it is a per-call cap; with a `spend_window` of `per_day`,
`per_week`, `per_month`, or `total` it is a **cumulative** cap enforced by an atomic
reserve-before-dispatch ledger, so two concurrent envelopes from the same agent cannot both slip under
the limit, and a checkout that fails to dispatch releases its reservation. Amounts are always validated
as finite and positive — a negative, zero, or non-numeric amount is refused. When a spend limit applies,
the capped amount must be in USD or USDC; any other currency is refused rather than bypassed, because
cross-currency conversion is a later follow-up (a call with no spend limit set may use any currency the
checkout supports). A re-sent envelope is rejected by a durable, single-use nonce guard shared across
workers, and the tenant's own caps still apply on top.
## How it differs from Settlement Verification
[Settlement Verification](/settlement-verify) is a read-only OEM **SDK** you embed inside your
own product to answer "did this settle and finalise". The Payment Gateway is a **service you
run**: it owns the whole intent lifecycle (create, watch, resolve, attest), produces the hash-chained,
Falcon-1024 signed evidence chain, and is the surface a full-custody
payout phase plugs into. If you only need to
confirm an arbitrary settlement inside your own backend, the SDK is the lighter fit. If you want
a gateway that runs the payment from request to proof, this is it.
Agent-to-agent settlement is the peer counterpart. It settles a single payment between
two autonomous agents that are parties to it, and structurally refuses to settle for third
parties. Payment Rails is the operator tier: it runs payments at scale on behalf of others. The
two compose, because an agent-to-agent execution reference is exactly the evidence Payment Rails
consumes, so an agent that outgrows peer settlement has a clean path here.
## The intent lifecycle
You describe the payment you expect; the gateway resolves what actually happened on-chain to one
of a small, closed set of outcomes:
| Status | Meaning |
| ------------ | ----------------------------------------------------------------------------------------------------------------- |
| `pending` | Intent created, no qualifying transfer to the recipient seen yet |
| `confirming` | A matching transfer is on-chain but has not reached the chain's finality threshold |
| `settled` | A transfer for the expected amount (or more) reached the expected recipient, in the expected asset, and finalised |
| `underpaid` | A transfer to the recipient landed for less than the intent amount |
Matching is by exact recipient, asset, and amount, so a transfer to a different address simply
never qualifies (the intent stays `pending`) rather than being mistaken for payment. When a
qualifying transfer finalises, the gateway records a settlement entry in the append-only, hash-chained
ledger, signed with the operator's own Falcon-1024 key. There is no ambiguous "probably paid": the outcome
is explicit, and the proof of how it was reached travels with the receipt.
## The settlement receipt
Each resolved settlement is written to an append-only, hash-chained evidence ledger and signed with the
operator's own Falcon-1024 key (NIST Level 5) through Substrate 2, by an on-box signer that picks up each
new settlement within seconds. A receipt is:
* **No-PII by construction.** It carries the network, asset, amounts (as exact integer minor
units, never lossy floats), confirmations, finality, your order reference, and content-address
hashes. It never carries names, emails, or any personal data. The payer and recipient appear
only as hashed references, not raw addresses.
* **Offline-verifiable.** Anyone you hand the exported pack to can verify every signature and the
full chain with no service running and no network access. A single altered byte breaks
verification.
* **CCC-ingestable.** The receipts export as a pack that drops straight into the Compliance
Command Center, where they appear in the consolidated posture as **"Payment Gateway ·
settlement receipts"** alongside the rest of your evidence estate. Settlement evidence sits next
to your sanctions, retention, and audit evidence in one auditor pack.
### Export and verify a receipt
`algovoi-receipt ` emits a single settlement's portable receipt. A standalone verifier ships alongside it
and checks that receipt with **stock open-source tools only**: integrity is a SHA-256 over the receipt's canonical
bytes checked against its `content_hash` (Python `hashlib`), and the Falcon-1024 signature is checked with `pqcrypto`
(`pip install pqcrypto`). No AlgoVoi
software and no canonicaliser are needed to verify, so an auditor confirms a settlement offline, against your
published key, with tools they already trust. The export is read-only and never touches the signing daemon.
## Agent passports: a federated issuer you run
The rails run a **federated agent-passport issuer** on your own infrastructure, on by default. A passport
is a Falcon-1024 signed credential that says an agent is authorised to act, bounded by the scopes,
spend limit, spend window, and expiry you set when you issue it. The passport verifies offline against
the issuer's published key and can be revoked, so a counterparty confirms an agent is still authorised
without calling you.
* **Self-provisioning issuer.** On install the rails generate the issuer's own Falcon-1024 keypair,
hold the secret key in a `0600` key file that never enters the environment, and derive a stable
issuer identity `did:key:passport-` from the public key. Nothing is supplied by AlgoVoi.
* **Federated by design.** The issuer publishes its DID and public key to the federation registry that
ships with the bundle, so any verifier in the mesh checks a passport against the issuer's published
key rather than a shared secret. This is why the federation validator is in the estate: passports are
issued and verified across issuers, not just within one box.
* **Revocable, with a CRL.** Revoking a passport is scoped to the owning tenant and publishes to a
content-addressed revocation list; a verifier that pulls the CRL fails a revoked passport closed. A
verify portal link renders the same check for a human.
| Passport carries | Meaning |
| -------------------------------- | ----------------------------------------------------------------- |
| `agent_did` | the agent the passport is issued to |
| `scopes` | the named capabilities the agent is authorised for |
| `spend_limit` and `spend_window` | the value bound the agent may transact within a window |
| `expires_at` | when the passport lapses on its own |
| Falcon-1024 signature | the issuer's post-quantum signature over the canonical credential |
The whole lifecycle (issue, list, verify, revoke, CRL, verify portal) is driven from an **Agent Passport**
tab in the operator control panel, so an operator runs it without touching the API. There is no separate
purchase: the passport issuer is part of the rails bundle.
## Agent-to-agent settlement you allocate
Agent-to-agent settlement is included in the bundle and **federation-allocated**: you create members in
the operator panel and allocate each one post-quantum agent-to-agent settlement, with no per-agent fee
and nothing to buy separately. Two agents then verify each other's passports, agree which chain to settle on, and
settle once as a single content-addressed reference that anyone can recompute offline.
* **You allocate, protected by a root-signed delegation.** On install the rails provision a federation
key of your own and receive an AlgoVoi root-signed, name-constrained certificate that scopes it to your
own DID namespace. You mint member licences under that namespace; a licence for any DID outside it is
refused by every verifier. The federation secret stays in a `0600` key file that never enters the
environment.
* **Agent-to-agent only, by construction.** Every member licence names its holder's own agent DID, so the
mesh settles only transactions that member is a party to. It will not settle between two third parties;
that is a payment rail, which is the rest of this bundle. Allocating keys and settling on behalf of
others stay cleanly separate.
* **One reference across chains, verified offline.** The agents each sign the chains they accept, bound to
the session, and settle only on a chain both signed for. The result is one `execution_ref` that binds
both passports, the two-party set, the agreed chain, and the amount, and recomputes offline with no
AlgoVoi service in the trust path. The chain only carries a 32-byte anchor, so one integration works
across the chains you touch.
| Member licence carries | Meaning |
| ---------------------- | -------------------------------------------------------------------------- |
| `agent_dids` | the member agent(s) the licence is bound to |
| `issuer_cert` | the AlgoVoi root-signed, name-constrained federation certificate |
| name constraint | the DID namespace the operator may allocate within |
| Falcon-1024 signatures | the federation key's post-quantum signatures, chaining to the AlgoVoi root |
Allocation is one click in the operator panel: pick a merchant, allocate its agent-to-agent settlement, and the panel
returns the allocation key and a one-line offline install. Two-agent settlement quickstarts ship in the
bundle under `examples/mesh_a2a/`. There is no separate purchase and no per-transaction fee: agent-to-agent
settlement is a capability of the rails bundle, allocated across your whole federation rather than bought
as a separate product.
## Seven chains, one bundle (Arc from 16 Sep 2026)
Seven chains ship live in the one bundle today, with Arc (Circle's USDC-native L1) settling from 16 Sep 2026; each registers itself with the engine on install.
Coverage is deep where generic multi-chain tooling is thin: the long-tail asset and finality
semantics are handled correctly per network.
| Chain | Network kind | Asset detected | Settlement model |
| ---------------------------- | --------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Base** | EVM L2 | USDC (ERC-20) | Token-transfer log detection to the recipient, with a confirmations finality rule |
| **Tempo** | EVM L1 | USDCe (TIP-20) | EVM token-transfer detection, same proven path as Base, parameterised for Tempo |
| **Solana** | Solana | USDC (SPL) | Signature scan plus token-balance-delta confirmation at the chosen commitment |
| **Algorand** | Algorand | USDC (ASA) | Asset-transfer detection via the indexer, with Algorand instant finality |
| **VOI** | Algorand-family | Native VOI | Native-payment detection via the AVM indexer |
| **Hedera** | Hedera | USDC (HTS) | Token-transfer detection via the Mirror Node, native Hedera finality |
| **Stellar** | Stellar | USDC | Payment detection via Horizon, exact 7-decimal asset amounts |
| **Arc** *(from 16 Sep 2026)* | EVM L1 (Circle) | USDC (native gas) | EVM token/native-transfer detection, same proven path as Base; 18-decimal native-USDC scaling handled internally |
Each chain takes its RPC or indexer endpoint from configuration (bring your own node, with
sensible public defaults), applies that network's confirmation and finality rules, and feeds the
same engine and the same receipt format. Every network is present out of the box, so there is no
per-chain integration to add.
Five of the seven chains have been validated **end to end on live networks** (Base, Algorand,
VOI, Hedera, Stellar): a real on-chain settlement detected and turned into a receipt that
verifies offline in the Command Center. Solana and Tempo are validated against their settlement logic and
go live with a keyed RPC endpoint for those networks.
These are the chains the gateway **settles and verifies** x402, MPP, and AP2 on (seven live today, Arc from 16 Sep 2026): it detects the
on-chain transfer and applies that network's finality rules, which needs a per-chain verifier. Peer
**agent-to-agent settlement is not limited to these seven**: because it only writes a
32-byte anchor and never verifies the payment on-chain, two agents can anchor an agent-to-agent reference on whichever
chain they both agree on, Arc included. The two are different jobs: the rails verify a settlement on the
seven live chains (Arc from 16 Sep 2026); agent-to-agent settlement records an agreed reference on whichever chain the agents pick.
## One engine, one port
All seven chains (Arc from 16 Sep 2026) run in one engine as **one process on one port (8090)**. You do not get a service
per chain. A request names its `network`, and the engine routes it to the matching handler. Every
network lives in the same service; there are no extra ports, processes, or moving parts to operate.
See the [ports and interfaces reference](/substrate-2-ports) for where it sits in the suite.
The service exposes a small, stable HTTP surface: create an intent, check an intent, list the
installed chains, report health, and export the signed settlement pack for the Command Center.
There is no SDK to adopt and no shared library to pin; any backend in any language talks to it
over plain HTTP.
## White-label: your own domain and identity
You run the rails on your own domain, and they present as **you**, not as us. One setting,
`GATEWAY_PUBLIC_URL` (which the installer sets to your domain), reconfigures every public surface to
your identity with no per-endpoint configuration:
* the A2A agent card and its signature,
* the `did:web` document (`did:web:pay.yourco.com`),
* the RFC 9116 `security.txt` contact,
* the compliance attestation and its operator identity,
* the x402 and MPP discovery documents.
No AlgoVoi identity, endpoints, or references appear anywhere on your deployment. The agent card can
be signed with a key you generate and hold, verifying against your own JWKS. Set your organisation
name or security contact with a single optional variable each, or leave the sensible per-domain
defaults. It is a genuine white-label deployment out of the box.
## Install in five minutes
One command brings the whole stack up under systemd behind automatic TLS:
```bash theme={null}
sudo ALGOVOI_DOMAIN=pay.yourco.com ALGOVOI_ACME_EMAIL=ops@yourco.com \
bash enterprise-setup.sh --license @licence.key
```
Every service installs as a hardened, auto-restarting systemd unit behind Caddy with HTTPS:
automatic Let's Encrypt when you set a domain, or a self-signed certificate for an air-gapped
install. The payment rails own port 443, so agents, payers, and facilitators reach you at
`https://your-domain` with no port; the operator and control panels sit on separate ports so admin
traffic never contends with live transactions. The bundle ships `GO-LIVE.md`, `A2A-AGENT-CARD.md`,
and the full [operator control panel guide](/operator-control-panel) with the walk-through, and
starts on SQLite so you are live in five minutes.
## Custody and payout
The gateway does both halves of a payment: it detects and proves inbound settlement, and it signs
and broadcasts outbound payouts. Custody is **operator-held**: the signing key for each chain lives
on your own infrastructure, supplied by environment and never by AlgoVoi, and a payout is fail-closed
if no key is configured. `POST /v1/payouts` signs and broadcasts on the chain you name and returns a
no-PII `gateway_payout` receipt (Falcon-signable, offline-verifiable) that folds into the Command Center
next to your settlement evidence. Operator-held custody is available across all seven chains; an HSM or KMS-backed signer
(the key never leaving the HSM) is the same interface, offered as a per-deployment option.
Optionally, a payout can be **bound to an authorizing decision**: configure the gateway to sign a payout
only against a fresh, valid ALLOW from the [Spend Guardrail](/spend-guardrail) for that exact amount and
destination. The authorizing decision is recorded in the payout receipt, so the evidence chain shows
authorized then settled as one provable sequence, and a payout with no valid authorization is refused.
## Defence in depth
The rails ship with a three-layer defence that is **active by default** the moment the service
starts: you do not switch it on, and an operator can pause any layer if it ever conflicts. Every
layer runs on your own infrastructure, and every decision it makes is Falcon-1024 signed and
offline-verifiable, the same evidence discipline as the payment receipts themselves.
| Layer | What it does |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **L0, perimeter firewall** | A `fail2ban` jail (`algovoi-edge`) bans offending IPs at the network edge, fed by the block decisions the runtime layer emits. |
| **L1, Substrate Guard** | Input byte-bounds and UTF-8 admission before any canonicalization, so malformed or oversized input is rejected before it ever reaches the signing path. |
| **L2, Edge Sentinel** | Runtime IP, geo, ASN, rate and replay admission, with each edge decision Falcon-1024 signed and persisted. |
The three layers compose. Edge Sentinel makes the runtime admission decision; its block decisions
feed the fail2ban jail, so a repeat offender is dropped at the perimeter rather than re-evaluated
on every request; and Substrate Guard bounds what any request can submit to the engine in the
first place.
### Operator security console
A **Security tab** in the [operator control panel](/operator-control-panel) shows the live state of
all three layers on one screen: which are active, the fail2ban jail status, and the list of
currently banned IPs. Each layer can be paused and resumed from the panel, and every change is
written to the signed audit chain. The panel drives fail2ban over a group-readable command socket,
so no `sudo` is involved and the hardened, `NoNewPrivileges` systemd units stay intact.
## Cryptography
* **Detection reads each chain's native signatures** (Ed25519, secp256k1, and so on): classical
cryptography inherent to the chains, not something the gateway supplies or replaces.
* **The receipts it produces are post-quantum signed** with the operator's own Falcon-1024 key through
Substrate 2, and canonicalised with JCS (RFC 8785) so the evidence is canonical and content-addressed.
A settled payment becomes evidence that survives the post-quantum migration.
## Who it's for
* **Merchants and platforms** that want to accept stablecoins across several chains on their own
infrastructure and keep an audit-grade record of every settlement.
* **PSPs and marketplaces** reconciling inbound settlements across heterogeneous networks who need
one engine and one evidence format rather than one integration per chain.
* **Regulated and agentic systems** that must prove, offline and after the fact, that a payment
finalised on-chain, to whom, and for how much, without exposing any personal data in the proof.
## What's in the bundle
One licence installs the whole stack as a single encrypted, offline-verifiable `.algv`:
* **The payment rails engine** across all seven chains: intent lifecycle, settlement and finality
detection, operator-held payouts, and the x402, MPP, and AP2 settlement protocols, with A2A
discovery, on one port.
* **The post-quantum Substrate 2 core**: Falcon-1024 signing, JCS canonicalisation, and the
receipt formats every settlement is signed with by the operator's own key.
* **The full keystone estate**: a federated agent-passport issuer with its own operator panel area
(issue, verify, revoke, CRL), the passport-to-journey lifecycle, the federation validator, the
zero-knowledge receipt service, and delegation refs.
* **Agent-to-agent settlement, federation-allocated**: allocate post-quantum agent-to-agent settlement to your own
federation members from the panel, with no per-agent fee, protected by an AlgoVoi root-signed
name-constrained delegation. Two-agent settlement quickstarts ship under `examples/mesh_a2a/`.
* **An active-by-default three-layer security suite**: a `fail2ban` perimeter firewall (L0) fed by
runtime block decisions, Substrate Guard input-bounds and UTF-8 admission (L1), and Edge Sentinel
runtime IP, geo, ASN, rate and replay protection with Falcon-1024 signed decisions (L2), all
visible and controllable from a Security tab in the operator panel.
* **Evidence and retention**: Command Center ingest and the hash-linked retention chain, so every
settlement folds into one offline-verifiable posture.
* **White-label deployment**: one setting reconfigures every public surface to your identity: did:web document, A2A agent card (signed with your own key against your own JWKS), x402 and MPP discovery documents, security.txt, and compliance attestation. No AlgoVoi identity, endpoints, or references appear anywhere on your deployment.
* **Operator-held custody and outbound payouts**: sign and broadcast payouts across all seven chains. The signing key lives on your own infrastructure; an HSM or KMS-backed signer (key never leaves the HSM) is the same interface. Optionally bind each payout to a Spend Guardrail ALLOW decision for that exact amount and destination, recorded in the receipt as an authorized-then-settled provable sequence.
The multi-tenant control plane, operator panel, and per-tenant isolation run it all. It starts on
SQLite for a five minute install and upgrades to PostgreSQL by import when you scale.
## Get the bundle
The rails ship as **one self-hosted bundle**: the gateway engine (intent lifecycle, signed
settlement evidence, the service, and the plugin framework), all seven chains, the full keystone
estate, the active-by-default three-layer security suite, and the post-quantum Substrate 2 core, on
a one-time perpetual licence. It is self-hosted and is not distributed on public package registries.
One licence installs the whole stack with all seven chains. Buy it on the [AlgoVoi
store](https://api.algovoi.co.uk/suite-store). For enterprise terms, [email us](mailto:hello@algovoi.co.uk).
## FAQ
Seven chains today: Base, Tempo, Solana, Algorand, VOI, Hedera and Stellar, all
in one engine on one port. Arc (Circle's USDC-native L1) is on the roadmap to go
live 16 September 2026.
No. It is fully self-hosted: it holds no account with us, makes no outbound call
to us, and never phones home. Every settlement receipt verifies offline against a
published key, with no service running.
No. Agent-to-agent settlement is a capability of the rails bundle,
federation-allocated from the operator panel with no per-agent fee. It is not
bought or licensed separately.