The Mass API

Introduction

Mass is the platform — the five primitives and every service built on them. Momentum is the fund that builds Mass and deploys it. The EZ Stack is the deployment package: Mass configured for a specific jurisdiction with lawpacks, adapters, and compliance rules. The mez CLI and {zone}.mez.network URLs use the abbreviation for Mass Economic Zone.

The Mass API provides programmatic access to institutional infrastructure across 30+ economic zones. Built in Rust on Axum 0.7, the API exposes 18 service families across five layers:

• Five primitives — Entity, Ownership, Fiscal, Identity, Consent
• Operational services — Tax, Documents & Signing, Governance, Licensing, Notifications
• Protocol infrastructure — Smart Assets, Corridors, Compliance, Trade, Credentials, Settlement
• Engines — Operations, Watchers, Arbitration, Policy Engine
• Government surfaces — GovOS, Regulator Console

The Mass SDK provides type-safe client libraries in TypeScript, Python, and Rust. All requests use JSON over HTTPS. The base URL for production deployments is zone-specific:

Base URLs

Versioning

All endpoints are prefixed with /v1. Breaking changes ship under a new version prefix. The current stack version is 0.4.44 GENESIS.

Content Type

All requests and responses use application/json. Artifact endpoints additionally support application/octet-stream for content-addressed binary data.

Authentication

The API uses Bearer JWT tokens signed with Ed25519. Tokens carry role claims that determine endpoint access. Include the token in the Authorization header of every request.

Roles

Scopes

Tokens include 22 fine-grained scopes following the {primitive}:{operation} convention: entities:read, entities:write, ownership:read, ownership:write, fiscal:read, fiscal:write, identity:read, identity:write, consent:read, consent:write, corridors:read, corridors:write, compliance:read, trade:read, trade:write, tax:read, tax:write, operations:read, operations:write, credentials:read, credentials:write, *:* (unrestricted). Empty scopes default to unrestricted for backwards compatibility.

Errors

The API returns errors in RFC 7807 Problem Details format. Every error response includes a machine-readable type URI, a human-readable title, the HTTP status code, and a detail string with context.

HTTP Status Codes

Entities

An Entity represents a legal structure — LLC, corporation, foundation, trust, or cooperative — formed within a zone. Entity creation triggers a 20-domain compliance tensor evaluation, provisions banking rails, and issues a decentralized identifier (DID) with a verifiable credential.

Creates a new entity in the specified zone and jurisdiction. The compliance tensor is evaluated synchronously. Banking rails are provisioned asynchronously.

Body Parameters

Retrieves a single entity by ID. Returns the full entity object including compliance status, banking rails, and DID.

Lists entities visible to the current token. Supports limit and offset query parameters. Default limit is 20, maximum 100.

Updates an entity with compliance orchestration. Name changes, jurisdiction transfers, and type conversions trigger re-evaluation of the full compliance tensor.

Triggers a cross-jurisdiction compliance evaluation against all 20 domains of the compliance tensor. Returns the tensor state and any failing domains.

Begins the 10-stage dissolution process. Requires operator role. The entity transitions through wind-down, creditor notification, asset liquidation, and final registry removal.

Ownership

Ownership represents cap tables, share classes, and equity transfers. Every ownership mutation triggers Securities and Corporate domain compliance evaluation, issues a verifiable credential, and updates the entity compliance passport.

Creates a new cap table for an entity. The cap table is a temporal data structure — every modification is recorded with an effective date, enabling point-in-time queries for any historical state.

Body Parameters

Retrieves the current cap table state. Supports as_of query parameter for temporal point-in-time queries.

Records an ownership transfer between shareholders. Triggers Securities and Corporate compliance evaluation, issues a VC attesting to the transfer, and emits a tax event for capital gains tracking.

Fiscal

The Fiscal surface manages treasury accounts, payment initiation, tax event recording, and withholding computation across 6 jurisdictions. Every financial write evaluates Banking and Payments compliance domains and updates the entity compliance passport.

Creates a treasury account for an entity. Currency is derived from the zone context. The account is linked to the entity compliance passport and evaluated against Banking domain rules.

Body Parameters

