A lighter way to learn.
An intelligence network.

01 / LAYAI: a lighter way to learn

LAYAI is an AI × Web3 project building a Deep Agent, reusable knowledge capsules and a community compute network. Its goal is to make useful intelligence more accessible by reusing knowledge and activating the resources a task needs.

The project brings together four layers:

The long-term objective is an agent that builds on previous work instead of reconstructing every useful piece of context for every task. Development starts with capsule evaluation and local execution, then expands into a connected contribution network.

02 / Knowledge capsules and selective execution

A knowledge capsule is a versioned package of reusable information: condensed task context, reusable procedures, retrieval indexes and provenance. Its contents and format depend on the workload. A capsule is distinct from the model weights that execute the task.

Compress → Activate → Compute → Release.

1. Compress. Structure useful knowledge into compact capsules. Record the source, version, format and access rules.
2. Activate. Select capsules relevant to the request. Load the necessary working copies into the agent’s active context.
3. Compute. Execute the task with the chosen knowledge, model and tools. Record the result and resource use.
4. Release. Discard working copies that are no longer needed; reuse the available memory. The stored capsules remain available for later tasks.

Capsule reuse, context compression and selective execution are complementary techniques. Model loading is a separate implementation track. The research compares their combined end-to-end cost, including indexing, retrieval, loading and decompression. Any change to a capsule creates a versioned update rather than silently overwriting its source.

03 / Building the Deep Agent core

The first planned workload, capsule_eval_v1, evaluates whether selected knowledge capsules preserve useful task quality while reducing the context and resources needed for execution. A small model runs locally on supported hardware. The comparison uses the same task, model version and output settings.

Each result is tied to a task version, model digest, device profile and reproducible run. Benchmark reports will establish which configurations deliver useful gains. Performance figures are published with the measurements that support them.

04 / A contribution network for useful work

Current contribution service. Connect for Windows 1.0.25, the live account dashboard and the HTTPS research centre record eligible participation and bounded task results. Browser Connect has been tested locally in Chrome but is awaiting store publication. Android has passed an installation and launch check on a Galaxy S22; end-to-end sign-in and remote work still need validation. Capsule evaluation remains a separate upcoming workload.

The planned network distributes independent AI jobs according to device capability. Windows and Android are the first client targets. Larger models are assigned to workers with sufficient RAM or GPU memory as those workload classes are added.

The contribution journey is straightforward: pair a device → receive a compatible job → execute locally → submit a result → verify → record accepted work.

Participants set resource limits and control when their device runs. Job assignments specify model and task versions, download size, expected resources, time limits and verification rules. Device pairing and one account-level device view keep participation simple.

A scheduler matches the workload to the device. A project-operated verification service initially checks results through task-specific validation, reference runs or repeated assignments. Accepted work enters an append-only contribution ledger; disputed results follow a review process. The network’s initial coordination and verification services are operated by the project.

Devices contribute separate useful jobs. Their RAM does not automatically combine into one large model. Distributed execution of a single large model is a later technical track. The first network demand comes from LAYAI’s own capsule evaluation; external workloads can follow demonstrated capacity and demand.

05 / Blockchain and shared AI memory

Propose → Evaluate → Adopt → Reuse.

Participants test capsules; blockchain records the acceptance process.

LAYAI is developing a shared memory that agents can improve together. Blockchain is intended to coordinate which capsule versions enter that memory, under published acceptance and dispute rules. This connects the network’s computing work to the Deep Agent’s growing knowledge library.

1. Propose. An agent or contributor submits a new capsule or an improved version, identifying its source, prior version and intended task.
2. Evaluate. Network participants test quality and resource use against a defined baseline. Reports identify the capsule, evaluation method and execution conditions.
3. Adopt. The planned on-chain process records report commitments, evaluator signatures and disputes. A version becomes accepted for a stated task scope when the published review and acceptance conditions are met.
4. Reuse. Agents select accepted versions suited to their tasks and devices. Later findings can flag or retire a version, allowing clients to return to an earlier accepted version while preserving its history.

For example, a smaller coding capsule could enter shared memory after evaluations show that it meets the stated quality and resource criteria. Other agents could then reuse it without rebuilding the same task context. This develops the capsule library; updating that library does not automatically train model weights.

Computation off-chain; acceptance coordination on-chain. Capsules, model execution and test reports remain off-chain, with content hashes and references linking them to the registry. The chain records version relationships, acceptance states and review decisions. A hash identifies content; it does not establish its quality or guarantee its continued availability. Storage and retrieval remain part of the network design.

The intended benefit is a common update history and shared rules that independent participants can inspect and use. Evaluation remains responsible for judging usefulness; token holdings do not determine whether a capsule is correct. Initial coordination and evaluation are project-operated, with independent evaluators a later development step.

The first implementation scope is one capsule type and its proposal, evaluation, dispute and version-acceptance flow on the existing chain. This mechanism is in architectural development; the deployed testnet token does not yet implement it. Evaluator eligibility, acceptance thresholds, review periods and contract permissions will be specified before activation.

06 / A budgeted token economy

Fixed supply ceiling: 1,000,000,000 LAYAI · 18 decimals · BNB Smart Chain. The testnet token already mints this supply once; the mainnet token is not deployed. The allocation below remains proposed and has not been distributed on mainnet.

