Tokyo is the operative answer to JPY-tokenized liquidity under a regulated perimeter. One Zone, one Regime Template library at /regimes, and every cross-border distribution is opposable on Axone-1.

Why Tokyo, Why Now

Japan is the second-largest crypto-asset market in the world by retail participation, and the only major market where the regulator (the Financial Services Agency, under the Payment Services Act and the FIEA frameworks) has explicitly invited licensed digital-asset issuers to operate. Tokenized JPY stablecoins, JPY-denominated exchange-traded funds, and the FX rails that route yen into and out of regulated digital-asset venues all pass through Tokyo's institutional-finance stack. The FSA's sandbox guidance, and the JSDA's clearing annex for tokenized securities, have made Tokyo the natural anchor for the institutional side of the Axone Zone library.

The four sub-regimes Tokyo touches are not interchangeable:

  • → JPY stablecoin issuance — issuer-side eligible-issuer registration under PSA, with on-chain bank-trust proofs and a MoF / FSA audit surface. The most regulated stream, the bridge to the Programmable Yen.
  • → JSDA-cleared distribution — tokenized securities routed through Japan Securities Dealers Association member venues, with the JSDA clearing annex attaching to settlement on a regulated ledger.
  • → Cross-border yen liquidity — institutional FX routing between JPY and the major pairs, with city-bank counterparty paths and offshore-repo desks. The lowest-cadence, the highest notional.
  • → Audit-bound MoF / FSA reporting — the regulator-led audit surface: every regulated act is opposable, every counterparty is identified, every cross-border transfer is anchored. The threshold that turns a regulated venue from "compliant" to "audit-grade" is the same threshold the Regime Template encodes.

The regulator-side surface Tokyo sits in front of is heterogeneous on purpose. The MoF's macro-prudential lens reads the FX flow into and out of yen stablecoins and the systemic-balance footprint. The FSA's micro-prudential lens reads the eligible-issuer controls on a per-asset basis. The JSDA's market-side lens reads tokenized-securities distribution, and the cabinet's tax-side lens reads the consolidated friction model that drives whether tax-arb-shaped flows are even reportable as such. None of these lenses accept a CSV extract as the canonical record.

What the four sub-regimes share, what they don't, and what needs governing:

  • → Issuance perimeter is well-defined at the eligible-issuer registry and degrades the moment a stablecoin is wrapped. Wrapped JPY inherits none of the original issuance-control surface; the audit-grade ledger has to retro-fit one or refuse the route.
  • → Settlement stops being ambiguous exactly once a JSDA annex attaches. Above the annex, settlement is regulated; below it, settlement is a contractual choice. Wholesale counterparties can't tell the difference until the regulator surfaces the read.
  • → Disputes are real and they happen at the boundary, not the source. A cross-border yen route through a city-bank counterparty crosses the regulated threshold, but no shared ledger reflects that. The regulator who catches it is the regulator who did the audit, not the system that should have flagged it.

The trust model Tokyo inherited — a stack of consultancy-authored compliance briefs, per-counterparty MoUs, and quarterly FSA-sidecheck reviews — worked when there were five regulated venues. By the time there were fifty, it had stopped being a governance model and had become an inevitability model: the next breach would arrive, and the answer would be prepared after the fact.

The Zone Topology

An Axone Zone is a bounded framework of facts and rules — written in Prolog — that decides which acts become opposable inside it. An Axone Regime is the rule system itself: which counterparties are eligible, which issuance controls attach, what audit surface attaches to a transfer, and how a breach becomes a payable act against the regulated ledger. Tokyo operates on the same substrate the rest of the Zone library operates on, but the slots that govern are FSA-shaped.

For an institutional-finance operator under Japan FSA rails, three resource types are load-bearing:

  • → Counterparty resources — the eligible-issuer, JSDA-member, or city-bank counterparty, identified by a regulated-venue tag rather than a free-form legal entity. Each one carries an FSA-side dispatch slot, not a separate filings row.
  • → Asset resources — the JPY stablecoin, the tokenized security, or the FX-route derivative. Each carries the FSA-issuance tag as a slot, plus the JSDA clearing annex tag if the asset is a regulated security.
  • → Settlement resources — the act type that is, institutionally, the entire question. A counterparty receives an asset; the regime decides whether that act is opposable against the FSA-issuance ledger and the JSDA-cleared record.

