Rights intelligence for tokenized assets.

Introduction

Rights intelligence for tokenized assets.

One-liner

RELL tells you exactly what a tokenized real-world asset actually gives you.

Why This Exists

Tokenized stocks and other tokenized real-world assets (RWA) are often marketed and perceived as if holding the token is equivalent to holding the underlying asset. In practice, a token can represent anywhere from full legal ownership to nothing more than synthetic economic exposure — and the difference is usually buried across smart contracts, issuer terms, and legal disclosures that most holders never read in full.

RELL exists to close that gap. It is a rights and claims intelligence layer: for any supported tokenized asset, it produces a standardized, plain-English breakdown of what the token actually entitles the holder to, backed by verifiable sources.

Who This Is For

• Holders of tokenized stocks / RWA who want to know what they actually own
• DeFi protocols deciding whether to accept a tokenized asset as collateral
• Issuers and platforms who want a neutral, standardized way to disclose token rights
• Researchers and auditors assessing tokenized asset structures

Document Scope

This document set describes the concept, mechanism, and system design of RELL. It intentionally does not cover implementation details (contract code, backend architecture, tech stack) — those live in a separate implementation-track document once build begins.

Problem Statement

The Core Issue

A tokenized stock or RWA can look like the underlying asset without giving the holder all the rights normally associated with owning that asset.

For example, a stock token might provide:

• Economic exposure
• Distribution / dividend entitlement
• Redemption rights
• Transferability
• DeFi / collateral compatibility

But it may not provide:

• Legal ownership of the underlying security
• Voting rights
• Direct shareholder rights

Why It's Hard to Know

Figuring out which of these apply for a given token currently requires reading:

• The token's smart contract
• Issuer terms and conditions
• Legal / custodial structure documents
• Distribution and redemption policies
• Corporate action disclosures

Most holders never do this. Even when they try, the information is scattered across sources that use different terminology, different disclosure standards, and different levels of detail.

The Consequence

Holders, integrators, and protocols end up making decisions — buying, using as collateral, assuming certain rights exist — based on assumption rather than verified fact. Misunderstanding what a token represents is a structural risk, not just a UX inconvenience.

Solution Overview

RELL creates a plain-English rights profile for every supported tokenized asset.

A user searches for a token and receives a standardized breakdown across six rights categories (see Core Concepts), with every claim tied to a source and a verification status (see Verification System).

Example

A user searches: AAPL Stock Token

RELL displays:

Each row is expandable into a plain-language explanation, its verification label, and a link to the underlying source.

What Makes This Different

RELL does not just show contract data (that's a block explorer) or price/portfolio data (that's a tracker). It answers one specific, narrow question — "what rights does this token actually carry?" — by combining onchain evidence with offchain documentation into one standardized, sourced answer.

Core Concepts

Every asset in RELL is evaluated across six rights categories. These categories are fixed and standardized — every asset is scored against the same six, regardless of asset type, so profiles are comparable across tokens.

1. Ownership

What the token actually represents, and who legally owns the underlying asset.

• Does holding the token constitute legal ownership of the underlying security?
• Who is the legal owner of record?
• What is the token, legally — a claim, a derivative, a wrapped representation, a certificate?

2. Economic Claims

What financial entitlement the token carries.

• Does the holder receive dividends / distributions?
• Is the holder entitled to redemption for the underlying asset or its cash value?
• What economic exposure does the token provide (price tracking, synthetic, direct)?

3. Control Rights

Whether holding the token grants any say over the underlying asset or issuer.

• Voting rights on the underlying security?
• Governance rights over the token or protocol?
• Any other shareholder / control rights?

4. Transfer Rights

The practical and permissioned ability to move the token.

• Can anyone hold and transfer it, or are there eligibility restrictions (KYC, jurisdiction, accreditation)?
• Can the issuer freeze, pause, or blacklist transfers?
• Is transfer permissionless, permissioned, or conditional?