Initiates a payment. Evaluates Payments and AML compliance domains. Sanctions check is performed as a hard pre-flight gate — NonCompliant sanctions result is a legal-requirement rejection with no override.

Computes jurisdiction-aware withholding tax. Dispatches to rate tables for PK (S153/S149), AE, SG, US, GB, and IN. Returns the applicable rate in basis points, statutory section reference, and filer-status differentials.

Queries tax events for an entity. Supports filtering by event type (capital_gain, withholding, distribution) and date range.

Records a tax event and computes withholding. Creates an immutable tax event record with jurisdiction-specific rules applied. Returns the computed withholding amount and statutory reference.

Retrieves a specific tax event by ID. Returns the full event record including computed rates, statutory references, and filer/non-filer differentials.

Returns outstanding tax obligations for an entity across all jurisdictions. Aggregates withholding amounts, filing deadlines, and compliance status per tax authority.

Generates a tax report for authority submission. Produces jurisdiction-specific output formats: FBR XML (Pakistan), IRAS PDF (Singapore), IRS 1042-S (US). Returns report digest and submission receipt.

Lists loaded withholding rules for a jurisdiction. Returns rate tables, statutory section references, effective dates, and filer/non-filer differentials.

Identity

The Identity service handles KYC/KYB verification, national ID cross-referencing, and decentralized identifier management. Supports NADRA CNIC verification, FBR NTN tax status checks, and general identity attestation workflows. Each verified identity receives a DID and verifiable credential.

Verifies a Pakistani CNIC (Computerized National Identity Card) against the NADRA registry. Returns format validation, registry match, and sanctions screening results.

Body Parameters

Verifies a National Tax Number against the FBR IRIS system. Returns tax filing status and compliance classification.

Returns the full identity record for an entity, including all linked national IDs, verification sources, and the entity DID.

General-purpose identity verification. Routes to the appropriate national adapter based on jurisdiction: NADRA (Pakistan), MyInfo (Singapore), Aadhaar (India), Emirates ID (UAE), DVLA (UK), or SSN/EIN (US). Returns verification result with DID and verifiable credential.

Retrieves a specific identity verification record by ID. Returns verification history, linked credentials, and compliance status.

Returns identity service health status, configured national adapters, and supported jurisdiction list.

Consent

Consent encodes multi-party approval workflows. Board resolutions, shareholder votes, and regulatory sign-offs flow through typed consent objects with quorum rules. Each consent mutation evaluates DataPrivacy and Corporate domains.

Creates a new consent request. Consent objects are typed by operation — COMPANY_NAME_CHANGE, EQUITY_OFFER, ISSUE_NEW_SHARES, etc. The quorum rule determines how many parties must vote to approve.

Body Parameters

Returns the consent object including current vote tally, quorum status, and whether the consent has been approved or rejected.

Submits a vote from an authorized party. When the quorum is met, the consent transitions to approved and fires a callback event to the operation engine.

Revokes a previously cast vote. Only available while the consent is in pending state. Recomputes the quorum tally after revocation.

Lists consent requests for an entity. Supports filtering by status (pending, approved, rejected, expired) and operation_type.

Tax

The Tax service records taxable events, computes withholding at source, tracks obligations per entity, and generates authority-ready reports. Withholding rules are jurisdiction-specific: Pakistan uses FBR Income Tax Ordinance rates (filer vs non-filer), ADGM applies 0% corporate tax, Delaware follows IRC withholding schedules. Every payment through the Fiscal primitive automatically creates a tax event.

Records a taxable event and computes withholding. The tax pipeline identifies the applicable jurisdiction, looks up withholding rules, computes the amount, and records the obligation. Returns the computed withholding and net amount.

Body Parameters

Lists tax events with filtering by entity_id, event_type, jurisdiction, and date range. Supports pagination.

Returns a specific tax event including computed withholding, applicable rate, statutory basis, and linked fiscal transaction.

Dry-run withholding computation. Returns the withholding amount, applicable rate, and statutory reference without recording an event. Use this to preview tax impact before executing a payment.

Returns the cumulative tax obligations for an entity. Breaks down by category (income, capital gains, withholding, dividend) with amounts collected, amounts due, and filing status.

