Computation.Made tangible.

SILORA is a digital artwork project built around GPU computation. Participants run the terminal on their own computers, perform real computational work, and generate an artwork with its own form and pixel detail. The SILORA network records ownership and rewards. Born from Compute is the starting point.

The original idea was to turn the time and work of a GPU into a finely detailed digital object on a square canvas. That idea has developed into four connected parts: a GPU terminal, pixel NFTs, SILORA Mainnet, and a dedicated block explorer.

SILORA artwork is produced through generative algorithms and GPU execution. Open-ended generation refers to the variety of possible outputs; a GPU executes computation rather than possessing independent thought. The artwork connects participation, a traceable creation process, and digital expression.

The website is the entry point for project information, artwork samples, the terminal installation command, and the mainnet explorer. Normal participation does not require manually importing task files; the terminal connects to its network and detects local devices.

This paper describes SILORA’s own network. Assets, rules, and services on other EVM networks do not automatically become part of SILORA.

Current artworks use a 256 × 256 square pixel canvas to express crystals, minerals, layered structures, orbits, curved surfaces, and sculptural forms. Generation changes proportions, cross-sections, spatial relationships, surface treatment, and fine detail as well as color.

The device identifier, task-specific randomness, and an independent ArtDNA contribute to generation. ArtDNA is a generative fingerprint that determines sets of form and detail parameters. Completed pixels are saved as a fixed output; website carousels, lighting effects, and interface animations do not redefine the artwork.

How is individuality enforced?

A large generative space creates variety, while duplicate checking tests for exact repetition. Registration checks the hash of the complete pixel content. Identical pixels cannot be registered twice in the same collection of records. If a duplicate is found, the task generates again while retaining confirmed work and reward terms.

This rule addresses exact pixel duplicates. Two works may share a visual language or look similar. Random generation alone is not treated as a guarantee that no artworks will ever resemble one another.

The information connected to a work

• Artwork identifier and name: for recognition and collection, subject to the saved and registered record.
• ArtDNA and content hash: describe the work’s generative identity and content fingerprint.
• Computation and time records: describe the task; supported devices also provide power samples and estimated energy use.
• Issuance and opening state: distinguish a local artwork, a registered NFT, and an opened work.

The 12 current gallery works are unissued GPU-computed test samples. They demonstrate the visual style, rather than user holdings, completed sales, or market prices.

After installation, the terminal detects available GPUs and establishes a task with defined work, difficulty, and reward terms. Computed answers must pass verification. Only accepted work advances progress that can be settled.

One device, one work; multiple GPUs participate separately

The project aims to associate one artwork opportunity with each GPU and allows multi-GPU computers to participate. The terminal identifies multiple devices so users can select participating GPUs. Each device maintains its own task, progress, and artwork.

Current duplicate-participation controls use registered device identities. Software identifiers from ordinary consumer GPUs are not unforgeable hardware attestations. One work per GPU is the participation rule and an ongoing engineering objective, rather than a claim of absolute identification of every physical GPU.

Computation time and actual progress

Initial work uses an expected duration of roughly 72 hours on an RTX 3060 Laptop GPU as a reference. Desktop RTX 3060 cards, laptops with different power limits, and other models must be judged by their performance in this program. Temperature, drivers, power limits, other workloads, and the randomness of finding valid answers affect completion time.

Current difficulty rises gradually with the task allocation ordinal, from approximately 1× toward 2×. Expected duration rises accordingly under the same conditions. Difficulty and full reward are locked when a task is allocated; later participants do not make an existing task harder halfway through.

Progress, pausing, and energy

• Progress follows confirmed work and may increase in steps. Continuous operation does not mean a valid answer is found every second.
• A task can be paused and resumed. Confirmed progress is retained; a sudden power loss may require repeating recent unsaved or unconfirmed work.
• Temperature and power come from available device sensors. Energy is a sampled estimate, not a wall-meter reading for the whole PC or a measure of GPU lifespan loss.
• Missing sensor data stays missing. Work verification establishes that answers meet task conditions, not independently the identity of a physical GPU or its exact electricity consumption.

Computation completion, image generation, NFT issuance, and reward payment are separate states. Seeing an image does not mean issuance has succeeded, and a pending reward is not a received wallet balance. Use the terminal’s actual state and confirmed explorer records.

What sealed and opened mean

A sealed NFT retains its unused opening entitlement. Under the current design, its personal wallet has not yet been created, and no mnemonic is hidden in the public image. At opening, the current holder’s terminal creates a wallet and associates its address with the artwork.

After opening, the artwork and its history remain available. What is consumed is the one-time opening entitlement. The created wallet can be used independently, and existing usable balances do not disappear because the NFT has been opened.

Ownership and wallet control after a transfer

A sealed NFT’s opening entitlement is associated with its registered holder. Transfers must follow the current protocol and available product flow, with ownership determined by confirmed records. Once opening has started, its receiving wallet is fixed. Later artwork transfers do not automatically hand over wallet keys, assets, or the bound reward recipient rights.

SILORA currently uses its own artwork registry protocol. Third-party NFT marketplaces, standard marketplace listings, and external wallet compatibility require separate integration and verification; EVM compatibility alone does not enable them.

SILORA is both the project name and the mainnet native coin. The artwork program has a cap of 21,000,000 works. Current genesis supply is 21,000,000 SILORA, held as the computation reward reserve. These are separate quantities: artwork opportunities and coins, not 100 coins for every work.