5. DeFi Compatibility

How the token behaves once it leaves the issuer's own platform.

• Can it be used as collateral?
• Can it be supplied to lending protocols?
• Can it be used in other DeFi applications (AMMs, derivatives, etc.)?

6. Asset Status

The current operational state of the token.

• Active, paused, or restricted?
• Redeemable right now?
• Subject to an ongoing corporate action (split, delisting, merger, etc.)?

Each category is populated using the data sources and verification mechanism described in the following sections.

Data Model

Every asset tracked by RELL follows one standardized structure. This keeps every profile comparable regardless of asset type or issuer.

Asset
├── Identity
│   ├── Name
│   ├── Symbol
│   ├── Contract
│   ├── Chain
│   └── Underlying Asset
│
├── Ownership
│   ├── Legal Ownership
│   └── Token Representation
│
├── Economic Claims
│   ├── Economic Exposure
│   ├── Dividends / Distributions
│   └── Redemption
│
├── Control Rights
│   ├── Voting
│   └── Governance
│
├── Transfer Rights
│   ├── Transferability
│   ├── Restrictions
│   └── Eligibility
│
├── DeFi Compatibility
│   ├── Collateral
│   ├── Lending
│   └── Other Integrations
│
├── Status
│   ├── Active
│   ├── Paused
│   ├── Restricted
│   └── Corporate Action
│
└── Sources
    ├── Onchain
    ├── Issuer
    ├── Legal
    └── Last Updated

Notes on the Model

• Identity anchors the profile to one specific contract on one specific chain — no cross-chain ambiguity.
• Each leaf node under Ownership / Economic Claims / Control Rights / Transfer Rights / DeFi Compatibility carries its own verification label (see Verification System) — the model is not scored as a whole, but claim by claim.
• Sources is not metadata bolted on at the end — it is a first-class part of the model. A claim without a traceable source should not be presented as a claim.
• Last Updated exists at the asset level because status and rights can change (corporate actions, contract upgrades, revised terms) — see System Mechanism for how freshness is maintained.

Data Sources

RELL combines two categories of information. Neither is sufficient on its own — onchain data tells you what's technically possible, offchain data tells you what's legally and economically true.

Onchain

Read directly from the blockchain:

• Token contract
• Chain
• Token standard
• Supply
• Transfer permissions
• Pause / freeze functionality
• Contract ownership / admin controls
• Related contracts
• Oracle / reference-price information
• DeFi integrations where verifiable onchain

Onchain data answers questions like: can this token be paused, can the admin blacklist an address, is there a redemption function present.

Offchain

Authoritative issuer, legal, and asset documentation:

• Terms and conditions
• Issuer documentation
• Legal structure
• Distribution terms
• Redemption rules
• Eligibility requirements
• Corporate action information
• Custodian / underlying-asset information

Offchain data answers questions onchain data structurally cannot: whether the holder has legal ownership, whether dividends are contractually owed, what the custodial arrangement actually is.

Why Both Are Required

A contract can technically allow permissionless transfer while the issuer's terms impose eligibility restrictions enforced off the smart contract (e.g. at a frontend or custodial layer). Relying on only one source produces an incomplete or misleading rights profile. Every claim in RELL is mapped to whichever source category is actually authoritative for that specific claim.

Verification System

Not all claims can be verified to the same standard. RELL makes the confidence level of every claim explicit, rather than presenting all information as equally certain.

Verification Labels

VERIFIED ONCHAIN Directly observable from blockchain data — contract code, contract state, or onchain events. Highest confidence for anything it covers.

VERIFIED FROM ISSUER / DOCUMENTATION Supported by authoritative documentation from the issuer or a legal/custodial source. High confidence, but dependent on the source document remaining current and accurate.

REPORTED / INFERRED Information that cannot currently be independently verified — pulled from secondary sources, inferred from pattern/precedent, or self-reported without a verifiable primary source. Lowest confidence.

The Core Rule