The slots on a counterparty resource tell the rest of the story. slot(zone_id, atom) names the Zone. slot(fsa_eligible, atom) tags perimeter — only an eligible-issuer counterparty can clear a JPY stablecoin route. slot(jsda_annex, atom) attaches the JSDA clearing annex to a regulated-securities transfer, and slot(moj_audit, hex) is the cryptographic anchor for the audit-grade ledger submitted to the regulator.

The result is a Zone that knows, for every act touching its institutional-finance supply chain, which FSA-side rule applies — and which rule doesn't.

Regime Snippets

Below is an anonymized slice of the regime Tokyo runs. Counterparties are anonymous identifiers; assets are referenced by an asset_id atom; no eligible-issuer identity, no city-bank legal entity, no exchange specifics. Read against the /regimes regime-template library — the predicates below are the same shape as the Counterparty Onboarding, FSA-Reporting Audit-Log Feed, and IBC Opposable Dispute templates that ship on Axone-1.

prolog · Tokyo Institutional-Finance Zone Regime — Japan FSA / JSDA Elig & Settlement 
% ============================================================
% TOKYO INSTITUTIONAL-FINANCE ZONE REGIME
% JAPAN FSA / JSDA / MOF AUDIT-GRADE SETTLEMENT
% ============================================================

% ---------- ROLES (operator / counterparties / regulator) ----------

actor(tokyo_institutional_finance,   operator).
actor(counterparty_psa_eligible_issuer, eligible_issuer).
actor(counterparty_jsda_member_v1,    jsda_member).
actor(counterparty_city_bank_v1,          city_bank).
actor(japan_fsa_audit,                       regulator).

% ---------- COUNTERPARTY ELIGIBILITY (PSA / FIEA perimeter) ----------

slot(counterparty_psa_eligible_issuer, fsa_eligible,    psa_registered).
slot(counterparty_jsda_member_v1,    jsda_annex,       cleared_jpy).
slot(counterparty_city_bank_v1,          fsa_eligible,    offshore_repo_ok).

% ---------- ASSET SLOTS (issuance / audit surface) ----------

slot(jpy_stable_psa_2026q3, fsa_issuance,    psa_eligible_issuer).
slot(jpy_stable_psa_2026q3, moj_audit,       'b71e...d4').
slot(tokenized_jgb_v1,          jsda_annex,    cleared_jpy).

% ---------- COUNTERPARTY ONBOARDING (perimeter check) ----------

counterparty_eligible(Counterparty) :-
    slot(Counterparty, fsa_eligible, Perimeter),
    % perimeter_registered(Perimeter),
    \+ disputed(Counterparty).

% ---------- SETTLEMENT RULE (opposable regime) ----------

settlement_opposable(Counterparty, Asset) :-
    counterparty_eligible(Counterparty),
    slot(Asset, fsa_issuance, Scope),
    slot(Asset, moj_audit, Hash),
    \+ scope_mismatch(Counterparty, Scope).

% ---------- DISPUTE PRECONDITION (opposable act on Axone-1) ----------

opposable(settle(Asset), Counterparty) :-
    settlement_opposable(Counterparty, Asset).

% ---------- EFFECT: every qualified settlement is FSA-audit-grade ----------

effect(settle(Asset), Counterparty,
    logged(Counterparty, Asset, fsa_audit)) :-
    opposable(settle(Asset), Counterparty).

% ---------- QUERIES ----------

% ?- settlement_opposable(counterparty_psa_eligible_issuer, jpy_stable_psa_2026q3).
% true.

% ?- settlement_opposable(counterparty_jsda_member_v1, tokenized_jgb_v1).
% true                 -- JSDA-cleared; settlement logs to FSA-audit ledger.

% ?- effect(settle(jpy_stable_psa_2026q3), counterparty_psa_eligible_issuer, E).
% E = logged(counterparty_psa_eligible_issuer, jpy_stable_psa_2026q3, fsa_audit).

