Foundation IP Bank • Product Paper

Real-World Asset Licensing for Athletes & Talent

A sovereign platform for managing, licensing, and settling portrait rights — built for the regulatory and commercial reality of athlete IP in Japan.
Partner: SoftBank Wallet: PayPay Q2 2026
Sandeep Casi  ·  Partner, Ibex  ·  Sandeep.Casi@ibex.now
01

The Problem

Athlete portrait rights in Japan sit at the intersection of personal consent, club ownership, commercial licensing, and cross-border media distribution. Today these rights are managed through spreadsheets, fax-based NDA workflows, and bilateral email chains. No single system tracks who has consented to what, which territories are licensed, or whether a campaign has actually run.

When an athlete transfers between clubs, the cascade of consent revocations, license suspensions, and settlement freezes is handled manually — often weeks after the transfer is complete. Infringement detection is reactive. Revenue settlement is slow and opaque.

IP Bank RWA replaces this with a single sovereign ledger: every consent, every license, every settlement instruction anchored to a cryptographic proof on Midnight — visible to the rights holder, auditable by the regulator, and invisible to everyone else.

02

Platform Architecture

The RWA instance is configured for high-sensitivity, low-autonomy operation. Every AI decision that touches consent, settlement, or disclosure requires human approval. The Midnight blockchain operates in PRIMARY mode — full Compact smart contracts, zero-knowledge proofs, and shielded settlement.

IP BANK RWA — PLATFORM ARCHITECTURE SURFACES Publisher Dashboard Buyer Marketplace Operator Console INTELLIGENCE Triton Operator Agent · 4 lanes Cortex System Oversight · 4 tiers ORCHESTRATION Foundation API Exclusivity Engine NG Rule Engine Batch Engine SERVICES IAM Settlement Tokenization Scout Fleet Analytics ADAPTERS Midnight PRIMARY mode PayPay Wallet CloudSign e-Signature LOGOS Event Bus Memory Agent Registry Cost Tracker Self-Learning Nervous system — every layer connects through LogOS HIGH SENSITIVITY · LOW AUTONOMY
Six-layer platform architecture — every layer communicates through LogOS, the platform's nervous system
03

Foundation-AI: The Intelligence Platform

Foundation-AI is the AI operating system that powers every intelligent behaviour in the IP Bank. It is not a chatbot bolted onto a database. It is a multi-agent architecture where specialised AI systems — Triton, Cortex, the Scout Fleet, and the Aristotle domain engine — operate as a coordinated organism, each with defined capabilities, strict autonomy boundaries, and a shared nervous system called LogOS.

Triton: The Operator Agent

Triton is the user-facing intelligence layer. It receives every query — from a rights holder asking about their revenue, to a licensee searching for available IP, to an operator checking system health — and routes it through one of four specialised lanes: inquiry, rights search, operations, or workflow. Each lane carries its own Semantic Airgap configuration. An inquiry about public market trends operates under PUBLIC_RESEARCH_ONLY. A workflow action involving a license grant operates under DENY — no external model touches the data.

Triton maintains cross-session collaboration memory: if a negotiation spans multiple conversations over weeks, Triton retains the full context without re-ingesting documents. Its prompt evolution system means that Triton's effectiveness improves with use — successful interaction patterns are crystallised into reusable playbooks, promoted across agent groups, and deduplicated at a 0.75 similarity threshold to prevent redundancy.

TRITON Inquiry Rights Search Operations Workflow PUBLIC_RESEARCH PUBLIC_RESEARCH DENY DENY SEMANTIC AIRGAP
Triton routes every query through a specialised lane — each with its own Semantic Airgap configuration

Cortex: System Oversight

Cortex monitors the entire platform through three operating modes. Reactive Red handles things that are broken now — auto-remediating Tier 2 actions like service restarts, settlement retries, and scout re-dispatches without human intervention. Proactive Amber detects things that will break soon — alerting operators and proposing remediation before failures cascade. Strategic Blue identifies how the platform gets stronger — suggesting configuration improvements, workflow optimisations, and policy refinements based on accumulated operational data.

Cortex operates under a four-tier action hierarchy. Tier 1 (observe) is unrestricted: monitor, correlate, simulate, propose. Tier 2 (reversible) is auto-executed: restart services, retry settlements, adjust thresholds. Tier 3 (approval-required) is proposed and held: schema migrations, policy changes, contract migrations wait for an operator to approve. Tier 4 (forbidden) is absolute: Cortex can never bypass the Semantic Airgap, weaken the audit trail, disable the circuit breaker, or reveal secrets. An independent watchdog — an unintelligent bash process running on a five-minute interval — kills Cortex entirely if it exceeds any threshold. The watchdog has no intelligence. It cannot be reasoned with. It is the final safety net.

