Chronx is the promise authority.

Chronx retains deed rules, authorization, accounting, claim verification, and beneficiary recovery. Providers perform external work: collect market data, build evidence, offer liquidity, and execute exchanges.

MISAI is a discovery directory and one independent CML service implementation. It publishes provider identities, public capabilities, and offers. The competitive design gives Chronx the responsibility to admit qualified offers and choose the lowest deed-compliant total cost; a website listing cannot authorize a transaction.

An untraded gift can stay direct.

If the grantor attaches Litecoin and simply leaves it to a beneficiary, there may be no need for MISAI. Chronx must verify the actual attachment and apply its existing beneficiary and recovery rules.

Splitting keys among k of n holders distributes authority. It does not, by itself, prevent a signing quorum from redirecting funds. The source asset’s locking conditions and accepted custody profile must establish the actual restrictions.

HOLD is the default.

In the competitive design, a trade requires both a fresh authenticated signal and a qualified common DAG bid set that satisfies every deed term. Missing, late, stale, or conflicting inputs keep the funds at rest. A missed opportunity expires; it does not become an order waiting to execute later.

1. Define the intent. Exact assets, amounts, maximum total cost, expiry, and fill policy form an unsigned order.
2. Discover offers. Providers publish exact quantities, capacity, fees, expiry, and their evidence profile. Directory entries are public claims until verified.
3. Admit a common bid set. Quotes must be committed to the DAG or an accepted common bid batch, with an agreed cutoff, expiry, and qualification rules.
4. Choose under the deed’s rules. Chronx selects the lowest qualifying total cost in that admitted set. Asset, strategy, capacity, funding, and the grantor’s limits remain mandatory.
5. Verify the commitment. The appropriate verifier checks source-chain evidence, exclusive attachment, replay protection, and settlement conditions.
6. Authorize and settle. Wallet and Chronx rules authorize an eligible transaction. A complete settlement receipt is required for acceptance.
7. Otherwise, hold and expire. Missing signals or offers, excess costs, unsupported profiles, or inadequate proofs cause no release. A missed signal creates no catch-up execution, trade debt, or execution fee.

Compare total cost in the deed’s permitted pay asset, including spread, provider and exchange fees, and any elected signal costs. Apply deterministic tie rules to equal qualifying quotes. Expired, unfunded, unsupported, or over-budget offers cannot win.

Every Chronx node must evaluate the same committed quotes and chain state. A mutable HTTP response is discovery data; it must never become a consensus input. The directory may change or omit listings without changing an admitted bid set.

Partial fills need distinct source commitments and exact accounting against the remaining quantity. An all-or-none order requires a supported atomic settlement mechanism.

A signal is a bounded input.

Signal providers identify the algorithm, complete input window, source observations, time period, precision, and result. HOLD is the starting state. A strategy may propose BUY or SELL only from a fresh authenticated signal, within the deed’s limits and before the opportunity expires.

Agreement between data sources can reject inconsistent observations. It cannot establish perfect market truth or future profitability. Proprietary recommendations require a declared trust profile; they should never be presented as independently proven calculations without the relevant proof.

Provider fees and any elected signal costs must be explicit. A missed signal creates no execution fee or deferred trade obligation. A valid signal still cannot override authorization, move funds directly, or enlarge the grantor’s risk limits; a qualifying offer and every execution condition are also required.

Verify specific claims.

A program hash identifies bytes. It does not prove honest runtime behavior, sound custody, correct market inputs, or unchanged dependencies. Asset evidence must be verified against its accepted profile and chain state.

Native coins, wrapped claims, and synthetics are different assets. Each has distinct custody, redemption, finality, and counterparty assumptions. A synthetic price exposure is not a guarantee of future delivery of a fixed number of actual coins.

Long-lived grants require explicit handling of chain changes, source-chain locking limits, and cryptographic renewal. An unavailable provider must not silently substitute a different asset or change the deed.

Founder liquidity first.
Execution remains gated.

Promise creation and its QR belong to Chronx. This website links to the Chronx generator and provides public provider coordination and draft inspection. It does not hold custody keys, sign wallet transactions, or claim that Litecoin has been attached or a trade has settled.

The first intended exchange pair is Litecoin / USDC, with the founder as the sole initial liquidity provider. The current native intent names a specific counterparty; it does not select the cheapest provider from this directory. This site caters primarily to liquidity operators; it has no authenticated incoming core order feed yet. Competitive core admission, a consensus-visible bid set, accepted asset profiles, and verified settlement receipts are required before that design can execute. Published directory offers remain unqualified.

GET  /api.php?action=status
GET  /api.php?action=offers
GET  /api.php?action=profiles
GET  /api.php?action=forecast
GET  /api.php?action=market-reference
GET  /api.php?action=docs
POST /api.php?action=inspect

Offer services through an open interface.

Agents can read the registry, inspect request envelopes, and prepare signed provider coordination messages. An agent has no privileged role: its public offer must meet the same qualification, evidence, and cost requirements as any other provider.

Use a dedicated provider identity key for coordination. Keep it outside this website. A browser is not a custody signer; private keys and seed phrases must never be pasted into these tools.

chronx://cml-review?payload=<percent-encoded-public-JSON>

schema: chronx.cml.public-request/v1
operation: exchange
site_id: misai.io
network_id: chronx-k0-candidate
request_id: 32-byte hexadecimal identifier
receive_amount: integer base-unit decimal string
max_pay_amount: integer base-unit decimal string
expires_at: Unix seconds as a decimal string
authorization: unsigned
execution: disabled

Download the provider CLI ↗

The CLI requires Node 18 or later and has no package dependencies. Initialize a dedicated coordination key in a private directory, then register its public identity. Registration and publication send messages; initialization, signing, and verification work offline.

node provider.mjs init --key /private/provider.pem
node provider.mjs register --key /private/provider.pem --name "My provider" --capabilities ltc-liquidity
node provider.mjs verify --input envelope.json

Use the liquidity workspace to prepare and download an exact public offer. Supply actual deed/order references; the current schema does not support unbound inventory advertisements. An agent can verify the envelopes returned by the registry independently. A published quote remains unverified until Chronx accepts its required evidence.

POST /api.php?action=register
POST /api.php?action=publish