Docs / method, model card, limits

How the parser works.

How LAYA works, in plain words, one topic at a time. Switch to Technical for the full method, field names and commands.

What the desk observes, what GUARD checks, what the model answers, how you reproduce it, and what remains unproven. Written to be argued with.

Check every promise on Trust

Built with Nillion and Oasis ROFL

What powers LAYA

Rules first, words second, provenance alongside. Partner availability never changes the deterministic guard or the four typed answers. LAYA never trades.

Nillion nilAI / the explanation

nilAI writes verdict prose from the guard output and the four typed answers using its OpenAI-compatible API inside a TEE. Each new result records the returned model ID, or an explicit offline state. Nonce-bound attestation reports are retained when available and labelled unverified until checked independently.

It does not decide the guard, rescore the answers or provide token intelligence. The fixed guard and contradictions stay visible above its prose. The prose is not part of the exact-probability replay.

nilAI documentation ↗

Nillion SecretVault / private inputs

The SecretVault SDK encrypts and splits signal inputs across nilDB nodes. Optional private notes are stored separately, never included in public results or sent to nilAI. LAYA's server sees a submitted note and its operator holds the decryption seed. Public chain observations already present in results remain public.

Storage is not analysis, anonymity or a risk verdict. Missing credentials, rejected keys, exhausted credit and incomplete writes are reported plainly. No plaintext storage fallback is used.

SecretVault documentation ↗

Oasis ROFL / result signing

The ROFL app derives an Ed25519 key inside its TEE and signs the result hash. A Sapphire registry accepts a signing-key binding only from a transaction authorized as that ROFL app. The verifier checks the result signature, app identity, registry bytecode and key binding through Sapphire RPC.

The existing publisher signature remains. A publisher signature alone is not TEE attestation. Until the app, registry and funded instance are running and the binding verifies, the page says attestation pending. Verification trusts Sapphire RPC and the registered app's code policy. It proves signer provenance, not the truth or quality of a verdict.

ROFL app and attestation path ↗

Chain coverage: all three services process application data independently of chain. LAYA supplies observations from Robinhood Chain 4663 only. Nillion is not a 4663 indexer. Oasis uses Sapphire for app identity, key authorization and billing, not for Robinhood token coverage. Other input chains are refused.

Activation: missing keys show “Nillion offline, key pending”. An unverified signer shows “Oasis ROFL offline, attestation pending”. The home service panel checks the server and switches to live results when credentials and attested infrastructure are available.

How fast LAYA sorts

In the 200 most recent results from the signed feed generated on 30 September 2026 at 10:28:55 UTC, the median was 135.5 seconds from launch block to signed result. The 90th percentile was 160,389.4 seconds (44.6 hours). Older queued launches are included. These figures describe the published sample, not a promise for the next launch.

For each result, subtract observation.launch.timestamp × 1000 from Date.parse(issued_at). Sort the valid, nonnegative intervals. The median averages the middle two values for an even sample; p90 uses the nearest-rank value at ceil(0.9 × n). All 200 records in this sample had valid timestamps. Guard passes, vetoes and unknown results are all included.

This interval includes queueing, chain confirmation, observation, guard and model work up to result issuance. It excludes the later publication delay and browser loading. The feed signature was verified against LAYA's pinned Ed25519 public key.

The six-second lab animation is a walkthrough of one result. It does not measure the time LAYA took. No speed comparison with any other tool is claimed. Read LAYA's signed feed.

The pipeline

Every new token goes through the same five steps: spotted, read, checked by fixed rules, answered by the AI, then signed. Each step leaves a record the next one can be checked against.

One launch goes through five fixed stages. Each stage writes what it saw, so the next one can be checked against it.

