The “TL;DR” summary

In the world of blockchain projects, albeit some interesting, some with true utility, many with doubtful purpose, it’s rare to see an ecosystem designed to combine classic ERC20 tokens, clever liquidity management, and special ERC721 “license” NFTs - all while coordinating node operation incentives. Our Ratio1 ecosystem stands out precisely because of this holistic design. Let’s walk through the high-level user flow to see how everything ties together, focusing on where the user gets involved and what to expect when interacting with the system.

R1 Token (ERC20 + Capped)

• Name: Ratio1, Symbol: R1 with maximum supply: 161,803,398 tokens.

• Only the ND (Node Deed) and MND (Master Node Deed) contracts can mint new tokens, which is essential for the functioning of the ecosystem, as it rewards node operators for keeping their nodes online.

• We also have a list of addresses that can burn the token, which comprehends the ND contract and will include other ecosystem smart contracts that were not live at the moment of the ecosystem deployment such as PoAI.

• For maximum security, the owner of the contract can set the address for both the ND and MND contracts only once, ensuring that no unexpected change to the tokenomics can happen. With the smart contract being non-upgradeable, the owner does not have the ability to do any other operation that could harm in any way the token or its holders.

R1 Supply Distribution Scheme

Controller

• Handles the logic that connects all the smart contracts together, and contains the immutable constants that should never change, such as percentages of R1 tokens allocated for each type of license.

• Signatures Verification:

  • The message for rewards claiming must be signed by oracles, whose role is to verify the nodes network and provide trustworthy information about node availability.

  • The signature is also verified during the buyLicense(...) call to ensure that the buyer has completed the KYC/KYB process, meeting all protocol compliance requirements.

  • The contract maintains a whitelist of authorized signers, which is also used by dAuth to determine which nodes will act as oracles.

  • Each node possesses a set of public and private keys which derive both an internal protocol address as well as an EVM address, which enables seamless signature verification and unlocks additional on-chain capabilities.

NDContract (Node Deed) – ERC721

• Users can buy node licenses (ERC721 tokens). Each license can eventually generate R1 rewards if the user “runs a node” and periodically claims.

• Buying a License:

  • User calls buyLicense(...) and provides:

    • The number of licenses to buy.

    • A limit on how many R1 tokens they are willing to pay per license (maxAcceptedTokenPerLicense).

    • The percentage of VAT to apply

    • A signed message (“invoice UUID”, plus a usdMintLimit and VAT percentage) from an authorized signer.

  • Contract checks the signature is valid (and not previously used).

  • It retrieves the R1 token price from the DEX (ILiquidityManager.getTokenPrice()), converts the license’s USD cost to R1 cost, and ensures the user’s maxAcceptedTokenPerLicense is not exceeded.

  • The user transfers that many R1 tokens to NDContract, including the percentage needed for VAT given by the backend..

  • NDContract then:

    • Burns 20%.

    • Sends 50% to liquidity.

      • A percentage of this amount, defined by a directAddLpPercentage storage, is automatically added to the Uniswap V2 USDC/R1 LP

      • The rest is sent to the LP Company Wallet

    • Sends the remaining 30% to the main wallet or among a set of organization wallets

  • NDContract mints the requested number of ERC721 licenses to the buyer.

  • The buy license also has a mechanism in place to protect buyers from high price swings: if the price changes more than 10% in an hour from the last buy, the buy will fail, ensuring fairness and protecting from MEV and other forms of attacks.

• Linking a Node:

  • Each license can be linked to a “node address” via linkNode(...).

  • Only one license can be linked to a node address at a time, and the license cannot be reassigned for 24 hours.

  • If the license was previously linked to a node, it calls an internal _removeNodeAddress to unlink the old node first.

  • For compliance reasons, the user must also have passed the KYC/KYB to be able to link its node to a license, ensuring that even users who bought from secondary markets are identified in the ecosystem.

• Unlinking a Node:

  • The license owner can choose to unlink the license from their “node address”.

  • To ensure that no rewards are lost, the node cannot be unlinked unless the rewards have been claimed beforehand.

• Claiming Rewards:

  • A user who owns a license and has set a node address calls claimRewards(...).

  • The function checks daily “epochs” (1 epoch = 24 hours, starting from a fixed startEpochTimestamp in 2025).

  • The user must provide an array of ComputeRewardsParams (one for each license they want to claim) plus arrays of signatures from oracles for each license.

  • The contract verifies that there are enough valid unique signers.

  • It calculates the number of tokens to mint. The maximum is determined by MAX_RELEASE_PER_DAY, which is derived from the fixed amount of R1 assigned per license divided by the 36-month (1080 epochs) mining period, multiplied by the node’s daily availability (0–255).

  • The contract mints the calculated R1 tokens to the caller, allowing the license to accumulate daily rewards if signed by the oracles.