Rewards are released from the existing reserve. The current genesis allocation contains no additional team or investor allocation. Unreleased reserve coins are not user holdings or evidence of circulating market supply. Actual releases and payments are determined by mainnet records.

Why does the reward per work decline?

Each task receives a reward allocation ordinal and locks its full reward when allocated. The ordinal follows task allocation, not completion order. The declining curve keeps cumulative rewards for the artwork program within 21 million SILORA. It does not subtract a fixed 0.1 coin for each new task.

Values are approximated to four decimal places; actual amounts follow locked task terms and on-chain precision.

How does progress translate into rewards?

Cumulative confirmed reward = the task’s locked full reward × verified progress.

For a task with a 100 SILORA full reward, 1% verified progress corresponds to 1 SILORA. For a task worth approximately 46.1874 SILORA, the same 1% corresponds to approximately 0.461874 SILORA. Progress remains proportional while later tasks earn fewer coins. The terminal may display fewer decimals than the accounting precision.

During computation, earnings are recorded as pending settlement. After issuance, reward crediting, and confirmed opening, the terminal attempts to pay the claimable amount to the associated wallet. A confirmed payment record and wallet balance establish that payment occurred.

Native SILORA is used for asset transfers, reward settlement, and network fees. A standard account transfer at 21,000 Gas and 1 Gwei costs approximately 0.000021 SILORA. Contract calls and other transactions use their actual Gas estimate; review the terminal quote before submitting. Applications, swaps, and markets depend on actual product launches. The reward formula does not determine NFT sale prices or coin exchange prices.

The wallet design evolved from the early idea of a pre-existing sealed wallet to a wallet created on the user’s device at opening. There is no pre-generated personal wallet whose private key is held by the project during the sealed period. Reward entitlement is associated with the artwork task before being connected to the new wallet.

The current opening flow generates independent cryptographic randomness locally, producing a 24-word mnemonic, private key, and address. Recovery material is encrypted on the device and is not uploaded to the server. GPU identifiers, images, ArtDNA, and work amounts are not used as wallet key material.

A public address, private recovery material

An address can be used to receive assets and inspect transactions; the mnemonic and private key control the wallet. After opening is confirmed, the address is associated with public records, while recovery material remains with the user. Public artwork pixels and fingerprints cannot recover the private key.

This privacy design protects wallet secrets; it does not make all ownership and transfers invisible. SILORA is a public network, and transactions and publicly exposed ownership information remain inspectable.

• Back up recovery material as directed after opening. An encrypted file stored only on the original computer is not an independent recovery backup.
• Do not send recovery material to others or enter it into unknown websites. Receiving assets publicly requires only an address.
• Local encryption does not replace device security. Someone who controls the device or obtains recovery material may control the wallet.
• Opening does not destroy the wallet. A later transfer of the artwork does not automatically transfer independent wallet assets.

SILORA Mainnet is running with Chain ID 73407 in an EVM-compatible environment. Mainnet and testnet have separate identities; test artworks and test balances do not automatically become mainnet assets. Mainnet results are available through its dedicated explorer.

GPUs perform artwork tasks, while network validators confirm on-chain state. These are different roles. Installing the mining terminal does not automatically turn a computer into a validator or grant it block-production authority.

The network is currently in a single-validator bootstrap phase. If that validator or its supporting services fail, confirmation of new state may stop. Multi-node fault tolerance has not yet been established.

The next direction is to add independently operated validators and complete synchronization, membership, and recovery mechanisms so the network can continue through partial failures. The user-node entry is currently closed, and node acceleration benefits are not presented as an available feature.

Mainnet connects artwork issuance, locally created opening wallets, and reward claims. Genesis acceptance artwork #1 has completed issuance, opening, and reward payment, with records available in the mainnet explorer. Genesis acceptance and ordinary mining use different computation conditions; ordinary tasks must complete the work fixed when their task is created.

SILORA separates computation in progress, generated artwork, confirmed issuance, and paid rewards through task verification, content checks, and on-chain state. Users can inspect their terminal state and check the corresponding public result in the explorer.

The current trust model

During the initial phase, computation verification, issuance coordination, and network administration are provided by the project’s operating infrastructure. Important authority has not yet been distributed among independent participants. On-chain records help verify state but do not remove reliance on those operational roles.

The protocol includes administration and upgrade mechanisms for fixes and network evolution. Users should read published release information to understand current rules. Future governance and open node participation depend on mechanisms that are actually announced and operating; community self-governance is not claimed as complete today.

Three important distinctions

SILORA has progressed along the path of computation producing artwork, artwork connecting to an account, and a network recording value. Early terminal and pixel-art exploration developed into device detection, multi-GPU tasks, verified work, an independent mainnet, and a public website. The wallet design evolved toward local creation at opening to meet the privacy objective.

The roadmap describes the development sequence, rather than claiming all features are complete or promising unverified launch dates, fixed income, or transaction prices. Later editions will update status, rules, and scope as real operation provides evidence.

• Use the official installation entry at silora.network and paste the complete command into Windows Terminal or PowerShell.
• Review detected GPUs, choose a device, and inspect the task’s difficulty, reward terms, and state.
• Start work within your device’s operating conditions, pause when needed, and monitor accepted progress, temperature, and power readings.
• On completion, check the artwork and issuance result. When eligible, open it and back up locally generated wallet recovery material.
• Inspect opening and payment records in the mainnet explorer to determine whether rewards were actually received.

A short glossary

This participant-facing whitepaper is edition 1.0, updated October 17, 2026. It describes the product, economics, and network state for this edition. Later changes will be reflected in website materials and release information.