Generates a tax report formatted for the relevant authority. Pakistan: FBR return format. Delaware: IRC 1099 series. ADGM: economic substance report. The report includes all events, withholdings, and obligations for the specified period.

Lists loaded withholding rules for a jurisdiction. Returns rate tables, filer/non-filer distinctions, thresholds, and the statutory basis for each rule.

Documents & Signing

The templating engine is a first-class part of the API surface. Operations trigger document generation automatically: lawpacks define what documents each operation requires, who signs them, and in what order. The templating engine generates jurisdiction-specific PDFs, orchestrates multi-party e-signatures, and files completed documents with government registrars.

Document Lifecycle

Template selection → field interpolation from lawpack params → PDF generation → signing widget (Docuseal) → signer notification → signature collection → signed document storage (S3) → operation advancement. When all signers sign, the operation engine advances to the next step. If any signer declines, the operation halts with a document.declined event.

Create a signing request. Specify template types, signers with roles, and field values. Returns a submission ID with status awaiting_signatures. The signing widget URL is returned for each signer.

Track signing status. Returns per-signer status (awaiting, signed, declined), timestamps, and the signed document download URL (presigned S3, 1-hour expiry).

List available document templates for an entity, filtered by operation type and jurisdiction. Returns template groupings, required fields, and signing roles.

Template Groupings

Signing Roles

officer (president/secretary/CFO), recipient (counterparty), spouse (community property jurisdictions), witness, system (auto-signed). Roles are defined by lawpacks per jurisdiction. Delaware requires an officer signature; ADGM requires an authorized signatory.

Filing Adapters

Completed documents are filed with government registrars through typed filing adapters. Filing lifecycle: Submitted → UnderReview → Approved / Rejected / RequiresCorrection. Each filing receives a registrar tracking number and fee record.

Governance

Governance extends the consent primitive with cap-table-aware weighted voting, quorum enforcement, proxy delegation, and jurisdictional variance. Resolution types map to corporate law requirements: ordinary (simple majority), special (supermajority, typically 75%), extraordinary, board, and written resolutions.

Creates a new resolution. The kernel applies jurisdiction-specific defaults: Delaware (DGCL §216) requires majority of shares for quorum; ADGM uses articles-defined quorum with 75% for special resolutions; Seychelles (IBC Act 2016) permits written resolutions per articles; Singapore (Companies Act §179) requires 2 members for quorum.

Casts a weighted vote. Voting power is computed from cap table: share count × class weight. Proxy votes include the proxy_id of the delegated holder. The tally recomputes automatically after each vote.

Returns the current vote tally: votes for, against, abstentions, total eligible voting power, quorum status, and pass/fail determination against the threshold.

Registers a proxy delegation. A shareholder delegates voting authority to a proxy holder, optionally with voting instructions and an expiration date. Delegations can be scoped to a specific resolution or apply entity-wide.

Returns jurisdiction-specific governance defaults: quorum requirements and approval thresholds for ordinary and special resolutions.

Licensing

Government licensing and permit management across jurisdictions. Business licenses, building permits, professional certifications, VASP registrations, and trade permits flow through a unified adapter interface. Each jurisdiction’s licensing authority connects through the service bus.

Submits a license application with supporting documents. The compliance tensor evaluates the application before routing to the jurisdiction’s licensing authority. Supporting documents are referenced by ID from the templating engine.

Lists all licenses for an entity. Filter by category (business_license, building_permit, vasp_license, professional_license, trade_permit, financial_services_license) and status (applied, under_review, active, suspended, expired, rejected).

Renews an existing license. The licensepack tracks renewal dates and triggers compliance warnings before expiration.

Verifies whether a license is valid and active. Returns a boolean determination suitable for real-time compliance checks by corridor peers and government operators.

Lists available license categories for a jurisdiction. Seychelles: IBC, CSP, VASP, trade. ADGM: FSRA, commercial, professional. Singapore: MAS, BCA, ACRA. This is the API that answers: “What licenses can I issue through the platform?”

Notifications

The notification adapter dispatches email, SMS, and webhook notifications as part of the orchestration pipeline. Signing requests, compliance alerts, filing deadlines, and governance votes trigger notifications automatically. Webhook handlers receive callbacks from external services (DocuSeal signing completions, payment confirmations, registrar filing updates).