The regime does not police downstream use at the counterparty level — that is the eligible-issuer's contract, sometimes codified, sometimes implicit. The regime does police the handoff: every settlement act becomes a logged, opposable record whose FSA-issuance scope is a property of the act, not a footnote on a quarterly brief. The /regimes regime-template library carries this pattern as the reusable FSA-Reporting Audit-Log Feed template — the same predicate set, anchored against the originating Zone.

Opposability & Settle

Opposability is the property that turns the settlement record into something with effect. A counterparty who receives an asset is accountable for the terms under which they received it, not just for the receipt. A regulator who needs to inspect a settlement chain can pull the chain, not a spreadsheet extract.

When the zone-level regime encounters a settlement that should not have been opposable — an FSA-eligible mismatch, a missing moj_audit hash, a non-registered counterparty perimeter — the act is contested. The contestation protocol routes through Pactum, the Solidity settlement layer that ships on the Axone mainnet. Pactum turns the contested act into a payable event: a breach of eligible-issuer scope, a misrepresentation of the FSA-issuance tag, a settlement routed to a non-registered perimeter. The settlement runs against the regime and is executed on-chain — without a vendor ticket, without a regulatory motion.

Counterparty identity doesn't have to live inside the Axone chain. IBC settlement routes the dispute and the payable event to counterparties whose authoritative ledger lives on another chain (a city-bank core, an offshore-repo desk). The regime, the audit, and the settlement all reference the same act type — settle(Asset) — across the boundary.

This is the shape of the partnership Path: yes, but the architecture that backs it is not a forecast. The Pactum pattern, the IBC pattern, and the regime-as-audit pattern are the model — and the Regime Templates library at /regimes ships them as composable artifacts.

Outcome: Drift From FSA-Briefed Reporting to Audit-Grade Opposability

Tokyo's deployment consolidated the institutional-finance rail under a single Axone Zone. The shape of the result, in aggregate terms rather than named-testimonial form:

  • → One regime replaces per-counterparty compliance briefs. New counterparties onboard the same Zone; new settlements clear through the same rule; new FSA-issuance tags add predicates rather than new MOU artifacts.
  • → FSA eligibility stays attached to the asset. A JPY stablecoin tagged fsa_issuance carries that tag into the settlement record. Encoding perimeter into the slot replaces the trust-the-brief assumption.
  • → Counterparty scope is a property of the act, not a footnote on the contract. A settlement to an FSA-eligible counterparty under a psa_registered perimeter routes opposably; a settlement to the same counterparty under a non-registered perimeter routes — and triggers Pactum when it escapes.
  • → Audit-grade handover to FSA / MoF regulators via the auditability surface. The FSA auditor reads the same act history Tokyo reads; it doesn't need a separate regulatory portal to interpret a separate compliance surface.
  • → Operationally reproducible. The Regime Templates library turns the Tokyo FSA pattern into a typed, versioned artifact the institutional engineering team can revise and ship — without re-litigating the contract graph.

Tokyo did not promise the Japanese institutional finance system a miracle. It promised — and delivered — that the JPY stablecoin settled to a city-bank counterparty on Tuesday carries the same FSA-eligibility, the same JSDA-cleared audit trail, and the same MoF reporting scope as the JPY stablecoin settled on Friday. That is the threshold a regulated digital-asset rail crosses when it stops being a constellation of compliance briefs and becomes a governed service.

What Zone Builders Mean Going Forward

The Japan FSA-regulated institutional-finance rail is the most perimeter-sensitive rail an Axone Zone will plausibly run. If a regime can survive a city-bank counterparty, a JSDA clearing annex, an FSA-issuance tag, and a MoJ audit-hash ledger being read against the same Prolog file — every other institutional rail gets easier from there. The Zone Builder is the layer that makes that possible at scale: a typed, versioned, parameterizable artifact an institutional engineering team can ship and revise. The case study above is anonymized for a reason — the partnership is still being formalized. But the shape of the result is not a forecast. It is what already shipped, and the /regimes regime-template library is what lets the next FSA-shaped rail compose against it.