Tokenized
hashing services.

The model connects a transferable digital token to measurable computing work. Customers commit tokens to request capacity, select a supported mining pool and provide their payout instructions. The chosen pool receives the work and pays mining proceeds directly to the customer under its own rules.

Two practical uses

Proposed product parameters

The service and product schedules define the contractual delivery standard, billing details and order conditions. A technical release must implement those terms consistently. The following sections describe the proposed operating model and the records needed to support it.

Activating a service request

A customer completes identity and wallet-authority checks, accepts the service terms and commits eligible tokens through the staking interface. Staking records a request for computing work. The request includes a supported pool endpoint, worker configuration and payout instructions.

The service provider allocates computing capacity to the request and routes the resulting work to the selected pool. Pool rules determine accepted work, payout thresholds, timing and fees. Customers can update supported routing instructions through the service interface, with changes recorded against the relevant request.

Allocating available capacity

The base specification is 1 TH/s for each active token. One TH/s means one trillion hashes per second. Capacity planning must support full activation of outstanding service entitlements. Actual delivery reflects availability, maintenance and the adjustment rules in the service schedule.

For each interval, a customer receives a share of eligible delivered capacity equal to their share of all active tokens. Eligible capacity is the verified hashing capacity available for customer work in that interval.

These figures illustrate the allocation formula. Capacity per token changes as eligible delivery and active demand change. A larger allocation also increases the electricity charge for that interval. If there are no active tokens, there is no customer allocation to calculate.

Measurement and service continuity

Allocation records link customer instructions, active token balances, eligible capacity and measured delivery to the same time interval. The service schedule defines metering tolerances, rejected-work treatment, corrections and credits. The proposed availability target is 95%, with a monthly measurement window and a hosting-credit remedy subject to the adopted service schedule.

Unstaking ends the associated service request and triggers settlement of accrued electricity charges. Transfers carry the remaining service and hardware rights, together with their existing exercise conditions.

Charging for delivered work

The proposed tariff is USD 0.065 per kilowatt-hour. The billing basis uses 9.5 joules per terahash and the operating time of delivered capacity. At that energy basis, 1 TH/s corresponds to 9.5 watts, or 0.228 kWh over 24 hours of continuous delivery.

The examples assume 24 hours of delivery and exclude any separately applicable taxes or transaction charges. Actual invoices follow measured delivery intervals. The energy figure is the contractual calculation basis; the billing schedule identifies any meter-based reconciliation, tariff adjustment and rounding rules.

Prepayment and the credit limit

Electricity is prepaid. The proposed policy also provides a credit limit equal to ten days of consumption at the applicable delivered-capacity rate. Customers receive usage and balance records so they can monitor the remaining balance and credit exposure.

When the limit is reached, computing delivery pauses and the unpaid bill enters settlement immediately. The proposed terms provide no additional cure period after the ten-day credit limit is exhausted. Service resumption and release of remaining tokens follow the settlement conditions.

Settlement through token cancellation

The settlement mechanism may cancel tokens against an unpaid electricity bill. Tokens are valued at the prevailing market price on a decentralized exchange (DEX) at the time of settlement. The settlement schedule defines the price reference and how it is applied to the bill and the token quantity cancelled.

Each settlement must record the unpaid amount, valuation reference, token quantity, cancellation event and credit applied to the bill. Recovery is limited to the outstanding balance. The schedule governs rounding, excess value, customer notice and disputes. Any recovery through released capacity is reconciled with token settlement against the same bill.

Cancelling tokens reduces the associated future service entitlement. After the bill is settled, remaining eligible tokens return unstaked under the service terms.

A fixed product right

The proposed hardware right permits 580 tokens to be used as the full token purchase price for one specified hydro-cooled miner rated at 580 TH/s. The adopted product schedule fixes the model, condition and token quantity for the token class. The hardware-purchase right expires on 31 December 2032.

The computing-service right continues under its own payment and service conditions. A transfer carries the existing hardware expiry date. Each customer receives the product schedule before placing an order, including warranty coverage and any freight, taxes or other delivery charges.

From order to delivery

Order request. The customer submits a hardware-purchase request and the required delivery instructions. The seller confirms eligibility, the fixed quantity and the product specification.

Written acceptance. The accepted order identifies the machine, condition, dispatch deadline, freight, taxes, warranty and the point at which ownership and transit risk pass. The proposed dispatch commitment is within 14 days of accepted order, subject to the conditions stated in the order.

Purchase locking. The required tokens enter a purchase lock. Their computing allocation ends, and the order record links the locked tokens to the accepted delivery obligation.

Cancellation and fulfilment. Token cancellation occurs at the contractual settlement stage. The accepted hardware-delivery obligation continues through cancellation. Dispatch and delivery records are reconciled with the order and token events.

Procurement and customer remedies

Fulfilment requires available inventory or binding procurement arrangements that support accepted orders and their dispatch deadlines. The capacity register must also reflect the service entitlements removed when tokens are used for hardware purchases.