Dispatches a notification. Channel priority: email (always), SMS (time-sensitive: signing deadlines, compliance alerts), webhook (system-to-system). Notification types: signing_request, document_signed, entity_formed, compliance_alert, consent_required, renewal_reminder, filing_deadline, payment_confirmation.

Checks delivery status: queued, sent, delivered, failed, bounced.

Registers a webhook endpoint. External services (DocuSeal, payment gateways, government registrars) send event callbacks through registered webhooks. Webhook payloads are verified against a signing secret before processing.

Lists registered webhook endpoints and their event subscriptions.

Packs

The Pack Trilogy is the configuration layer that makes the kernel jurisdiction-aware. Three pack types define the rules, regulatory state, and license lifecycle for every zone. Governments define rules in packs; the kernel executes them.

Lawpack

Compiles legislative statutes into machine-readable operation step DAGs. Each lawpack pins to a jurisdiction and domain, is content-addressed via SHA-256, and defines what steps an operation requires, what documents are generated, who signs, what fees apply, and which registrar receives the filing. A lawpack for entity.rename in Delaware produces different steps than in ADGM: different documents (Certificate of Amendment vs Special Resolution), different signers (officer vs authorized_signatory), different fees ($150 vs $100), different registrar filings.

Regpack

Captures dynamic regulatory state that changes independently of legislation. Sanctions lists (OFAC, UN, EU, UK), license registries, reporting deadlines, enforcement priorities. The regpack feeds the compliance tensor. A regpack update (new OFAC sanctions entry) immediately affects the compliance tensor for all entities in all zones. Regpacks are versioned and hash-chained for audit.

Licensepack

Manages business license lifecycle across 15+ categories: business licenses, professional certifications, regulatory authorizations (CSP, EMI, CASP, custody, token issuer, exchange, fund admin, trust company). Tracks issuance dates, renewal deadlines, and compliance warnings. For Pakistan: SECP registration, SBP authorization, FBR NTN, PSEB registration, and 11 additional categories.

Smart Assets

A Smart Asset is a content-addressed financial instrument — equity, debt, fund unit, or real estate token — that carries its compliance state as a tensor. Assets are created with a genesis event, bound to a home harbor (jurisdiction), and can migrate across corridors while maintaining continuous compliance.

Creates a new Smart Asset. The genesis event is content-addressed: the asset_id is the SHA-256 digest of the canonical genesis payload. This makes the asset ID deterministic and verifiable.

Body Parameters

Evaluates the compliance tensor across one or more target jurisdictions. Returns per-jurisdiction binding status, allowed/denied determination, reasons, and missing attestations.

Proposes a cross-jurisdiction migration. The asset moves through an 8-phase saga: pre-flight check, source lock, exit attestation, corridor transit, entry attestation, target registration, source deregistration, and finalization. Returns a migration ID and corridor receipt.

Submits a Smart Asset registry verifiable credential. Binds the asset to a jurisdiction registry and issues a W3C VC attesting registration.

Returns the current view of a Smart Asset: genesis metadata, compliance tensor, home harbor, migration history, and all linked attestations and checkpoints.

Submits an attestation for an asset. Attestations are signed evidence documents (compliance evaluations, watcher signatures, registry confirmations) appended to the asset’s attestation chain.

Creates a state checkpoint for an asset. Captures the current compliance tensor, home harbor, ownership, and valuation as a content-addressed snapshot.

Verifies corridor anchoring evidence for an asset checkpoint. Confirms that the corridor receipt chain supports the claimed asset state transition.

Corridors

A Corridor is a bilateral compliance bridge between two jurisdictions. Corridors maintain a cryptographic hash chain of receipts using SHA-256 and Merkle Mountain Ranges (MMR). Every asset transfer, state transition, or settlement that crosses jurisdictions produces a corridor receipt appended to this chain.

Creates a new corridor between two jurisdictions. Initial state is DRAFT. Transitions through PENDING and ACTIVE require evidence gates (bilateral agreements, watcher bonds).

Body Parameters