• Price Tiers:

  • ND licenses are sold in 12 ascending “price tiers,” each with a different USD cost and a fixed supply. Once a tier sells out, the contract automatically advances to the next tier.

MNDContract (Master Node Deed) – ERC721 (Soul-Bound)

• Special “founder” licenses (max 500). They represent 26.1% of R1 total supply assigned across MND holders, plus a separate “genesis” license that corresponds to 28.9% of supply (total 55% if you include the GND’s portion plus MND’s portion, as outlined).

• Key Differences from ND:

  • MND licenses are minted only by the owner of the contract (not purchased by users).

  • They are “soul-bound”, which means they are normally non transferable.

  • A transfer can only occur between two wallets belonging to the same entity (eg. for security reasons) if the contract owner calls initiateTransfer(...), specifying the new address. Similarly, a burn can only be executed if initiateBurn(...) is triggered. Otherwise _beforeTokenTransfer reverts the transaction.

  • The genesis license (ID = 1) is minted upon smart contract deployment and is assigned 28.9% of the total supply. Any rewards claimed with this license are minted directly to designated company wallets.

  • Other MND licenses (ID = 2..500) are allocated a portion of the total supply, with a combined maximum of 26.1%. No single license and no single wallet  can receive more than 2% of the total supply

  • There is a “no-mining” period of 223 epochs (223 days) after startEpochTimestamp for MND licenses. The genesis license can claim from day one.

  • After the no-mining period, the license can claim daily similarly to ND, using a “per-epoch availability.”

• Claiming Rewards:

  • The user must provide an array of ComputeRewardsParams (one for each license they want to claim) plus arrays of signatures from oracles for each license.

  • If it is the genesis token, the minted R1 tokens go directly to the set of company wallets (rather than the license holder). Otherwise, the amount of rewards will be determined with a sigmoid vesting formula and sent to the owner of the license.

The full story

Imagine a global network where each participant holds a digital title to a slice of “processing real estate.” Within this network, tokenized licenses let you harness compute power for a range of decentralized tasks - from training AI models to running IoT processing nodes, from hosting LLM-based services to maintaining efficient microservice endpoints. Everything unfolds in a trustless and secure environment, designed to incentivize ongoing operation and fair participation. The Ratio1 ecosystem brings this concept to life by combining a capped ERC20 token (R1) with two forms of ERC721 license contracts - one for general node operation (ND) and one for master or “founder” nodes (MND) - all orchestrated under carefully designed reward and liquidity mechanisms.

The $R1 utility token

At the base of this system sits the R1 token, whose maximum supply is hard-coded into the token smart contract. It can only be minted or burned by the ND and MND contracts, preventing any unapproved expansion of the token supply. This property assures participants that the total token economy remains predictable. When someone decides to join the network as a node operator, they first engage with the NDContract, the home of Node Deeds. Each Deed is minted as an ERC721 license, purchased in predefined price tiers that are pegged to USD but ultimately paid in R1 tokens. The process relies on an external liquidity manager that quotes the token’s price, ensuring the correct conversion from R1 to USD and preventing surprise markups. Buyers deposit R1 tokens into the NDContract, which then divides the tokens among a burn address, for pool growth, and special “company wallets” that fuel the network’s ongoing development. A newly minted Deed license arrives in the buyer’s wallet, representing the right to claim future rewards by lending compute power to the network.

Node deeds and actual nodes

Once the license is in hand, the owner links it to an off-chain node address. The license confers the ability to provide computational services, handle daily availability reporting, and claim the resulting token rewards. Every 24 hours is considered an epoch, and over time, oracles confirm a node’s availability. The license owner submits these proofs (complete with valid signatures) to the NDContract. The contract then calculates how much R1 can be minted to the operator based on node performance. This direct relationship between real-world compute work and on-chain incentives helps turn a simple NFT license into a piece of true digital property that generates tokens in a fair and transparent way.

The team plays a part

A parallel part of the ecosystem is the MNDContract for Master Node Deeds. Although it functions similarly in terms of claim logic and node linking, MND licenses differ in two ways: they are soul-bound and come with a special share of the total token supply. The soul-bound property means they cannot be moved or traded freely; the contract owner must specifically authorize any transfer, a design choice intended to keep these licenses in the hands of long-term supporters and founders that have an important role: maintain a strong and reliable network or oracle nodes that supervise the whole processing landscape. There is also a “genesis” license with its own core organization allocation of R1, used to fund the system’s core needs and ensure ongoing progress most notably the research and development grant funds and the social responsibility one.

Where ND licenses can be purchased by anyone willing to pay in R1, MND licenses are selectively assigned by the contract owner. The assigned amounts of R1 for each MND token are larger than an ordinary node license, providing a higher stake in the network’s operation. MND licenses also have a waiting period of 223 days before they can start claiming rewards, a feature that encourages stable, committed participation rather than speculative flipping. Both ND and MND node operators ultimately serve the same broad purpose: supplying reliable compute power so that training jobs, IoT processing, LLM-serving, and simple microservices can run without interruption and with verifiable performance.