The token is intended to support accepted research contributions and future network service access. Account creation and device participation do not require buying it. There is no guaranteed yield, market price, listing or fixed points-to-token exchange rate.

Release discipline

• Contribution reserve: at least 60 months; a maximum budget of 70 million tokens per year. An approved period budget and verified eligible work are both required. Unused budgets remain reserved; this is not automatic emission or an entitlement.
• Research and operating treasury: 48-month planning horizon, milestone budgets and expenditure reports. Treasury tokens do not pay cash expenses unless a separately disclosed funding mechanism exists.
• Team: proposed 12-month cliff followed by 36 months of linear vesting from the declared mainnet start date. No immediate team unlock.
• Community: separate campaign budgets; the first distribution is proposed to use at most 10 million tokens (1% of supply), leaving 90 million for later campaigns. A campaign is not automatically launched by this document.
• Liquidity: 50 million reserved tokens, not an instruction to deposit all at once. Pairing assets, custody, pool parameters and lock policy require a separately funded plan.
• Funding: up to 10 million tokens in the first proposed round; the other 90 million are not part of that round. Later rounds need separate terms and disclosure.

Reserve wallets, vesting contracts, multisignature signers and spending authority will be published before activation. Team rewards and paid founder development must be disclosed separately to make total compensation visible. Proposed schedules require implementation and independent review; they are not enforced by the current testnet token.

07 / Development funding

Earliest decision window: Q2 2027 (April–June), subject to readiness. No active sale. A date on the roadmap does not open a funding round.

The first round is capped in planning at 1% of total supply. Price, funding targets and spending budgets have not been set; they must follow a costed research scope, operating data and review quotations.

Refunds, review periods, vesting and custody will be specified and tested together before accepting funds. Development spending, liquidity and ongoing reward liabilities need separate budgets. The test contract is not an active offer, and this whitepaper does not authorize a mainnet sale.

Opening gates: working public account service, a reproducible capsule evaluation, costed deliverables, independent contract review, documented custody and published participation terms. Missing a gate moves the date; a calendar target never overrides it.

08 / Delivery roadmap

Dates are development targets, not guaranteed launches. Quarter order matters: accounts and safe device execution precede capsule evaluation; reproducible evaluation precedes acceptance coordination; distribution follows published rules and funded, reviewed contracts. Presale timing is covered only in the funding section.

09 / Contributions, points and campaigns

LAYAI targets its first community airdrop in May 2027. This does not make current contribution points tokens or reserve a fixed amount for every participant. Qualification, distribution and appeal rules will be published before final eligibility is decided.

The account ledger separates checked availability, accepted work and community contributions. Android-only users can participate without a computer. The current Android candidate requires the app to remain open, charging and on unmetered Wi-Fi; it pauses on excessive temperature or low battery. It is not cryptocurrency mining or a promise of passive income.

Current contribution records are not redeemable tokens. No existing points are silently converted, repriced or erased by this proposal. Availability proves readiness checks, not that useful research was completed. A result passing a reference check is not a cryptographic proof of the physical device or its claimed energy consumption.

For a first campaign, a proposed fixed budget could be split 70% to accepted research, 20% to checked availability and 10% to reviewed community work. Eligibility, per-person limits, anti-duplicate rules and an appeal period must be published before final selection. An unused research sub-budget is retained if there are no tasks; it is not automatically transferred to idle time. Contribution weights are a proposal, not a change to the current point ledger.

Planning sequence: append-only monitoring snapshots on the first of every month at 00:10 UTC beginning October 2026; eligibility and review rules published before final selection; first claims targeted within May 2027 after audited claims and funded custody are ready. The exact claim day and final eligibility cutoff are not fixed. Monthly snapshots preserve records but do not automatically allocate tokens. Future campaigns depend on real demand and remaining reserves. Following a link alone does not verify social participation.

10 / Services and ecosystem access

The objective is repeatable capsule evaluation and useful service demand. Token distribution by itself creates neither research demand nor operating revenue. Service pricing, task budgets and settlement will be designed around measured costs; no artificial volume or guaranteed return is part of the model.

CoinMarketCap and CoinGecko application preparation follows a verified mainnet token, accurate project information and the relevant platform requirements. Acceptance and timing belong to those platforms. No exchange agreement or confirmed listing exists in this roadmap.

11 / Delivery status — 27 September 2026

Historical local contract tests are recorded in the test record. They do not certify this revised economic design or replace an independent review.

12 / What happens next

LAYAI has a live contribution service and a Windows client. The next research milestone is to publish a reproducible account of useful work completed on an independent device, followed by measured capsule evaluations. Results will be reported with their methods and limits.

The first community airdrop is targeted for May 2027 within the fixed 1 billion $LAYAI supply. Monthly monitoring snapshots begin in October 2026. Before final selection, LAYAI will publish the qualifying period, allocation method, final cutoff, review and appeal process, and claim instructions. Points preserve a contribution record; they are not a fixed token amount.

Before any mainnet distribution or funding round, LAYAI will publish the relevant contract addresses, independent review results, custody controls, unlock schedules and final terms. The participation terms cover the current service; project announcements appear on X, Discord and Telegram.