Advances the corridor state machine. Valid transitions: DRAFT → PENDING → ACTIVE, with HALTED and SUSPENDED branches. Each transition requires evidence matching the gate specification.

Submits a new receipt to the corridor hash chain. The receipt links prev_root to next_root via the payload digest. The MMR root is updated and the chain height increments. Receipts are content-addressed and independently verifiable.

Lists corridors with pagination. Supports limit, offset, and state query parameters. Returns corridor metadata, current state, and chain height.

Retrieves a single corridor by ID. Returns the full corridor object including state machine position, hash chain root, watcher bonds, and bilateral agreement status.

Resolves a fork between two competing receipt branches. Selects the canonical branch using watcher attestation quorum and updates the MMR root.

Anchors a corridor commitment to L1 (Phase 2). Posts the MMR root and chain height as an on-chain attestation.

Computes finality status for a corridor commitment (Phase 2). Returns confirmation depth, anchor hash, and finality determination.

Corridor Peers

The peer protocol handles inter-zone communication for corridor proposals, acceptance, receipt exchange, and watcher attestation propagation.

Lists all known corridor peers. Returns zone IDs, connection status, and last-seen timestamps.

Retrieves a specific peer by zone ID. Returns peer metadata, supported corridor types, and attestation history.

Receives a corridor proposal from a peer zone. Validates the proposal against local policy, evaluates compliance requirements, and returns acceptance or rejection.

Receives corridor acceptance from a peer zone. Transitions the corridor from DRAFT to PENDING and initiates watcher bond collection.

Receives an inbound receipt from a peer zone. Validates the receipt chain linkage, verifies the MMR proof, and appends to the local chain.

Receives a watcher attestation from a peer zone. Verifies the Ed25519 signature, checks the watcher bond, and updates the corridor’s attestation quorum.

Compliance

The Compliance surface exposes the 20-domain compliance tensor, entity passports with tamper-evident hash chains, bilateral passport exchange outcomes, and decision proof materialization. Every write in the system feeds into this compliance state.

Lists all 20 compliance domains with their descriptions and jurisdiction-specific rule metadata. Domains include AML, KYC, Sanctions, Tax, Securities, Corporate, Custody, DataPrivacy, Licensing, Banking, Payments, Clearing, Settlement, DigitalAssets, Employment, Immigration, IP, ConsumerProtection, Arbitration, and Trade.

Returns the entity compliance passport — a materialized view of the entity's compliance state with a tamper-evident SHA-256 hash chain. Each evaluation extends the chain with prev_digest = SHA-256(previous_passport).

Verifies the structural integrity of an entity's compliance passport hash chain. Checks genesis correctness, chain invariant, terminal state consistency, and prev_digest format validation.

Verifies the mutation journal hash chain. Walks the in-memory chain recomputing event_hash via canonical bytes and verifying previous_hash linkage. Returns total entries, valid entries, and any chain violations.

Bilateral passport exchange between two entities. Computes mutual compliance across shared domains, produces a bilateral outcome, and materializes a decision proof as a verifiable credential.

Trade

Trade flows model cross-border commercial transactions across four archetypes: Letter of Credit, Open Account, Documentary Collection, and Structured Payment. Each flow progresses through a jurisdiction-aware state machine with compliance gates at every transition.

Creates a new trade flow. The archetype determines the state machine: Letter of Credit flows require document presentation and bank confirmation; Open Account flows track invoice lifecycle and payment terms.

Body Parameters

Returns the trade flow including current state, transition history, and compliance evaluation results at each gate.

Submits a state transition. Valid transitions are enforced by the archetype state machine. Each transition triggers compliance evaluation against Trade, AML, Sanctions, and jurisdiction-specific export control domains.

Attaches a trade document to a flow. Document types: bill_of_lading, commercial_invoice, certificate_of_origin, packing_list, insurance_certificate. Documents are content-addressed and linked to the flow’s compliance chain.

Lists trade flows with filtering by archetype, state, exporter, importer, and date range. Supports pagination via limit and offset.

Runs export control screening against EAR/ITAR (US), dual-use regulations (EU), and jurisdiction-specific restricted goods lists. Returns screening result, matched control lists, and required licenses.

Credentials