Inferred information is never presented as fact. Every claim in a rights profile shows its label alongside the claim itself, so a user can immediately see the difference between "this is directly verifiable" and "this is reported but unconfirmed."

Handling Conflicts

Where onchain data and offchain documentation appear to disagree (e.g. a contract technically allows a transfer that issuer terms prohibit), RELL surfaces both rather than silently picking one:

• The onchain claim reflects technical capability
• The offchain claim reflects permitted / legal use

Both are shown with their own label so the user understands that technical capability does not necessarily equal legally sanctioned use.

System Mechanism

This describes how a rights profile gets built and kept current — conceptually, not as an implementation spec.

Pipeline Overview

1. Asset Registration

An asset is added by identifying its token contract, chain, token standard, and the underlying real-world asset it references. This becomes the anchor for everything else in the profile.

2. Onchain Data Ingestion

The token contract and related contracts are read to determine supply, transfer/pause logic, admin/ownership controls, and any oracle or DeFi integration points.

3. Offchain Document Ingestion

Issuer terms, legal structure documents, and disclosure materials are collected and mapped against the six rights categories.

4. Claim Extraction & Mapping

Each leaf in the Data Model is populated from whichever source (onchain or offchain) is authoritative for that specific claim.

5. Verification Labeling

Every populated claim is tagged with one of the three verification labels, based on how it was sourced.

6. Conflict Resolution

Where onchain and offchain evidence disagree, both are retained and shown side by side rather than collapsed into a single answer (see Verification System).

7. Rights Matrix Assembly

The individual claims are assembled into the standardized rights matrix — the same format used across every asset, so profiles remain comparable.

8. Plain-English Explanation Layer

Each claim in the matrix is paired with a short, non-technical explanation of what it means in practice for the holder.

9. Status Monitoring

Assets are re-checked when trigger events occur — a corporate action, a contract upgrade, a pause/freeze event, or a revision to issuer documentation — rather than on a fixed schedule alone. A re-check re-runs the pipeline from ingestion.

10. Publishing

The finished profile is what a user sees when they search or look up an asset, along with its sources and last-updated timestamp.

Scope

RELL covers Robinhood Chain + Stock Tokens.

What's Built

1. Asset search
2. Token lookup
3. RELL profile page
4. Rights matrix (the six categories)
5. Source / document references
6. Onchain verification
7. Plain-English explanations
8. Last-updated timestamp

Why This Scope

Stock tokens on Robinhood Chain are a single, well-documented asset class — enough to fully exercise the rights-matrix concept, the verification labeling, and the conflict-resolution logic in one coherent product.

Out of Scope

• Other chains
• Non-stock RWA categories
• Any of the items listed in What RELL Is Not

API Design

This describes the conceptual surface area the product needs to expose — not request/response schemas or implementation.

Design Principles for the API

• Every claims-related response should carry its verification label — the API should never return a claim without also returning its confidence level and source.
• /status is separated out because it is the field most likely to need near-real-time freshness, while the rest of the profile changes less frequently.
• The API mirrors the Data Model directly — no additional grouping or transformation layer between the model and the API surface.

What RELL Is Not

RELL has one narrow job: tell users what they actually get when they hold a tokenized asset. It is deliberately not:

• A token screener
• A portfolio tracker
• A trading platform
• A price dashboard
• A generic RWA explorer
• A wallet
• A lending protocol
• A legal-advice platform

Every one of these is a legitimate product category — they are simply not this product. Feature requests that pull RELL toward any of the above should be treated as scope creep away from its core purpose.

Positioning

Primary

RELL — Rights intelligence for tokenized assets.

Alternative

Know what your token actually gives you.

Product Feel

RELL should feel like a rights/claims intelligence layer — closer to a disclosure or compliance tool than a crypto dashboard. The tone throughout the product (copy, explanations, matrix design) should read as neutral and factual, not promotional. It is reporting what a token gives you, not selling the token.