#Token Accounting and Settlement

Legra uses one native accounting and settlement unit across the complete data logistics route. It gives data, rights, compute, storage, services, outcomes, rewards, and corrections a common denominator while preserving who contributed what and why they are paid.

The public overview is at legra.ai/token. This guide explains the operational model.

#One token is the settlement quantum

One token (1 T) is the smallest positive amount Legra transfers and settles. Balances, reservations, prices, claims, commissions, credits, and rewards contain whole, non-negative integers.

The unit stays constant while resource prices change. One token is not fixed to a CPU cycle, a byte of storage, an API request, or any other single physical quantity. Versioned price tables translate class-qualified measurements into tokens:

• CPU, GPU, and accelerator time retain their distinct resource classes.
• Storage, retention, custody, transport, and bandwidth use their own measured quantities.
• Data, rights, capability, service, and outcome prices come from the applicable publisher or provider offer.

Measurements can accumulate below one token as exact pre-settlement quantities. Legra converts them once at the activity boundary. Fractional token balances and fractional settlement entries never exist.

Every operation uses pricing and token accounting, wherever it runs. A provider may publish a zero price for a service. That price applies only to that service: zero-priced compute or storage can still involve a worker calling a paid API. Running nodes yourself does not select a pricing mode or turn accounting off.

A positive charge goes from the funding wallet to the provider’s receiving wallet. If both are the same wallet, the charge and matching credit remain in its history with no net balance change. Different wallets transfer tokens even when you or your organization own both.

#Wallets hold tokens

A wallet is the only token account, and every wallet has exactly one token ledger. People and organizations, including the NetworkOperator organization, hold tokens in wallets. An organization can use several wallets and inspect combined totals; each wallet keeps its own balance and history.

Spending identifies the funding wallet and the person or service authorized to act for its owner. Acting for an organization does not automatically select the actor’s personal wallet. Monthly allowances credit the wallet designated in the signed agreement. Moving tokens between two wallets of the same organization is a real transfer; verified common ownership makes its commission zero.

#Competitive offers price each execution

A query has no permanent token price. Its quote belongs to one complete execution context:

P(query, plan, provider, offer version, validity window, rights, SLA)

For the same valid plan, Operator A can quote 80 T while Operator B quotes 100 T. Legra compares the complete landed price together with latency, reliability, placement, trust, capacity, and outcome requirements. Better hardware, a better algorithm, spare capacity, or a smaller margin can make one Operator cheaper. Stronger guarantees can make a higher offer preferable.

Provider offers take three common forms:

The NetworkOperator base table provides a reference for rating measured work. It is not a retail price or price floor. Operators can publish absolute offers and compete through rates, efficiency, capacity, margins, and service terms.

Authorization binds the selected offer or maximum for one execution. The settled amount then becomes permanent evidence. An 80 T settlement remains an 80 T historical fact. Repeating the logical query starts a new price decision against the current valid plans and offers.

#Prices change while the unit stays fixed

Compute and storage commonly become cheaper as technology improves. Operators publish new table versions and one token then buys more of that resource. Scarcity, demand, energy, and capacity can move a price in the other direction. Core admission and settlement always use exact integer tokens.

Versioning preserves the complete context:

1. The offer and price-table versions explain the activity’s token amount.
2. The Journal preserves the exact amount that was authorized and settled.

#Governed circulation supports a growing economy

Legra uses governed, elastic circulation. A fixed global token count would couple the capacity of the data economy to artificial scarcity. Authorized issuance expands circulation; retirement contracts it. The current supply is the exact result of those recorded events.

Every issuance or retirement record names its authority, principal, whole-token amount, policy version, economic basis or backing class, boundary evidence, and time. Network policy defines which issuers and bases are accepted. Ordinary settlement conserves tokens: it moves existing balances among principals and never issues or retires them.

The responsible issuer retains its source evidence. Downstream settlement entries do not copy that source record or attach a complete funding genealogy to each token. They record the immediate funding principal, recipient, claim, amount, and activity evidence. Tokens remain fungible under the applicable network policy.