Every write operation in the system produces a W3C Verifiable Credential signed with Ed25519. The Credentials surface allows verification of any VC issued by any zone in the network.

Verifies a Verifiable Credential's Ed25519 signature and validates the embedded claims against the issuing zone's public key. Returns the verification result, the decoded credential subject, and any chain-of-custody metadata.

Body Parameters

Issues a compliance credential for a Smart Asset. The VC attests to the asset's current compliance tensor evaluation and is signed by the issuing zone's Ed25519 key.

Settlement

The Settlement service handles multilateral netting and cross-corridor routing. Netting computes optimal net positions from a set of bilateral obligations, reducing the number of settlement legs. Routing finds the lowest-cost path between two zones using Dijkstra over the corridor graph.

Computes multilateral netting across a set of obligations within a corridor. Returns the netting reduction percentage, net positions per party, and the minimum set of settlement legs.

Body Parameters

Finds the optimal route between two zones. Uses Dijkstra over the corridor graph weighted by compliance cost, latency, and fee. Returns the hop sequence, estimated total fee, and estimated transit time.

Generates ISO 20022 pacs.008 payment instructions from the netting result. Produces SWIFT-compatible XML messages with corridor receipt references for cross-border settlement.

Watchers

Watchers are bonded observer nodes that attest to corridor state. The watcher economy enforces honest attestation through a bond/slash mechanism: watchers post collateral to activate, earn attestation credit for honest observation, and face slashing for equivocation, false attestation, availability failure, or collusion. Four slashing conditions with severity ranging from 1% (availability) to 100% + permanent ban (collusion).

Registers a new watcher node. Initial state is Registered. The watcher must post a bond and activate before it can attest to corridor state.

Body Parameters

Posts collateral bond. Transitions the watcher from Registered to Bonded. Bond amount must be positive. The watcher can then activate for corridor monitoring.

Activates a bonded watcher. Transitions from Bonded to Active. The watcher begins monitoring corridor state and can submit attestations.

Records a successful attestation. Increments the watcher's attestation count. Only valid in Active state.

Slashes a watcher for protocol violation. Four conditions: Equivocation (100%), FalseAttestation (50%), AvailabilityFailure (1%), Collusion (100% + permanent ban). Transitions from Active to Slashed or Banned.

Begins voluntary unbonding. Transitions from Active to Unbonding. After cooldown, complete with /complete-unbond to reach terminal Deactivated state and reclaim collateral.

Arbitration

The Arbitration service manages cross-border dispute resolution through a 7-phase lifecycle with typed evidence gates at every transition. Supports 8 dispute types (breach of contract, payment default, delivery failure, force majeure, and more) and integrates with institutional registries including DIFC-LCIA, SIAC, ICC, AIFC-IAC, and Pakistan-specific institutions (ATIR, ADR Centre, KCDR).

Files a new dispute. Requires claimant and respondent DIDs, dispute type, jurisdiction, and claims with optional monetary amounts. Initial state is Filed. Every state transition produces a TransitionRecord with content-addressed evidence digest.

Body Parameters

Transitions Filed → UnderReview. Requires ReviewInitiationEvidence with case reference and institution acknowledgment digest.

Transitions UnderReview → EvidenceCollection. Opens the evidence collection phase with a procedural order and deadline.

Transitions EvidenceCollection → Hearing. Requires hearing date and tribunal composition digest.

Transitions Hearing → Decided. Records the tribunal ruling with a content-addressed ruling digest. The ruling can then be enforced.

Transitions any pre-decision state to Settled (terminal). Requires settlement agreement digest and consent from both parties.

Policy Engine

The Agentic Policy Engine evaluates environmental triggers against registered policies and produces scheduled actions. Twenty trigger types across six categories: regulatory environment, arbitration lifecycle, corridor activity, asset lifecycle, fiscal events, and entity/migration events. Deterministic conflict resolution guarantees identical outcomes across all nodes — higher priority wins, then jurisdiction specificity, then lexicographic policy ID as tiebreaker.

Submits an environmental trigger for policy evaluation. The engine evaluates all registered policies against the trigger, resolves conflicts deterministically, and returns matching policies and their scheduled actions.