Our focus on security

All the on-chain components, specifically the smart contracts we’ve discussed, are designed with security as a top priority. Our approach ensures that no actor can alter the way the protocol functions, creating a Monolithic Smart Contract System between R1 Token, ND and MND SCs that is and inter-coupled.

To ensure long-term reliability, we have invested significant effort in comprehensive testing, covering the protocol as a whole. With over 130 tests covering over 99% of the codebase, we have rigorously examined various scenarios, including potential attacks and unintentional misuses, to protect our protocol and our users as much as possible.

To further reinforce security and stability, we operate two additional networks alongside the mainnet: testnet and devnet. These environments allow us to simulate real-world scenarios with node communications and smart contract interactions. Testnet is a pre-production environment, mirroring mainnet 1:1, while devnet offers a faster-paced testing ground, featuring one-hour-long epochs for rapid iterations.

One aspect that smart contracts cannot directly verify on-chain is node availability - a critical factor in determining rewards. Since rewards must only be distributed to active node operators, this component required a robust solution. Our oracle system ensures a secure and decentralized approach to tracking node activity.

Each contract maintains a whitelist of authorized signers, consisting of EVM addresses controlled by trusted entities - founders, team members, and partners. These oracles continuously monitor the network, listen for node heartbeats, and reach consensus on each node’s actual availability during a given epoch. Without their validated signatures, no license - not even the GND - can mint rewards if its associated node was inactive.

To further strengthen security, the system allows for an adjustable minimumRequiredSignatures threshold. This ensures that multiple nodes must sign the verification message before the smart contract mints any rewards, reinforcing trust in the network and guaranteeing that only genuine uptime is rewarded.

A perfect harmony

Our ecosystem is built on a seamless interaction between multiple smart contracts, which work together while integrating data from oracles to accurately calculate rewards.

Beyond the on-chain mechanics, full compliance is one of our core values. To ensure regulatory alignment, every license sale requires KYC/KYB verification for clients, along with an invoice issuance upon purchase. This process is managed through a distributed microservice running on our oracles, which securely stores data provided by our compliance partner. For every buy transaction, a signed message is generated to verify that the buyer has successfully passed the compliance checks.

Moreover, our storage and event systems act as a monitoring layer, enabling seamless integration with other components. For instance:

• When a user purchases a license, an event is emitted, which the microservice automatically detects, triggering invoice generation for the buyer.

• The signerSignaturesCount storage allows us to track oracle signatures, ensuring that all oracles contribute equally and detecting potential abuse or discrepancies in the system.

Another fundamental pillar of our ecosystem is the direct connection between our smart contracts and dAuth, enabling two key integrations:

1. Node activation control – A node cannot be started unless it is linked to a valid license, ensuring that only committed participants can join the network.

2. Oracle node promotion – Any node added to the signers whitelist is automatically promoted as an oracle by dAuth, streamlining and securing this critical role.

These integrations provide flexibility for interacting with our diverse components while maintaining long-term adaptability. This approach ensures that we can easily support future innovations, such as the integration of the Proof of AI Contract.

Wrapping up

The reward mechanisms in these contracts revolve around signatures from trusted oracles, multi-sig logic, and meticulous math to ensure no operator claims more than their fair share. Each day’s potential rewards are strictly capped. The total minted to all node operators can never exceed the pre-defined fractions of the overall R1 supply, which keeps the economic system balanced. Admins hold certain powers to add or remove oracle signers, update company wallet addresses, and ban licenses that break protocol rules, reflecting a cautious approach to security as the ecosystem matures.

By combining an ERC20 token with a carefully measured mint-and-burn design, distributing node licenses as ERC721 tokens in ascending price tiers, and tying license ownership to real compute work, the Ratio1 ecosystem reimagines the concept of “decentralized processing real estate”. Each license becomes a direct claim on future token emissions, but only if the holder actually operates and maintains the underlying node. In this way, holders are rewarded for honest work and stable uptime, building a trustless but fair system in which no single party can unilaterally mint excessive tokens or manipulate supply at will. The end result is a network that welcomes people to acquire a Node Deed, connect their compute-infrastructure, and then reliably serve tasks, from small IoT workloads to demanding AI model training. The entire architecture provides a transparent, incentive-aligned environment where participants and the network as a whole benefit from the steady contribution of processing power.

Next episode we go beyond our Proof-of-Availability and will be on our Proof-of-AI user-experience - true democratization of job distribution where participants (from low level 2 core, 8 GiB VMs to gaming workstations to high end A100-powered machines) are incentivized proportionally to their contributions.