Operators and NetworkOperators can retain earned tokens, fund later work, and clear mutual obligations entirely in tokens.

A usage quota or promotional authorization remains an authorization until it becomes a genuine transferable token through an explicit issuance event. Legra does not create tagged, second-class tokens that contaminate receiving balances.

#Every activity has a settlement graph

The familiar P(activity) formula describes the gross economic anatomy or the price from one participant’s perspective. The authoritative settlement is a graph of directed claims:

funding principal -> recipient principal : whole-token amount, claim, evidence

Every transfer edge has a positive integer amount. Explicitly zero-priced activity remains journal evidence without creating a transfer edge. A reward, refund, credit, rebate, or penalty changes direction. It does not create a negative token amount.

The caller is one role among several. In one activity, a person or Organization can simultaneously act as caller, data owner, rights-holder, provider, beneficiary, or sponsor. Its net position is a derived view:

net position = tokens received - tokens paid

The effective price has the opposite sign: tokens paid minus tokens received. It can be positive, zero, or negative. For example, a sponsor pays you 10 tokens to fetch an advertisement and the fetch costs you 2 tokens in resources: you earn 8 tokens, an effective price of −8. Quotes identify whose net price is shown and retain the separate resource charges and sponsor payments.

Every outgoing payment still needs authorization and funding before the work it pays for starts. A zero or negative net price never makes an unfunded dependency free. Sponsor terms establish eligibility and prevent duplicate reward claims; missing pricing or incomplete usage is not a zero price.

The ledger retains the directed positive entries behind that result.

#Sponsored activities can pay the caller

A mortgage provider can sponsor a quotation because temporary access to a prospective customer’s private financial data has business value. One purpose-limited activity might settle as follows:

Mortgage provider -> prospective customer : 150 T, temporary data rights
Mortgage provider -> services/Operators  :  35 T, quotation delivery
Mortgage provider -> NetworkOperator     :   5 T, network settlement

The mortgage provider funds 190 T. The customer pays zero and finishes with a net-positive 150 T position. The agreement binds the purpose, data scope, duration, permitted derivations, retention, and evidence requirements.

The same mechanism supports marketing and participation rewards. A sponsored button can invoke an activity whose infrastructure costs tokens while paying the end user a larger reward. The campaign reserves enough tokens for every claim before execution.

Sponsorship offers bind eligibility, purpose, validity, maximum claims, evidence requirements, uniqueness, rate limits, and exhaustion behavior. Expired, ineligible, replayed, exhausted, or underfunded sponsorship fails before resource-consuming work begins.

#Authorize, execute and prove, settle

#1. Authorize

Legra resolves the complete set of claims and funding principals. Each funder reserves its bounded outgoing amount. Missing prices, missing authority, insufficient balances, and unbounded spend without explicit authorization stop the activity before work.

#2. Execute and prove

The Task tree records the selected providers, offer versions, inputs, rights, resource measurements, outputs, and outcomes. The workspace Journal preserves the immutable evidence behind every claim.

#3. Settle

The settlement commits every directed entry atomically. Recipients receive the amount established by the selected offers and evidence. Unused reservations return to their funding principals. A partial settlement cannot pay one party while omitting another entitled participant.

#Monthly token allowances fund participation

Monthly token allowances supply a contracted quantity each month. Allocated tokens accumulate without expiry, reset, or inactivity deductions. Cancellation stops future allocations and preserves the existing balance. The agreement defines allocation and overage terms; it does not unlock feature tiers. Every Legra capability remains available on self-operated infrastructure.

Pay-as-you-go funding, sponsorship, earnings, and token packages all feed the same wallet and authorization model. The execution path only needs valid identity, applicable offers, sufficient authorized funding, and the resulting settlement graph.

#Accounting unit is a functional description

The term accounting and settlement unit describes the token’s role inside Legra. Applicable legal treatment follows the actual issuance, transfer, redemption, exchange, and custody mechanisms in each market. Product naming is not a legal exemption.

Continue with Activity Monitoring for the Tasks and Journal evidence, Events for domain provenance, and End-to-End Encryption for private data authority.