Body Parameters

Lists all registered policies sorted by priority. Each policy defines a trigger type, optional condition predicate, action, authorization requirement (Automatic, Quorum, Unanimous, Governance), and jurisdiction scope.

Unregisters a policy. Future triggers of this type will no longer be evaluated against this policy. Existing scheduled actions are not affected.

Lists scheduled actions awaiting execution. Each action has a status (Pending, Executing, Completed, Failed, Cancelled), deadline, retry count, and authorization gate.

Operations

The Operation Engine is the kernel’s instruction decoder. It reads lawpack YAML definitions and decomposes high-level business intents into jurisdiction-specific step DAGs. Each step flows through the compliance pipeline: pre-flight tensor, sanctions hard-block, service execution, evidence storage, VC issuance, passport update.

Three Control Levels

Creates and begins executing a multi-step operation (Level 1). The engine builds a dependency DAG from the lawpack definition, topologically sorts steps, and drives all ready steps to completion. Supports compensation on failure and async event delivery.

Body Parameters

Dry-run (Level 2): builds and returns the full step DAG without executing. Shows dependency graph, topological order, interpolated parameters, async steps, ready steps, compensation coverage, and estimated fees.

Returns the operation state including overall status, per-step status (Pending, Ready, Executing, Waiting, Completed, Failed), step results, compliance evaluations, attestation IDs, and timing.

Advances the next ready step in the DAG (Level 2). A step is ready when all dependencies are satisfied. Each advancement flows through the full compliance pipeline. Returns the step result and updated operation state.

Delivers an async event to a waiting step. Operations span time — board votes take hours, state filings take weeks. When external processes complete, this endpoint advances waiting steps. Event types: consent.approved, document.signed, filing.accepted, verification.completed.

Lists all operation types available in the zone with jurisdiction coverage. Returns operation families and the jurisdictions each supports.

Returns jurisdiction-specific requirements for an operation type: step DAG, required parameters with validation, consent requirements, filing requirements (fees, authorities, timelines), and compliance domains.

Compares how an operation differs across jurisdictions. For each jurisdiction: step count, filing authorities, forms, fees, required documents, consents, compliance domains. The intelligence surface for jurisdiction selection.

Cancels an in-progress operation. Triggers compensation for completed steps as defined in the lawpack. Status transitions to compensating then compensated.

Regulator Console

The Regulator Console provides read-only access for regulatory authorities to inspect zone compliance state, query attestation history, and view aggregate dashboards. All queries are authenticated with regulator-scoped bearer tokens and return data filtered to the regulator's jurisdiction scope.

Returns the zone-wide compliance summary: total entities, entities by compliance status, domain-level aggregate statistics, and flagged entities requiring attention.

Queries attestation records with filtering by compliance domain, status, date range, and entity. Returns paginated attestation history for regulatory audit.

Full regulator dashboard view: compliance summary, recent attestation activity, active disputes, watcher health, corridor status, and alerts. Designed for rendering in the GovOS console interface.

Per-entity compliance posture. Returns the full 20-domain tensor evaluation, current status per domain, and attestation chain with timestamps and watcher signatures.

GovOS

The Government Operating System exposes zone-level dashboards for government ministries. Four console surfaces cover tax revenue and collection, free zone operations, citizen services, and the unified government console. Designed for integration with 40+ ministry interfaces across economic zones.

Unified government console. Aggregates compliance summary, revenue metrics, entity formation velocity, corridor throughput, and active alerts across all zone subsystems.

Tax revenue dashboard. Withholding collected, filing compliance rates, revenue by sector, and FBR IRIS integration status. Filterable by date range, entity type, and tax section.

Free zone operations dashboard. Entity formation pipeline, license issuance, visa processing, and zone-level compliance metrics. Designed for free zone authority control rooms.

Citizen services dashboard. Identity verification status, benefit disbursement, and public service delivery metrics.

Licensing and permits dashboard. For zones that build custom licensing systems on Mass APIs: building permits, VASP compliance, professional certifications, regulatory authorizations. 15+ license categories tracked. Renewal dates, compliance warnings, and fee collection. Role: zone_admin.

Console Access

Integration