The fulfilment terms address delayed or failed delivery, including release of locked tokens or restoration of equivalent entitlements where applicable. Any proposed substitution requires express customer agreement. The accepted order determines the warranty process and the allocation of transport responsibilities.

Separate records for separate obligations

An order remains traceable from acceptance to completion. The order record, token lock, cancellation, dispatch, delivery and remedy records establish whether the customer has received the promised product. Outstanding orders continue to be tracked if service arrangements change or a supplier is replaced.

States and permitted uses

The token lifecycle links each exercise of a service or product right to a recorded event. The following states describe the intended customer flow; implementation details are specified in the technical release.

Digital records and physical delivery

The proposed system combines token and program records with service operations. Token records establish balances and relevant commitments. The service interface records customer instructions. Allocation and billing systems connect those commitments to delivered hashing work, energy charges and settlement.

Mining pools process the work they receive and pay customers under their payout rules. Hardware fulfilment requires separate procurement, order and delivery records. Reconciliation joins these records so that a token event can be traced to the related service interval, electricity bill or hardware order.

Supply and capacity accounting

A capacity register supports the base service obligation at full activation and tracks eligible customer capacity, maintenance, contingency provision, hardware fulfilment and electricity-settlement uses. A token ledger distinguishes outstanding supply, active commitments, purchase locks and cancellations.

Supply reporting and capacity reporting must be read together. The deployment specification sets the total supply, circulation policy, mint controls and administrative permissions. Service capacity claimed for customers must be supported by delivery records and supply commitments.

Transfers and technical disclosure

Transfers use compatible wallets and available transaction infrastructure. Secondary-market execution depends on prevailing prices, liquidity, fees and venue rules. A recipient completes applicable onboarding and accepts the service or order conditions when exercising the token rights.

The technical release identifies the token and program, transfer and program fees, controllers, upgrade powers, lock and cancellation permissions, and recovery procedures. The interface explains the wallet permissions required for each action and presents the relevant transaction summary before approval.

Accountability for service delivery

The customer-facing service provider is responsible for the performance described in the service terms, including work supported by operating suppliers. Supply arrangements must cover committed capacity, hosting, electricity, maintenance, reporting and continuity of outstanding obligations.

Hardware orders create a separate fulfilment obligation with an identified contracting seller in the accepted order. Internal procurement and operating arrangements support that obligation and the customer remedies attached to it.

Records needed to reconcile performance

Customer information and access

Before purchase or service activation, customers receive the applicable service and product schedules, charges, token identifier and transaction conditions. Account information should make committed tokens, delivered capacity, accrued electricity and available balances understandable.

Onboarding establishes customer identity, eligibility and wallet authority. Operating controls cover screening, transaction monitoring, record retention and escalation of unusual activity. Access to customer and wallet information follows documented permissions and retention rules.

Changes and support

Material changes to service terms, tariffs, delivery arrangements or program controls follow the notice and consent requirements of the adopted customer contract. Published information, accepted terms and the technical release must remain aligned.

Support records track service, billing, transfer and hardware queries against the relevant transaction or operating interval. Complaints follow the stated response timetable. Continuity arrangements address equipment replacement, service interruption and the fulfilment or transfer of outstanding customer obligations.

Computing output and mining proceeds

Hashing work is a measurable service input. Mining proceeds vary with network conditions, pool performance, accepted work, fees and payout rules. Electricity and other charges affect the customer’s net result. A change in surplus allocation changes both delivered capacity and its associated energy charge.

Availability and equipment performance

Power interruption, cooling faults, equipment failure, maintenance and connectivity problems can reduce delivery. Measurement rules, contingency capacity, maintenance plans and service credits determine how these events are recorded and addressed. Long-duration service depends on continued equipment operation, replacement and supply performance.

Billing and settlement exposure

An unpaid electricity balance can pause service and result in token cancellation under the settlement policy. Customers therefore need clear balance information and an accurate statement of the credit limit. Metering errors, valuation errors or inconsistent settlement records can affect both the bill and remaining entitlements.

Hardware and transfer risks

Hardware fulfilment depends on procurement, inventory and dispatch performance. Product discontinuation, delivery delays and warranty disputes must be handled under the accepted order and its remedy provisions. Transfer execution can be affected by liquidity, transaction costs and market-price changes.

Wallet compromise, incorrect payout instructions, program defects and misuse of administrative permissions can cause loss or interrupt access. The technical release needs controls appropriate to those powers, together with a documented incident and recovery process.

Implementation requirements

Customer activation requires completed service and product schedules, operating supply commitments, a reconciled token and capacity register, and a technical release that performs the stated allocation, billing, locking and cancellation rules. Release verification must cover each customer flow from accepted instructions to final records.

The minimum operating evidence comprises measured delivery and billing samples, capacity commitments, procurement support, accepted-order records, tested wallet permissions and a documented support process. Ongoing reporting should show service availability, allocated capacity, electricity reconciliation, token events and hardware fulfilment.

The model’s performance can then be assessed through four observable results: computing work delivered under customer instructions, electricity charged against that work, token events reconciled to the relevant obligation, and accepted hardware orders fulfilled under their stated terms.