OPERATING MODES REACTIVE RED Something is broken now PROACTIVE AMBER Something will break soon STRATEGIC BLUE How the platform gets stronger ACTION TIERS TIER 1 — OBSERVE Monitor · Correlate · Simulate · Propose TIER 2 — REVERSIBLE Restart · Retry · Dispatch · Adjust TIER 3 — APPROVAL Propose and wait for operator TIER 4 — FORBIDDEN Never. No exceptions. INDEPENDENT WATCHDOG Unintelligent bash · 5-min interval · kills Cortex on threshold violation
Cortex: three operating modes govern what to look for — four action tiers govern what it can do about it

LogOS: The Nervous System

LogOS is the connective tissue. It provides the event bus (asyncio queues in-process, Kafka across services), the memory system (episodic, semantic, hive, and graph), the agent registry (heartbeat-driven presence and capability discovery), and the deliberation protocol (multi-agent voting for high-blast-radius decisions). Every significant decision produces a DecisionTrace — a JSONL record of what was decided, why, what alternatives were considered, and what signals drove the outcome.

The cost tracker monitors ten distinct cost sources — from Triton's frontier model usage to Midnight gas fees to Kafka throughput — with EWMA-based anomaly detection that triggers warnings at 2x burn rate and critical alerts at 5x. For the RWA instance, where settlement values can be significant and a runaway agent could generate material cost exposure, this is not a reporting tool. It is a budget enforcement mechanism.

LogOS Nervous System Event Bus In-process: asyncio.Queue Cross-service: Kafka/MSK 8 topics · circuit breaker · DLQ Memory System Episodic · Semantic Hive · Graph Confidence scoring · decay Agent Registry Heartbeat · capability discovery 22 capabilities tracked Deliberation Multi-agent voting High-blast-radius decisions Cost Tracker 10 cost sources monitored EWMA anomaly detection 2x warn · 5x critical Self-Learning Signals · Model learning · Forgetting Playbook evolution · Aristotle Procedural memory · Strategy memory DecisionTrace JSONL audit log What · Why · Alternatives Signals · Outcome Redis Kafka
LogOS: six subsystems connected through a central nervous system — every agent, every service, every decision flows through it

Foundation Media Intelligence Engine

FMIE is the perception layer. It doesn't search — it sees. Every piece of media that enters the platform — a contract PDF, an athlete photograph, a campaign screenshot, a licensee's promotional video — passes through FMIE before it touches any other system. FMIE is the gatekeeper that determines what something is, whether it is authentic, and what rights attach to it.

The Media Passport

When an athlete's portrait rights are registered, FMIE produces a Media Passport — a comprehensive sidecar artifact that travels with the asset throughout its entire lifecycle on the platform. The Media Passport is not a single document. It is a structured bundle of machine-readable attestations, each generated by a different FMIE capability, each independently verifiable.

The passport contains the perceptual fingerprint (a mathematical representation of the athlete's visual identity that survives cropping, colour shifts, style transfer, resolution changes, and partial occlusion), the authenticity score (FMIE's confidence that the original media is unmanipulated), the sensitivity tags (face detected, PII present, biographical context inferred), the disclosure transforms (silhouette for F0, redacted for F1, full for F3+), the language detection result, and the lineage graph (a directed acyclic graph tracing every derivative version of the asset back to the registered original).

The Media Passport hash is anchored to the Asset Contract on Midnight at the point of registration. This means the passport's contents are cryptographically bound to the on-chain asset — any tampering with the passport after registration is detectable by comparing the current hash against the anchored proof. When a licensee receives an asset via the CDN Gateway, the passport is delivered alongside it. When the Scout Fleet detects a potential infringement, it compares the suspect media's fingerprint against the passport's registered fingerprint. When a dispute arises, the passport's lineage graph and authenticity attestations form the evidentiary foundation.

MEDIA PASSPORT Perceptual Fingerprint Authenticity Score Sensitivity Tags Disclosure Transforms Language Detection Lineage Graph (DAG) SHA-256 → PASSPORT HASH Anchored to Asset Contract on Midnight Registration Immutable after anchor
The Media Passport: six attestations bundled, hashed, and anchored to Midnight at the point of asset registration

Deepfake Detection & Media Authentication

Every piece of campaign evidence submitted by a licensee — screenshots of advertisements, recordings of broadcast spots, photographs of merchandise in-store — passes through FMIE's authentication pipeline before it is accepted as proof of campaign execution. The pipeline operates in three stages.