StageWhat happensWhat you can check
ScanPons V2 launch events on Robinhood Chain, chain ID 4663, after twenty confirmations.Block number and hash in every result.
ObserveCurve trades, transfers, holders, reserves, creator history and bytecode, read at one block.The exact state JSON and raw evidence.
GUARDDeterministic checks. No model, no randomness.Each check with its status and evidence.
WeighThe open Laya checkpoint answers four typed questions on CPU.Every probability, the input hash and the weight hashes.
SignEd25519 over a canonical JSON string.Signature, key ID and content hash, in your browser.

What is observed

LAYA reads what happened on the chain for this token at one moment: trades, holders, fees, who created it and its code. It saves exactly that, so the input can never change later.

The scanner reads the official Pons V2 factory through the Robinhood RPC. It records TokenLaunched events, curve buys and sells, complete token transfers since creation, reserves and runtime bytecode. Twenty block confirmations and block hash checks reduce reorganization risk; they are not a finality guarantee.

Holder balances are rebuilt from transfers. Counts exclude the curve, the zero address and the burn address, and include other contracts. Early buyers are curve buy recipients, not transaction senders or routers. Creator history covers an explicitly recorded window, not the creator's lifetime. Token names never enter the model instructions.

GUARD

GUARD is a set of plain rules, not AI. It checks whether selling works, the fees, the creator, how concentrated the holders are and the code. If a rule fails, it vetoes, and the veto is shown above the AI answer. Passing is not a safety guarantee.

GUARD runs before the model and is shown above it. It is ordinary code with fixed rules, so the same state always gives the same result. A veto is never averaged with the model answer; the page shows both and says which one wins.

CheckWhat it looks at
Sell simulationAn eth_call sell at the recorded block. When allowances or missing holders prevent a clean simulation the check is unknown, which is a limitation and never a honeypot accusation.
FeesCreator tax and pool fee recorded for the launch.
Creator historyEarlier launches by the deployer inside the recorded window.
ConcentrationTop holder share and holder breadth.
BytecodeOpcode and selector presence such as delegatecall, selfdestruct and mint. Flags are heuristics and absence does not prove safety.

Every check reports its status with the evidence it used, or the reason it could not decide. The overall result is pass, veto or unknown.

Results issued before GUARD existed say so. The site never fills in a guard result after the fact.

A guard pass is not a safety guarantee. It means none of these particular checks failed at that block.

Four typed answers

The AI must answer four fixed questions in a fixed format: what research action fits, is risk elevated, which way is buying and selling flowing, and how spread out the holders are. Every probability is shown, including the options it did not pick.

  • Action, a choice: buy research, copy research, skip or pass. These are research labels, not orders.
  • Risk, a yes or no answer for elevated observed risk signals. It is not a verified rug probability.
  • Momentum, a score over selling pressure, mixed flow and buying pressure. It describes observed flow, not a price forecast.
  • Crowd, a choice: concentrated, broad or unknown.

All returned distributions travel with the result, including options the model did not pick. When the answers disagree, for example buy research alongside elevated risk, the disagreement is shown unchanged and counted on the scoreboard.

Results and signatures

Each verdict is sealed with a digital signature. Your browser checks that seal against LAYA's published key. A valid seal proves who published it and that nothing changed, not that the AI was right.

Each result is a canonical UTF-8 JSON string with sorted keys, its SHA-256 as the ID, an Ed25519 signature and the fingerprint of the publisher key. The bundled public key is the trust anchor. The browser checks the hash and the signature before it shows a verdict, and refuses to show anything that fails.

A signature proves which publisher signed these bytes. It does not prove truthful inputs, a correct model or an independently witnessed publication time. Public content hashes alone are not a blockchain timestamp.

Reproducibility

The AI model and its files are public and pinned to one version. Anyone can run the same model on the same saved input and must get exactly the same numbers.

The weights are open and pinned by revision and file hash. The input is the exact signed JSON. The runtime is pinned: CPU, float32, two threads, fixed library versions. Under those conditions the replay returns the same answers, and the largest probability difference must be exactly 0.

