Meridian: a programmable, non-custodial settlement layer for institutional treasuries.

1. Executive summary

Meridian is a programmable settlement protocol for institutional treasuries operating across United States dollar (issued as Tether USD₮ on TON) and native TON. Treasury rules are expressed in TypeScript or natural language, compiled to deterministic on-chain commitments, and executed by a non-custodial agent under multisig authorization. Every action is recorded to TON and reconciled continuously across USD and TON ledgers.

The protocol holds no principal at any time. Funds remain in the client's multisig until the moment a signed instruction settles. Meridian's economic claim is a published basis-point fee per executed instruction — there is no spread, no rehypothecation, and no off-chain order book.

This brief does not constitute an offer to sell or solicitation to buy any security. Forward-looking statements about audits, listings, and partner relationships are subject to change as the protocol matures.

2. The problem

Treasury operations at most institutional scales are partially manual, partially scripted, and almost always reconciled retroactively. The friction is well known:

• Wires and ACH cannot express a rule. Anything programmable lives in custom internal scripts that are unaudited and difficult to govern.
• Reconciliation between fiat ledgers and any on-chain holdings is a quarterly exercise, often outsourced.
• Custodial rails impose a trust assumption — a third party holds the principal — that institutional risk teams already do not love.
• Stablecoin rails on most networks are settlement-grade in throughput but lack the policy primitives needed to express a treasury operation.

Meridian's hypothesis is that the unit of work for an institutional treasury is the policy, not the transaction. A programmable, deterministic, on-chain-verifiable policy layer compresses three weeks of monthly reconciliation work into a continuous signed audit trail, while preserving the constraint risk teams care about most: the principal never leaves the client's control.

3. Architecture

Meridian is composed of four primary components. Each is independently audited and addressable on-chain.

3.1 Policy verifier

A TON contract that holds the canonical hash of every active policy registered to a workspace. Before any executor can act on a policy, the verifier resolves the policy hash on-chain and confirms the executor has presented an instruction signed by the required quorum.

3.2 Treasury executor

A non-custodial agent that constructs and broadcasts settlement transactions. The executor is the only Meridian component that holds an operational signing key, and that key is restricted to executor-bounded actions (gas, broadcast). Value-bearing transactions require co-signature from the client's multisig.

3.3 Reconciliation indexer

An off-chain service that consumes the TON ledger and reconciles every settled instruction against the originating policy. Reconciliation reports are signed and published on a fixed cadence; clients can subscribe to per-instruction proofs by webhook.

3.4 SDK + console

The SDK is the developer surface for authoring policies, simulating against forked TON state, and registering compiled policy artifacts. The console is the operator surface for approvals, balances, audit, and reports.

4. Settlement guarantees

Meridian commits to four explicit settlement properties, each enforced by either contract logic or required multisig authorization.

• Determinism. A registered policy compiled at hash H will execute identically every run. Hash drift requires a signed multisig upgrade and a 24-hour timelock.
• Authorization. No instruction with monetary effect executes without the client's multisig. Every signature is recorded with the on-chain transaction.
• Verifiability. Every settled instruction emits a structured event including the policy hash, instruction id, counterparty, and the signed quorum. Indexers reconstruct the audit trail without trust.
• Bounded latency. The median end-to-end settlement time observed in the controlled-pilot cohort is 2.4 seconds. The protocol commits to a 12-second upper bound under nominal TON network conditions; otherwise, the executor surfaces a delay event.

5. Custody model

Meridian is non-custodial by architecture. A client onboarding to Meridian retains their existing multisig (Safe{Wallet} on TON, Fireblocks MPC, or hardware-backed cold storage) and registers it as the authorizer for one or more policies. The protocol's executor key cannot move funds; it can only co-broadcast a transaction whose value-bearing payload has already been signed by the client.

For fiat off-ramping, Meridian routes through licensed money-transmitter partners. The off-ramp partner's terms govern that leg. Meridian publishes the partner stack and material partner changes are surfaced in the security packet.

6. Threat model

The protocol's safety properties are stated explicitly. Each is enforced by either contract logic or multisig authorization, not by trust in any single operator.

• Compromised protocol team. Cannot move client funds, cannot modify executed transactions. Can propose contract upgrades; client multisig + 14-day timelock required to apply.
• Compromised single client signer. Cannot execute alone. Multisig threshold + 24h cooldown on rotation.
• Compromised RPC or indexer. Detectable. Settlement is verified against multiple independent TON nodes; divergence pauses the executor automatically.
• Compromised oracle. Two-source confirmation within tolerance; outside tolerance, queued for manual review.
• Regulatory action against an entity. Operating entities are jurisdictionally diversified across Cayman, Delaware, and Estonia; protocol logic does not depend on any single entity remaining operational.

The complete threat model — including censorship, key-rotation race conditions, and adversarial policy authoring — is included in the security packet (NDA).

7. Economics

Meridian's revenue is a published per-instruction basis-point fee. There is no spread, no taker fee, no liquidity-provision side. Forty percent of protocol revenue is distributed weekly to staked $MRD holders in USD₮; the remainder funds operating costs and the DAO-governed treasury.

• Fee curve. Tiered by monthly settled volume; published in the SDK and on-chain in the fee contract.
• No emissions. $MRD total supply is fixed. There is no inflationary token program funding distributions.
• Vesting transparency. Every vesting wallet is published; circulating versus locked supply is attested monthly by an independent firm.

8. Roadmap

Meridian is currently in private preview (cohort 02). The next milestones, as governed by the DAO when applicable:

• Q3 2026. SOC 2 Type II report. ISO 27001 pre-engagement. Module 1: payroll rails.
• Q4 2026. Public preview. Tier-1 CEX listings for $MRD. Module 2: FX corridors (USD ↔ regional fiat via partners).
• Q1 2027. General availability. Module 3: treasury credit facilities (collateralized, on-chain).
• Q2 2027. Bridged $MRD on EVM via the official TON bridge.

9. References

1 Volume figures cited on meridian.fi reflect aggregate throughput across all production policies for the trailing 30-day period ending on the date displayed and are derived from on-chain settlement records.

2 Audit reports referenced in this brief are published in the security packet and on the public security register at security.html#audits.

3 "Institutional review" in this document means the conjunction of an engineering security review, a finance reconciliation review, and an external audit firm review, as practiced by the design-partner cohort.