First, manipulation detection. FMIE analyses the media for signs of synthetic generation or post-capture alteration: inconsistent lighting and shadow geometry, compression artefact anomalies, frequency-domain signatures characteristic of GAN-generated imagery, splicing boundaries, and clone-stamp patterns. Each detected anomaly is localised to a specific region of the image or frame of the video, producing an authenticity regions map that shows exactly where and why FMIE's confidence drops.

Second, deepfake detection. For media containing faces — which is the majority of athlete portrait rights content — FMIE runs a dedicated face authentication pipeline. This compares the face in the submitted media against the registered fingerprint in the Media Passport, checking not just visual similarity but physiological consistency: skin texture continuity, iris reflection patterns, ear geometry, and temporal coherence across video frames. A deepfake that replaces an athlete's face with a synthetic version that looks visually similar will fail on temporal coherence — the micro-movements of a real face over consecutive frames follow patterns that current generation models cannot perfectly replicate.

Third, provenance verification. FMIE examines the media's metadata chain — EXIF data, encoding signatures, compression history — to determine whether the media has been re-encoded, screenshotted, or passed through a generative pipeline. A photograph taken with a camera and submitted directly will have an intact metadata chain. A photograph that has been passed through a face-swap model and re-saved will show a broken chain — even if the visual output is indistinguishable to a human eye.

The output of the authentication pipeline is a challenge bundle — a structured artifact containing the authenticity score, the anomaly region map, the deepfake analysis results, the provenance chain assessment, and FMIE's overall confidence rating. This bundle is stored in Alexandria as campaign evidence and referenced by the Scout Fleet's Campaign Verifier mission. If the authenticity score falls below the threshold, the campaign evidence is quarantined and the publisher is notified. The settlement associated with that campaign milestone is frozen until a human reviewer resolves the dispute.

Campaign Evidence 1 · MANIPULATION GAN signatures Splicing boundaries Compression anomalies Clone-stamp patterns → Anomaly region map 2 · DEEPFAKE Face vs passport match Skin texture continuity Iris reflection patterns Temporal coherence → Deepfake analysis 3 · PROVENANCE EXIF metadata chain Encoding signatures Compression history Re-save detection → Provenance chain CHALLENGE BUNDLE → Alexandria
FMIE authentication pipeline: three stages, each producing a distinct attestation, combined into a challenge bundle

The Media Passport and the deepfake detection pipeline work as a pair. The passport establishes what the authentic original looks like — its fingerprint, its provenance, its sensitivity profile. The authentication pipeline then measures every subsequent piece of media against that baseline. Together, they create a closed loop: the platform knows what is real because it registered the original, and it can prove what is fake because it can measure the distance from that original with mathematical precision.

Sensitivity Tagging & Graduated Disclosure

For the RWA instance, FMIE's sensitivity tagging is critical. Athlete imagery carries inherent PII — faces, names, biographical context. FMIE tags sensitivity levels and generates disclosure transforms: versions of the asset that can be shared at different phases of the licensing workflow without exposing the full original. A buyer at F0 sees a silhouette and metadata. At F1 (post-NDA), they see the full asset. This graduated disclosure is enforced by the Asset Delivery Gateway and gated by the Disclosure Contract on Midnight, not by trust.

Foundation-AI's defining principle for the RWA instance is low autonomy, high intelligence. The agents are extraordinarily capable — but every action that touches consent, settlement, or disclosure requires a human to approve. The AI proposes. The human disposes. The blockchain proves.

04

Midnight: The Trust Layer

Midnight is a privacy-preserving blockchain purpose-built for regulated industries. In the RWA instance, it operates in PRIMARY mode — the most comprehensive integration available. This means every significant state change in the platform is not merely logged but cryptographically anchored with zero-knowledge proofs that can be verified by authorised parties without revealing the underlying data.

Why Zero-Knowledge Proofs Matter for Athlete Rights

A talent agency needs to prove to a regulator that an athlete's consent was obtained before a license was granted — without revealing the commercial terms of the license. A licensee needs to prove to a brand partner that they hold a valid territory license — without disclosing the royalty rate. An investor holding IP Tokens needs to prove their holding is within the jurisdictional cap — without revealing the total number of tokens in circulation. Zero-knowledge proofs make all of these possible. The proof is mathematically verifiable. The data behind it remains shielded.

Smart Contracts (Compact)

Midnight uses a contract language called Compact, purpose-built for privacy-preserving business logic. In the RWA instance, Compact contracts are deployed across the full lifecycle:

