Rebirth Protocol & RLY (Reality+) Utility Token

2. The Problem

Over time, blockchain ecosystems accumulate large volumes of inactive or unsupported tokens. These assets:

• Remain permanently in user wallets without utility
• Create fragmented and unusable on-chain value
• Increase compliance and AML risk exposure
• Offer no compliant recovery path for users or projects

At the same time, Web3 platforms lack infrastructure to recover dormant value and reallocate it into productive ecosystems in a transparent and regulated way.

3. The Rebirth Protocol

3.1 Rebirth Engine Overview

The Rebirth Protocol introduces a structured and auditable process:

1. Burn
   Users voluntarily burn inactive or unsupported tokens on-chain.
2. Earn Rebirth Credits
   Burned assets generate Rebirth Credits on a 1:1 unit basis.
3. Convert
   Rebirth Credits can be converted into RLY or, in later phases, approved partner tokens.

This separation between asset destruction and token issuance enables a compliant and transparent recovery flow.

3.2 Supported Networks & Asset Scope

At launch, the Rebirth Engine supports inactive or unsupported assets across 15 blockchain networks, including both EVM and non-EVM environments.

Asset recovery is chain-agnostic, while utility issuance is consolidated to ensure consistent monitoring, settlement, and regulatory alignment.

4. Rebirth Credits

Rebirth Credits are an internal platform utility unit.

They are:

• Off-chain
• Non-transferable
• Not redeemable for fiat
• Not crypto-assets under MiCA
• Used exclusively within the Rebirth ecosystem

Rebirth Credits function as:

• A neutral accounting layer
• A compliance buffer between asset recovery and token issuance
• A controlled access mechanism to on-chain utility

5. RLY (Reality+) Utility Token

5.1 Token Classification (MiCA)

RLY is classified as a utility token under MiCA Article 3(1)(5).

RLY is not:

• An Electronic Money Token (EMT)
• An Asset-Referenced Token (ART)
• A security or investment product

RLY does not grant:

• Ownership rights
• Revenue participation
• Yield or profit entitlement
• Claims against PixelPai ApS

5.2 Core Utility Functions

RLY is required for:

• Converting Rebirth Credits into on-chain utility
• Accessing advanced platform features
• Participating in governance mechanisms
• Routing and liquidity pairing for partner projects
• Coordinating ecosystem-wide participation

RLY functions as the platform utility and settlement token across all Rebirth-enabled products.

5.3 Network & Token Standard

RLY is issued as an ERC20 utility token on the Arbitrum network, selected for its EVM compatibility, scalability, and ecosystem maturity.

The RLY smart contract has been audited by OpenZeppelin, following industry-standard security review practices.

6. Token Supply & Distribution

Total Supply: 2,000,000,000 RLY (fixed, non-inflationary)

6.1 Allocation

No additional minting is possible.

6.2 Rebirth Distribution Mechanics

• Base conversion rate: 100 Rebirth Credits = 1 RLY
• Early participation bonuses may apply during defined phases
• Bonuses are:
  • Time-limited
  • Protocol-defined
  • Designed to incentivize early usage, not financial speculation

Distribution is expected to complete within approximately 18 months, after which RLY becomes fully circulating.

7. Conversion Fees & Payment

Converting Rebirth Credits into RLY or future approved partner tokens requires payment of a conversion fee.

Key principles:

• Fees are applied at the conversion stage, not during token burning
• Fees may vary depending on the quantity of Rebirth Credits being converted
• All conversion fees must be paid in stablecoins
• Accepted stablecoins may include, but are not limited to, USD-denominated stablecoins

Fees are designed to:

• Support platform operations and compliance costs
• Discourage abusive or exploitative usage
• Enable sustainable ecosystem growth

Fee parameters are transparent and may be adjusted through governance processes.

8. Community & Governance

Rebirth is designed as a community-driven ecosystem.

RLY holders may participate in:

• Voting on ecosystem milestones
• Allocation of platform revenues
• Prioritization of new features and integrations

Governance remains utility-focused and compliance-aware.

9. B2B2C Platform Model & Ecosystem Expansion

9.1 Rebirth as a B2B2C Infrastructure Platform

The Rebirth Engine operates as a B2B2C infrastructure platform.

PixelPai provides regulated compliance, settlement, and monitoring infrastructure to approved partner projects (B2B), while Rebirth offers a consumer-facing interface (B2C) where users can connect their wallet and interact with supported assets.

Approved partner projects may:

• List their utility token within the Rebirth ecosystem
• Enable users to convert Rebirth Credits into partner tokens
• Leverage PixelPai's compliance, identity, and monitoring infrastructure

Users interact directly with Rebirth, while partners integrate at the infrastructure layer.

9.2 RLY as Ecosystem Routing Token

All partner integrations require:

• RLY as the routing and liquidity pairing token
• Alignment with protocol parameters
• Compliance approval via PixelPai

This establishes RLY as the shared utility layer across multiple projects.

10. Wallet Screening, Custody & Withdrawals

When users connect a wallet, automated wallet screening and sanctions checks are performed in alignment with AML, FATF, and EU regulatory requirements.

To support compliant flows, Rebirth generates a platform-linked custodial wallet associated with the user profile. This custodial wallet temporarily holds Rebirth Credits, RLY, and supported assets within the platform.

Key principles:

• Assets remain associated with the user at all times
• Custodial wallets are used solely to support regulated flows
• Users may request withdrawal to an external non-custodial wallet

Withdrawals may require identity verification (KYC) depending on jurisdiction, thresholds, and applicable regulation.

Custody and wallet operations are handled through specialized third-party providers meeting industry security and compliance standards.

11. Compliance & Regulatory Alignment

Rebirth and RLY are designed in alignment with internationally recognized standards, including:

• MiCA (EU Markets in Crypto-Assets Regulation)
• AML / KYC frameworks
• FATF recommendations
• GDPR (EU General Data Protection Regulation)

Compliance is a core design principle of the protocol.

12. Roles & Responsibilities

12.1 PixelPai ApS

PixelPai ApS provides regulated infrastructure and compliance services.

PixelPai is responsible for:

• KYC and AML controls where required
• Wallet monitoring and risk scoring
• Transaction monitoring and reporting
• Jurisdiction-aware compliance operations

PixelPai ApS is a registered VASP with the Danish Financial Supervisory Authority and is grandfathered into the CASP regime under EU MiCA.

12.2 Rebirth / Reality+

Rebirth (Reality+) operates as:

• The consumer-facing product layer
• The utility distribution and coordination layer
• The ecosystem growth interface

Compliance and regulated services are outsourced to PixelPai ApS.

13. Risk Disclosures

Users should be aware that:

• RLY has no guaranteed liquidity or market availability
• Utility depends on platform adoption and partner participation
• Protocol parameters may change
• Regulatory frameworks may evolve
• Tokens may lose utility or relevance over time

Participation is voluntary and utility-driven.

14. Disclaimer