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 call mint/burn.

• 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.

R1 Supply Distribution Scheme

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).

    • A signed message (“invoice UUID”, plus a usdMintLimit) 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.

  • NDContract then:

    • Burns 20%.

    • Sends 50% to liquidity (via ILiquidityManager.addLiquidity(...)).

    • 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.

• 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.

• 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 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.

• 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.

• 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.

Liquidity Manager

• A contract directly linked to NDContract, whose responsibility is to allow interactions between NDContract and R1 liquidity pools.

• It implements the ILiquidityManager interface, which defines two methods:

  • addLiquidity(...), which allows to add liquidity in a DEX Pair and send it to a designated liquidityReceiver.

  • getTokenPrice(), which returns the R1 price in USD with 18 decimals, allowing real-time price calculations for license purchases.

• The contract was created to provide flexibility for potential liquidity management changes, such as switching a different DEX or creating a new trading pair with a new stablecoin

• At the same time, it ensures security by automatically adding funds to the liquidity pool when a user purchases a license, while keeping the main contract non-upgradeable.

• The current implementation utilizes a UniswapV2 pool between R1 and USDC for these operations.

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 can receive more than 2% of the total supply

  • There is a “no-mining” period of 120 epochs (120 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 calls claimRewards(...) with a single ComputeRewardsParams.

  • Must also provide enough valid signatures.

  • If it is the genesis token, the minted R1 tokens go directly to the set of company wallets (rather than the license holder).

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, a liquidity manager 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 short waiting period 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 non-upgradeable and inter-coupled - every rule is set in stone.

Security & immutability benefits:

• Preventing changes to tokenomics

• Avoiding governance risks or external manipulation

• Maintaining predictable incentives for long-term stability

• Real-trust worthy protocol economy direct coupled with the R1 token and business adoption

This immutability comes with great responsibility: the system must be flexible enough to accommodate potential future needs, such as adjusting DEX interactions, allowing founders and the company to update wallet addresses if necessary, and more. 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 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.