01
Publisher Contract Deployed at onboarding. Holds the publisher's KYB proof, wallet binding, and IP registry. When a new rights asset is registered, it is added to the on-chain contract — creating an immutable record that the asset existed, was registered by this publisher, at this timestamp.
02
Asset Contract Deployed per rights asset at the point of registration. The Asset Contract is the on-chain representation of a specific piece of IP — an athlete's portrait rights for a defined scope. It holds the FMIE fingerprint hash, the consent record reference, territory restrictions, NG expression flags, and the asset's current lifecycle state (active, suspended, revoked). Every license grant references this contract, creating an auditable chain from the original asset registration through to every downstream commercial use. When consent is revoked, the Asset Contract state transitions to REVOKED and all referencing license grants are invalidated in the same Midnight transaction.
03
Buyer Contract Deployed when a licensee passes KYC. Holds their verified identity proof and wallet binding. This contract is referenced during license grant issuance to prove buyer eligibility without re-running verification.
04
Token Contract Deployed when IP Tokens are minted against a rights portfolio. The Token Contract is a child of the Asset Contract — it cannot exist without a valid, active parent asset. Minting, purchasing, revenue distribution, holding proofs, and redemption all execute as Compact transactions on Midnight. The holding proof is a ZK proof that a wallet holds tokens within the jurisdictional cap — verifiable by the regulator without revealing exact holdings. If the parent Asset Contract transitions to REVOKED or SUSPENDED, the Token Contract automatically freezes: no new purchases, no distributions, no redemptions until the asset state is resolved.
05
Disclosure Contract Manages the graduated disclosure workflow. Controls which phase of the licensing negotiation a buyer has reached, and gates access to asset delivery accordingly. Viewing keys are issued per-phase — F0 gets public metadata, F1 gets detailed profiles, F3 gets full contract terms.
PUBLISHER CONTRACT ASSET CONTRACT BUYER CONTRACT DISCLOSURE CONTRACT TOKEN CONTRACT LICENSE GRANTS Child of Asset — freezes if parent suspended/revoked References Asset + Buyer Invalidated on revocation KYC proof + wallet binding Phase gating: F0 → F1 → F3 holds Media Passport hash
Midnight contract hierarchy: every relationship is enforced at the protocol level — not by application logic

Shielded Settlement

When a royalty payment is settled through PayPay, the Settlement Service generates a settlement instruction that is anchored to Midnight as a shielded receipt. The receipt proves that a payment of a specific amount was made, from a specific buyer, to a specific rights holder, at a specific timestamp — but the amount, the parties, and the terms are all shielded. Only the rights holder (via their viewing key) and the regulator (via a separate regulatory viewing key) can decrypt the full details. Everyone else sees a valid proof and nothing more.

This is not encryption. Encryption hides data and requires trust in the key holder. Shielded settlement proves facts about data without revealing the data itself. The difference matters in regulated markets: a regulator can verify compliance without requiring the platform to expose commercially sensitive information to a third party.

PayPay JPY payment Settlement Service MIDNIGHT ZK proof generated Receipt shielded Rights Holder ✓ Full details via viewing key Regulator ✓ Compliance via reg key ✗ Third parties see valid proof only
Shielded settlement: the proof is public, the data is private — only viewing key holders can decrypt

Consent Anchoring

Every consent record — the athlete's agreement to license their portrait rights under specific conditions — is anchored to Midnight at the moment of creation. When consent is revoked, the eight-step Consent Cascade Orchestrator executes its saga and anchors the revocation as a new proof that references the original consent proof. This creates an immutable chain: consent granted → licenses issued → settlements made → consent revoked → licenses suspended → settlements frozen. The entire chain is verifiable. No single step can be forged, backdated, or deleted.

For athlete transfer scenarios, the Athlete Transfer Engine triggers a consent cascade that revokes all consents under the prior club and anchors the entire transfer as a single atomic Midnight proof. The new club's onboarding creates a fresh consent chain that is explicitly disconnected from the prior one — there is no inheritance of consent across club boundaries.

Consent Granted Licenses Issued Settlements Made Consent Revoked Licenses Suspended Settlements Frozen EVERY STEP ANCHORED TO MIDNIGHT — IMMUTABLE · VERIFIABLE · ATOMIC proof #1 proof #2 proof #3 proof #4 → refs #1 proof #5 proof #6
Consent chain on Midnight: each proof references its predecessor — revocation cascades are atomic and irreversible

Midnight Anchor Verifier