Mass integrates with existing government digital public infrastructure through adapter layers. The five primitives and operational services act as a canonical data model — a shared vocabulary that the service bus enforces. No system talks directly to another. Everything routes through Mass.

Adapter Pattern

Each government system connects through a typed adapter. Adapters handle authentication, data transformation, error recovery, and retry logic for the target system. 12 national adapters ship with the platform. New adapters follow a trait interface and deploy as Kubernetes sidecars.

Integration Sequence

Identity first. The national identity system is the root of trust. Once identity is connected, entity formation can anchor to verified individuals. Fiscal follows (tax registration). Ownership and Consent compose on top. The sequence is: Identity → Entity → Fiscal → Ownership → Consent.

Deployment Options

Infrastructure Requirements

Minimum production deployment: 8 vCPU, 32GB RAM, 500GB SSD, PostgreSQL 16, Redis 7. Kubernetes 1.28+ or Docker Compose for development. 12 containerized services. Terraform modules for AWS VPC/EKS/RDS/KMS included.

MCP Tools

The Mass MCP Server exposes 17 tools via the Model Context Protocol (JSON-RPC 2.0 over stdio). Any MCP-compatible client — Claude, GPT, Gemini, or custom agents — can call these tools to operate sovereign economic zones. The tools cover the full operational lifecycle: discover, plan, execute, monitor, inspect, and act.

Discovery (2 tools)

Execution (3 tools)

Monitoring (3 tools)

Intelligence (2 tools)

Action (5 tools)

Query (2 tools)

Agent Workflows

The 17 MCP tools compose into jurisdiction-aware workflows. An agent discovers available operations, inspects requirements, plans or executes, monitors progress, delivers async events, creates entities and payments, verifies identity, and manages corridors. The Operation Engine handles jurisdiction-specific decomposition — the agent works at the intent level.

Incorporate a company

Compare jurisdictions

Monitor async operations

Compliance audit

Read Surfaces

Two intelligence tools give agents comprehensive read access across all five primitives. The underlying API also exposes zone state, compliance domains, and operation capabilities through standard REST endpoints that agents can query directly.

Entity Dossier

Compliance Passport

Zone and Operation Intelligence

Zone Setup

Initialize a zone from jurisdiction configuration to a running API server. The process is deterministic: a zone definition (jurisdiction stack + module manifest + profile) produces a fully configured deployment artifact.

Setup Sequence

Operation Kernel

The operation kernel decomposes high-level business intent into jurisdiction-specific step DAGs. This is the architectural insight that differentiates the EZ Stack: the same operation (entity.rename) produces different step sequences, different documents, different signers, different fees, and different registrar filings depending on jurisdiction.

How It Works

An operation request arrives with a type and jurisdiction. The kernel loads the lawpack for that combination, interpolates parameters, builds the step DAG with dependencies, and begins execution. Each step passes through the 20-domain compliance tensor. Async steps (consent collection, registrar filing) emit events that the engine watches for advancement.

Example: entity.rename

Delaware requires: name availability check → Certificate of Amendment (signed by officer) → filing with Division of Corporations ($150) → entity update. ADGM requires: name availability check → special resolution (75% shareholder approval) → Special Resolution document (signed by authorized signatory) → filing with ADGM-RA ($100) → entity update. Same operation. Different jurisdictions. Different step DAGs.

131 Operation Definitions

32 operation families covering: entity lifecycle (incorporate, rename, dissolve, amend), ownership (transfer, issue shares, record pledge), fiscal (open account, make payment, file return), identity (verify individual, verify entity, issue credential), consent (collect board resolution, collect shareholder vote). Each family has jurisdiction-specific variants.

Operational Independence

Government staff operate the platform independently by Day 90. This is a contractual deliverable.

Training Curriculum

Certification Criteria

Government team must demonstrate: (1) deploy a zone update independently, (2) configure a new license category, (3) process entity formation end-to-end, (4) investigate and resolve a compliance alert, (5) modify a lawpack when legislation changes. All five pass = operational independence certified.

Evidence

Próspera, Honduras: 87 days to full-stack deployment. 500+ entities formed. 7 corridors active. 47-second average formation time. Local staff operate independently. Momentum exited.