The Replay page walks through it: download the source and manifest, install the pinned runtime, verify the weights, run one command, and compare hashes and probabilities in your browser. The local verifier loads the weights in your own process, so no hosted inference is involved.

~/work/laya/.venv/bin/python tools/reproduce-local.py RESULT_FILE_OR_URL

Different hardware, GPU execution or other library versions can change the last digits or even the answer. That is why the runtime is part of the manifest.

How outcomes are measured

One, six and twenty four hours after each verdict, LAYA reads the price again and records it, whatever happened. These are price moves, not profits, because fees and slippage are left out.

At issuance the desk records a curve reserve ratio at its observation block. At 1, 6 and 24 hours after issuance it reads the first confirmed block at or after the deadline and keeps prices, block hashes and quote units. Each window ends as measured, pending, unavailable or failed. Graduation off the curve makes a price unavailable and it is counted that way, never as a win.

This is descriptive research, not a trading backtest. Returns are curve spot returns before fees and slippage.

Acting on a verdict

LAYA never trades for you. If you want to act, you get a live quote, read it, and confirm it in your own wallet. The AI saying buy is never a reason for the site to send a transaction.

The token page has an ACT panel for buying or selling from your own wallet. It connects through an EIP-6963 picker, so you choose the wallet. It reads a live quote from chain 4663, shows the expected and minimum output, and asks for an explicit confirmation before your wallet asks again. Approvals are for the exact amount only. If GUARD vetoed the token, the panel says so and asks you to acknowledge it before quoting.

LAYA never trades on its own, never holds funds and never asks for a private key. A model saying buy research is never a reason the site sends a transaction.

Model card

The model is the open Laya checkpoint by ConvAI, used exactly as published. Its exact files and versions are listed and fingerprinted. It has not been shown to be accurate for memecoins.

The model is the open Laya typed-decision checkpoint by ConvAI, used as published, without fine tuning on memecoin data.

Loading the pinned manifest.

Intended use. Structured research labels over an observed onchain state, with every probability published for inspection.

Not intended for. Automated trading, price prediction, or treating any probability as a chance of profit.

Calibration. The checkpoint's calibration does not establish calibration for financial outcomes. No accuracy is claimed until the scoreboard has enough measured outcomes, and even then the result will be reported as measured, not promised.

Limits

Some things LAYA cannot see: trades after a token leaves its curve, a creator's full history, or hidden logic in code. When a check cannot decide, it says unknown instead of guessing.

  • Only official Pons launches on Robinhood Chain are read. Uniswap V4 swaps after graduation are not covered in this version.
  • Creator history is a window, not a lifetime record.
  • Bytecode flags look for opcodes and selectors only. They cannot see privileged logic in general.
  • The sell simulation can be unknown when allowances or holder limits get in the way.
  • The feed is marked stale after six minutes without a new generation time. A stale feed is never shown as fresh.
  • Queue positions and wait times are observations, not promises.

$LAYA launch facts

$LAYA has not launched. Until a verified contract address appears here, anything called $LAYA is not it.

Reading token status.

Name LAYA, ticker $LAYA, planned venue Pons on Robinhood Chain. No contract address is published yet. The site will show it once the API returns a verified address. No launch date, fee recipient, tax or supply is announced here. Reading the desk never requires holding the token.

Disclosures

This is experimental research, not financial advice. The AI has not been proven accurate for memecoins. Memecoins can go to zero. Only use money you can afford to lose.

Built with Laya by ConvAI under Apache-2.0. Checkpoint convaiinnovations/laya. Pons event definitions come from the official contract repository and Pons V2 documentation. LAYA is not affiliated with ConvAI or TypeSafe.

Experimental research, not financial advice. Model probabilities have not been validated for memecoin outcomes. Memecoins can go to zero. Only trade what you can afford to lose entirely.

Download the LAYA source and replay tools. Publisher public key. API reference.

The interface components are ports of open-source work. See the credits and licences.