The Scout Fleet runs a dedicated Midnight Anchor Verifier mission every four hours in AUGMENTED mode. This mission compares the platform's database state against the Midnight chain — detecting any drift between what the platform believes to be true and what the blockchain can prove. If the database shows a license as active but Midnight shows the corresponding consent as revoked, the verifier flags the discrepancy as critical. This is not a nice-to-have monitoring feature. It is the mechanism that ensures the platform's operational state never diverges from its cryptographic truth.

Midnight's role in the RWA instance is not "blockchain for the sake of blockchain." It is the enforcement mechanism for a specific promise: that an athlete's consent is sovereign, that their commercial terms are private, and that the proof of both is stronger than the word of any intermediary.

05

Key Engines

NG Rule Engine

Japanese athlete portrait rights carry NG (No Good) expression restrictions — specific poses, contexts, or product categories that a talent agency has declared off-limits. The NG Rule Engine evaluates every incoming license request against the rights holder's declared restrictions before it reaches a human reviewer. A merchandise request for an energy drink campaign is automatically flagged if the athlete's NG list prohibits alcohol-adjacent branding.

Athlete Transfer Engine

When an athlete changes club, the platform triggers a consent cascade: all existing consents under the prior club are revoked, active license grants are suspended, pending settlements are frozen, asset delivery tokens are invalidated, and all affected parties are notified in their preferred language. The entire cascade is anchored to Midnight as a single atomic proof. The new club's rights holder is then onboarded and existing licensees can re-request under the new consent regime.

Exclusivity Engine

Before any license is granted, the Exclusivity Engine checks for conflicts — territory overlaps, category exclusivity, temporal collisions. A licensee requesting exclusive merchandise rights for Kanto cannot be granted if another licensee already holds non-exclusive rights for the same territory and category with a wider date range.

Consent Cascade Orchestrator

An eight-step idempotent saga that handles consent revocation across every dependent system — from license suspension through to Midnight proof anchoring. Each step is individually retriable, and the entire cascade can be replayed from any failure point without side effects.

1 · Revoke Consent 2 · Suspend Grants 3 · Cancel Requests 4 · Freeze Settlements 5 · Revoke Delivery 6 · Notify Parties 7 · Anchor Midnight 8 · Emit Complete Each step individually retriable · entire saga replayable from any failure point · zero side effects
Consent Cascade: eight idempotent steps from revocation to Midnight anchoring — zero grace period for RWA
06

Licensing Workflow

The platform supports both a fast-path flow for pre-approved templates and a full five-phase negotiation (F0 through F4) for bespoke deals.

F0 Lead Exploration F1 Post-NDA F2 Terms Proposal F3 Agreement F4 Operation DISCLOSURE None F1 F2 Full Full AIRGAP DENY PUBLIC ABSTRACT DENY DENY Disclosure and Airgap modes tighten after agreement — operational phases default to DENY
Five-phase licensing: disclosure expands through negotiation, then locks down for operation
F0
Lead Exploration Buyer discovers IP in the marketplace. Public metadata only — no confidential terms visible. Semantic Airgap in DENY mode.
F1
Post-NDA NDA issued via CloudSign. Once countersigned, the buyer gains access to detailed rights profiles, pricing history, and territory availability. Airgap shifts to PUBLIC_RESEARCH_ONLY.
F2
Terms Proposal Buyer submits a license request. Exclusivity Engine validates. NG Rule Engine screens. Triton assists with counter-proposal drafting under ABSTRACT_REASONING_ONLY mode.
F3
Agreement Terms finalised. License grant issued. Royalty rules attached. Midnight contract deployed with shielded settlement terms.
F4
Publication & Operation Asset delivery via signed CDN URLs with watermarking. Scout Fleet monitors campaign compliance, territory usage, and post-expiry asset recall.
07

Settlement & Tokenization via Midnight

Royalty settlement runs on PayPay rails with JPY as the primary currency. The Settlement Service calculates royalties automatically based on pre-configured rules, locks FX rates at the point of instruction, and retries failed settlements with exponential backoff. Every settled payment is anchored to Midnight as a shielded receipt — the amount is provable to the rights holder without being visible to third parties.

On-Chain Tokenization

IP Tokens are not database entries with a blockchain receipt. They are native Midnight assets. The entire token lifecycle — minting, offering, purchasing, distributing revenue, and redeeming — executes as Compact smart contract transactions on the Midnight chain. The platform's Tokenization Engine orchestrates these transactions, but the source of truth is the Token Contract on Midnight, not the platform's database.

This distinction matters. A token that exists only in a database can be modified by the database administrator. A token that exists on Midnight can only be modified by a valid Compact transaction signed by an authorised party. The platform cannot unilaterally alter holdings, redistribute revenue, or create tokens that violate the contract's minting rules — even if the platform's own database is compromised.

Fractionalised Asset Tokens

A talent agency registers an athlete's portrait rights as an Asset Contract on Midnight. The agency then deploys a Token Contract as a child of that Asset Contract, defining the total supply, the minimum and maximum holding per wallet, the jurisdictional gating rules, and the revenue distribution formula. The total supply represents fractional economic interest in the licensing revenue generated by that specific asset.

Tokens are offered to qualified investors (verified via the Buyer Contract's KYC proof). Each purchase is an atomic Compact transaction: the buyer's payment is confirmed on PayPay, the Token Contract updates the holding ledger, a holding proof is generated, and the settlement receipt is shielded — all within a single Midnight transaction. There is no window between payment and token allocation where the state is inconsistent.

Revenue distribution happens on a configurable schedule. When royalties are settled against the parent Asset Contract, the Token Contract's distribution function calculates each holder's pro-rata share based on their holding at the distribution snapshot. Distribution instructions are pushed to PayPay for settlement, and each payout is anchored as a shielded receipt. A holder can verify that they received their correct share using their viewing key — without seeing any other holder's payout.

Redemption & Lifecycle

Token redemption converts a holding back to settlement currency. The holder submits a redemption request, the Token Contract validates it against the redemption policy (minimum holding period, redemption window, remaining supply floor), and if valid, triggers a PayPay settlement instruction. The redeemed tokens are burned on-chain — reducing total supply and proportionally increasing the remaining holders' share of future distributions.

If the parent Asset Contract transitions to SUSPENDED (e.g. during an athlete transfer), the Token Contract enters a frozen state: all operations halt, distributions are deferred, and a notification is dispatched to all holders. When the asset is reactivated under a new consent regime, the Token Contract resumes — but any deferred distributions are recalculated against the new consent terms, not the old ones.

ASSET CONTRACT (parent) TOKEN CONTRACT (Compact on Midnight) MINT Deploy supply OFFER Jurisdiction gate PURCHASE Atomic on-chain DISTRIBUTE Pro-rata quarterly REDEEM Burn + settle PayPay settlement rail — every financial operation settles off-chain via PayPay, anchored on-chain via Midnight FROZEN STATE — triggered by parent Asset Contract suspension/revocation
Token lifecycle: every operation is a Compact transaction on Midnight — the Token Contract is a child of the Asset Contract
CapabilityImplementation
Settlement RailsPayPay JPY — QR payments, eKYC, P2P transfers, bank settlement
FX HandlingRate locked at instruction creation, multi-currency support
Token LifecycleMidnight Compact contracts — mint, purchase, distribute, redeem, burn
FractionalisationConfigurable supply, per-wallet caps, jurisdiction gating, pro-rata distribution
Proof AnchoringMidnight PRIMARY — every token operation is a ZK-proven on-chain transaction
Parent-Child BindingToken Contract inherits state from Asset Contract — suspension cascades automatically
ComplianceHolding cap enforcement, jurisdiction gating, consent-freeze cascade, redemption policy
08

Autonomous Monitoring

The Scout Fleet operates thirteen mission types, running continuously. For the RWA instance, the most critical are the Usage Monitor (crawling web and social media for unauthorised use of athlete imagery), the Campaign Verifier (confirming that licensees are actually running campaigns they've paid for), and the Cross-Border Monitor (detecting territory violations when Japanese-licensed content appears in unlicensed markets).

Scouts operate in three execution modes. LOCAL missions use only the on-platform media intelligence engine at zero model cost. AUGMENTED missions add a frontier language model for reasoning. AUTONOMOUS missions can spawn sub-scouts to pursue leads. All findings feed into the Hive — a peer-to-peer mesh that lets any scout's discovery benefit every other scout.

EXECUTION MODES LOCAL FMIE only · zero model cost Expiry Watcher · Settlement Reconciler · Token Health AUGMENTED + frontier model · budget-tracked Campaign Verifier · Compliance · Midnight Anchor AUTONOMOUS + sub-scout spawning · depth-limited Usage Monitor · Cross-Border · Market Intel · Evidence CRITICAL MISSIONS (RWA) Usage Monitor · 4h Crawl web + social for unauthorised athlete imagery Campaign Verifier Authenticate evidence via FMIE deepfake pipeline Cross-Border · daily Detect territory violations across markets + 10 more mission types HIVE — PEER-TO-PEER FINDING MESH Every scout's discovery benefits every other scout · similarity threshold 0.85 · critical push
Scout Fleet: thirteen mission types across three execution modes — all findings shared via the Hive mesh
09

Privacy & Compliance

The Semantic Airgap prevents any confidential rights data from leaking to external AI models. In DENY mode (the default for RWA), no external model call is permitted. When Triton needs frontier reasoning for a negotiation assist, it operates in ABSTRACT_REASONING_ONLY mode — sending surrogated terms rather than raw contract data.

DENY No external model call permitted. Default for RWA operations and workflow lanes. PUBLIC ONLY F0 public metadata only. No confidential terms. Marketplace browsing. ABSTRACT Surrogated terms — no raw contract data. Negotiation assistance at F2. RAW EXCEPTION Full data — requires explicit operator approval. Audit logged. Rarely used.
Semantic Airgap: four modes controlling what data can reach external AI models — DENY is the RWA default

All personal data handling complies with APPI (Japan's Act on the Protection of Personal Information) and GDPR for cross-border scenarios. The erasure protocol replaces content with [ERASED] markers, zeroes embeddings, and retains only an audit skeleton — the proof that something existed without revealing what it was.

The consent grace period for the RWA instance is zero days — revocation is immediate and irrevocable. This reflects the sensitivity of athlete portrait rights, where any delay between revocation and enforcement creates legal exposure.

10

End to End: From Onboarding to Fractionalised Token

The following traces the complete lifecycle — from a talent agency's first interaction with the platform through to an investor receiving their first royalty distribution from a fractionalised athlete portrait rights token.

01
Publisher Onboarding A talent agency registers on the platform. IAM Control creates a tenant-isolated environment with Row-Level Security. The agency completes KYB verification via PayPay eKYC. A Publisher Contract is deployed on Midnight — anchoring the agency's verified identity, wallet binding, and organisational structure. The agency configures team roles (owner, admin, finance, editor, viewer) and connects their PayPay settlement account. Cortex begins monitoring publisher health on a 30-minute cycle.
02
Asset Registration The agency registers an athlete's portrait rights as an IP asset. FMIE processes the uploaded imagery and produces a Media Passport — containing the perceptual fingerprint, authenticity score, sensitivity tags, disclosure transforms (silhouette for F0, full asset for F1+), and the initial lineage graph. The agency defines NG expression restrictions, territory availability, and consent terms. The athlete provides consent (anchored to Midnight immediately — zero grace period). An Asset Contract is deployed on Midnight as a child of the Publisher Contract — holding the Media Passport hash, consent reference, territory map, NG flags, and lifecycle state. The passport hash binds the registered original to the on-chain asset permanently. The asset is now live.
03
Marketplace Listing The asset appears in the Buyer Marketplace with F0-level disclosure: category, territory availability, and a sensitivity-masked preview. No commercial terms, no pricing history, no identity. The Semantic Airgap is in DENY mode — Triton can answer general marketplace queries but cannot reference any confidential data about this asset. Alexandria indexes the asset in its MARKETPLACE scope, making it discoverable via semantic search. The Scout Fleet's Market Intelligence mission begins tracking demand signals for this asset's category and territory.
04
Licensee Engagement A merchandise company discovers the asset and requests access. An NDA is issued via CloudSign in the buyer's preferred language. Once countersigned, the buyer's Disclosure Contract advances to F1 — revealing detailed rights profiles, pricing benchmarks, and territory availability. The buyer browses, evaluates, and submits a license request. The Exclusivity Engine checks for territorial and categorical conflicts. The NG Rule Engine screens for expression restrictions. Triton assists the agency with counter-proposal drafting under ABSTRACT_REASONING_ONLY mode. Terms are finalised at F3. A license grant is issued with royalty rules attached. A shielded Midnight proof anchors the agreement.
05
Asset Delivery & Operation The licensee receives high-resolution assets via CloudFront signed URLs with invisible watermarking tied to the license grant ID. The Media Passport is delivered alongside the asset. The Scout Fleet activates Campaign Verifier (running FMIE's deepfake detection and authentication pipeline on every piece of submitted campaign evidence before settlement is triggered), Usage Monitor (crawling for unauthorised use of the fingerprinted imagery), and Cross-Border Monitor (detecting territory violations). Campaign evidence that fails the authenticity threshold is quarantined and the associated settlement is frozen. Verified royalties are calculated automatically, settled through PayPay, and anchored to Midnight as shielded receipts.
06
Tokenization Decision With licensing revenue now flowing, the agency decides to fractionalise the asset. They define the token parameters: total supply (e.g. 10,000 tokens), minimum holding (10 tokens), maximum holding per wallet (500 tokens — preventing concentration), jurisdictional whitelist (Japan, Singapore, UAE), revenue distribution schedule (quarterly), and redemption policy (90-day minimum hold, 30-day redemption windows). Triton generates a summary of projected yields based on current and forecasted licensing revenue from the Analytics Pipeline.
07
Token Contract Deployment A Token Contract is deployed on Midnight as a child of the Asset Contract. The parent-child binding is enforced at the protocol level — the Token Contract inherits the asset's lifecycle state. If the Asset Contract is suspended or revoked, the Token Contract freezes automatically. The total supply is minted in a single atomic Compact transaction. The minting proof — recording supply, parameters, and the parent asset reference — is anchored and verifiable.
08
Token Offering Tokens are offered to qualified investors via the Buyer Marketplace. Each investor must hold a verified Buyer Contract (KYC-proven). The Token Contract enforces jurisdiction gating at the point of purchase — a wallet registered in a non-whitelisted jurisdiction cannot acquire tokens regardless of the buyer's KYC status. The offering is visible in the marketplace with the asset's F0 disclosure level; detailed financials (yield history, licensing pipeline, Scout Fleet compliance reports) are available at F1 post-NDA.
09
Atomic Purchase An investor purchases 200 tokens. The transaction is atomic on Midnight: PayPay confirms the JPY payment, the Token Contract debits available supply, the investor's holding is recorded, a holding proof is generated (proving the investor holds 200 tokens within the 500-token cap without revealing any other holder's position), and the settlement receipt is shielded. The entire sequence is a single Compact transaction — there is no intermediate state where the payment is confirmed but the tokens are not allocated.
10
Revenue Distribution At the end of the quarter, the Settlement Service aggregates all royalty receipts settled against the parent Asset Contract. The Token Contract's distribution function takes a snapshot of holdings, calculates each holder's pro-rata share, and generates distribution instructions. Each payout is settled through PayPay and anchored to Midnight as an individual shielded receipt. The investor holding 200 of 10,000 tokens receives 2% of the quarter's net licensing revenue. They can verify the calculation using their viewing key — confirming total distributable revenue, their holding at snapshot, and their payout — without seeing any other holder's data.
11
Continuous Governance The Scout Fleet monitors the asset continuously: Usage Monitor detects infringement, Campaign Verifier confirms licensee compliance, Midnight Anchor Verifier checks for state drift, and Token Health Monitor prevents oversale and flags distribution anomalies. Cortex watches the system. LogOS records every decision. Aristotle accumulates domain intelligence. The Renewal Engine generates license renewal offers based on performance data. The entire system operates autonomously — but every action that touches consent, settlement, or disclosure still requires a human to approve. The AI is the engine. The human is the pilot. Midnight is the black box.
END-TO-END WORKFLOW 01 ONBOARD KYB via PayPay eKYC Publisher Contract → Midnight 02 REGISTER FMIE → Media Passport Asset Contract → Midnight 03 MARKETPLACE F0 disclosure · DENY mode Alexandria indexes asset 04 NDA + ENGAGE CloudSign NDA · F1 disclosure Buyer Contract → Midnight 05 NEGOTIATE Exclusivity + NG screening Triton ABSTRACT mode 06 LICENSE Grant issued · royalty rules Midnight proof anchored 07 DELIVER CDN signed URLs + watermark Media Passport attached 08 SETTLE PayPay JPY · auto royalties Shielded receipt → Midnight 09 TOKENIZE Define supply · caps · jurisdictions Token Contract → Midnight 10 OFFER Marketplace listing Jurisdiction gating enforced 11 PURCHASE Atomic Compact transaction PayPay + Token in one tx 12 DISTRIBUTE Pro-rata quarterly payouts Shielded per-holder receipts CONTINUOUS GOVERNANCE Scout Fleet (13 missions) · Cortex (3 modes) · Midnight Anchor Verifier · FMIE deepfake pipeline · LogOS DecisionTrace MIDNIGHT — EVERY STEP ANCHORED · EVERY PROOF VERIFIABLE · EVERY CONSENT SOVEREIGN ■ Onboarding ■ Licensing & Settlement ■ Tokenization & Distribution ■ Continuous Governance
The complete lifecycle: 12 steps from onboarding to revenue distribution — three phases, all anchored to Midnight

This is the complete picture: a talent agency onboards in a day, registers an asset in minutes, reaches a global marketplace immediately, negotiates with AI assistance under privacy constraints, settles royalties in real time, fractionalises the asset into tokens governed by on-chain smart contracts, distributes revenue to investors with cryptographic proof — and the entire system is defended by an autonomous fleet of monitoring agents that never sleep. Every step is anchored. Every proof is verifiable. Every consent is sovereign.