rightsheet — the ownership and royalty ledger for onchain IP
rightsheet logo
rightsheet
the ownership and royalty ledger for onchain IP

ip ownership,
split on record.

The whole story is filed in this cabinet. Scroll to browse the drawers — click one to pull the file.

scroll to browse · click to open · scroll up to close
drawer {{ openNo }} · {{ openLabel }}
the ownership and royalty ledger for onchain IP

ip ownership,
split on record.

Patent rights, assignments and royalties, recorded as a verifiable ownership trail. RIGHTSHEET distributes what an asset earns — automatically.

view registry
no token issued
revenue is a fee per split
no minting
attaches to an existing IP-NFT
no custody
owners are paid direct to wallet
application for letters patent — redacted copy
compound: SS-114 / oxindole derivative
priority date: 2024-03-11
inventor: A. Okonjo
rights sheet
university
inventor
dao
fund
FILED
ON CHAIN
inventor
assignee
license
royalty
priority

one ip record.
multiple rights.

Every research asset carries several rights at once. RIGHTSHEET keeps them on one sheet — and pays each one its share.

ip → record → split

01
research
a result worth protecting
02
assignment
rights signed over, on paper
03
ip-nft
the asset is filed on chain
FILED
ON
CHAIN
04
split
the sheet divides — shares recorded
05
royalty
each share paid direct to wallet
original agreement
assignment
license
amendment
royalty split — v3

not deleted.
not replaced.
recorded.

Each change is a new sheet pasted over the last — the edges of the old ones always stay visible.

the cap table

illustrative figures

One payment in. The splitter reads the registry, withholds the fee, pays every owner in the same transaction.

$
platform fee− {{ feeAmt }}
distributed to owners{{ netAmt }}
share total{{ sumLabel }}
beneficiary
layer
share
allocation
{{ r.name }}
{{ r.addr }}
{{ r.layer }}
{{ r.status }}
{{ r.pct }}
{{ r.amt }}
one transaction · four transfers · fee withheld in flow

royalty received.

The one place this system allows feeling: money actually reaching the researcher.

royalty receipt
royalty receipt
researcherLAB-042
recorded2026-08-28
statusPAID

who owns what?

IP-0042
{{ whoTag }}
{{ whoLabel }}

{{ whoDoc }}

pulled from the stack · IP-0042

the registry

sample records · illustrative
IP-00041
Compound X
inventorDr. Lin
priority2026-03-12
assigneeLab A
royalty27.50%
RECORDED
IP-00042
Assay Panel B
inventorDr. Osei
priority2026-05-02
assigneeLab A
royalty20.00%
ACTIVE
IP-00043
Peptide S-207
inventorDr. Vance
priority2026-06-21
assigneeFund B
royalty15.00%
FILED
record
assetIP-00042
filed2026-08-28
hash0x7a91…e41
inventorDr. Osei
assigneeLab A
sourcelicence agreement · sha256

every claim
has a record.
for researchers
RESEARCH
↓
IP
↓
ASSIGNMENT
↓
ROYALTY
for assignees
RECEIVE IP
ASSIGN RIGHTS
DEFINE SPLIT
RECORD CHANGE
for contributors
contribution
RESEARCHER A
RESEARCHER B
LAB C
FUND D

ready to record the split?

FILED
RECORDED.
protocol design

from asset record to first royalty split

The registry is the single source of truth the splitter reads. Payment allocation happens inside the transaction that receives the money — there is no reconciliation step in between.

walkthrough

step {{ stepNo }} of 5 · {{ stepActor }}

{{ stepTitle }}

{{ stepBody }}

record written: {{ stepRecord }}
pinboard
{{ p.n }}
{{ p.label }}
{{ p.note }}

components

P0

asset-bound ownership registry

An on-chain record linked to a minted IP-NFT: owner list, each party's share, entitlement layer. The truth the splitter reads.

P0

stablecoin revenue splitter

Receives payment at the asset's own address and allocates by the effective share version. Without it the system is a signed spreadsheet.

P0

fee per split

A fixed portion of each allocation routed to the protocol treasury, enforced inside the split flow rather than invoiced separately.

P0

versioned share-change events

Assignments and dilution on new capital are written as numbered updates. Prior versions stay intact and remain queryable.

P0

admin console for the TTO

Create registries, enter owners, read allocation history — without the institution operating a wallet directly.

P1

licence terms vault

Attach and hash the agreement into the registry, recording scope, term and licensee. Owner dashboards, a licensee payment page and accounting exports read the same data.

cap table history

Shares are not treated as immutable. A share-change event writes the next version and keeps the old one; later payments split by the new version, while payments already made resolve to the version that was used.

{{ verTitle }}
basis document · sha256 {{ verHash }}
{{ r.name }}
{{ r.layer }}
{{ r.pct }}
{{ r.delta }}
{{ verNote }}

deliberately out of scope

no minting

The legal framework for bringing an asset on chain belongs to whoever holds it. The unclaimed part is governance and money after.

no token issuance

Revenue is a transaction fee on real royalty cash flow, independent of asset price or new capital inflow.

no competing with research DAOs

Longevity DAOs are prospective customers, not rivals — they run this layer by hand today.

no custody as lock-in

Lock-in is cash flow, not data: once the first royalty runs through the splitter, leaving means rewriting the payment terms with the licensee.
for universities · technology transfer

answer "why did I receive this amount" from the record itself

A TTO manages hundreds of patents with different revenue-sharing structures between the institution, the department and each named inventor. Rightsheet keeps that structure as a versioned on-chain record and executes it on every payment.

today
  • Each royalty period: weeks of manual spreadsheet reconciliation.
  • Inventor questions answered by reopening the original contract.
  • Separate transfers to each beneficiary, on separate schedules.
  • Assignment and dilution maths recomputed by hand each round.
with rightsheet
  • Allocation happens in the transaction that receives the royalty.
  • Every payout carries the share version and basis document hash.
  • The licensee pays once, to one address, with proof of discharge.
  • Share changes are numbered versions; history is never overwritten.

admin console — asset registry

rightsheet console — regents of a research university
operator: tto.admin@ · session verified
assets · 148
share versions
allocations
licence documents
beneficiaries
exports
asset
ip-nft
version
received ytd
status
{{ a.name }}
{{ a.id }}
{{ a.version }}
{{ a.ytd }}
{{ a.status }}
console mock-up · sample records

no wallet in the institution's hands

The console is built so the office operates without touching keys directly. Sales cycles run through legal, finance and IT; requiring an institution to self-custody would stop the deal before procurement.

Every write is previewed as a table for line-by-line comparison against the paper contract, and the executed agreement is hashed into the registry so the record can later be proved to match a specific document.

confirm registry write — negative print
asset      SS-114 oxindole derivative
ip-nft     0x7a3f…c410 / token 21
owners     4 parties · total 100.00%
document   licence-agreement-2026.pdf
sha256     9f2c41a7…d0b8
sign and file
irreversible · pending signature

pilot checklist

01

One asset with a licence agreement already paying royalties.

02

Licensee willing to settle in stablecoin, confirmed in writing.

03

Named beneficiaries with receiving addresses and identity on file.

04

A payment addendum pointing the contract at the asset address.
for inventors, research daos and funds

verify your share without waiting for a report

Owners are paid direct to their own wallet and see the allocation together with the share version applied. Nothing is recomputed at read time — the dashboard reads allocation history.

inventor · named on the patent

Today: no idea how much revenue the asset produced, how the share was computed, or when the money lands. Rightsheet: a payout line, a percentage, a version, a document hash.

research dao operator

Entitlements move out of spreadsheets and forum posts. Distributions to members or treasury run on the same splitter; dilution on a new round is a numbered version, not a manual recalculation.

owner dashboard

beneficiary
A. Okonjo — inventor
0x9c1d…7f22 · 3 assets · 2 entitlement layers
received to date
$182,400.00
effective share
22.50%
date
asset
version
share
allocation
{{ p.date }}
{{ p.asset }}
{{ p.version }}
{{ p.pct }}
{{ p.amt }}
each line resolves to the share version and the basis document that was in force · dashboard mock-up

entitlement layers

assignee

The institution holding title, typically split further with the department.

inventor

Named parties on the application, each with an individual share.

funder

Grant bodies and research venture funds holding contractual entitlement.

dao

Collective treasuries that funded the work, paid as one address or onward.
for licensees

pay once, to one address, with proof of discharge

A licence obligation owed to a university, three inventors, a grant body and a DAO becomes a single stablecoin transfer. The splitter distributes it and issues a receipt naming every beneficiary and share applied.

royalty payment · SS-114 oxindole derivative
pay to asset address
0x4d81…9ab7copy
amount due
$250,000.00
period
Q2 2026
licence    field-limited, non-exclusive
addendum  §4.2 payment instruction
document  sha256 9f2c41a7…d0b8
settle payment
receipt of discharge
university (assignee)52.50%
A. Okonjo (inventor)22.50%
VitaDAO (dao)15.00%
Longevity Fund (funder)10.00%
share version v3 · one transaction · settled 2026-07-14
OBLIGATION DISCHARGED

one instruction

The addendum names a single address. No beneficiary list to maintain, no schedule per party.

no reallocation risk

Assignments and dilution between rightsholders change the registry, not your payment instruction.

auditable proof

The receipt records amount, date, share version and every recipient — evidence the obligation is met.
documentation

technical reference

registry record

A registry is bound to one minted IP-NFT. Before creation, the system verifies the asset exists and that the institution holds administrative rights over it. Share totals must reconcile exactly before a write is permitted.

registry {
  asset_contract   0x7a3f…c410
  token_id         21
  payment_address  0x4d81…9ab7
  effective        v3
  owners[v3]       university   assignee  42.50%  0x1b0e…88fa
                   A. Okonjo    inventor  22.50%  0x9c1d…7f22
                   VitaDAO      dao       15.00%  0x33ba…0d51
                   Longevity F. funder    20.00%  0xc7f4…412e
  document         sha256 9f2c41a7…d0b8
}

split execution

The splitter is a reader. It queries the effective share version, withholds the platform fee and allocates the remainder to each owner address inside the same transaction that received the payment.

on_receive(amount, token):
  version = registry.effective()
  fee     = amount * platform_fee
  net     = amount - fee
  transfer(treasury, fee)
  for owner in version.owners:
      transfer(owner.address, net * owner.share)
  emit Allocation(version, amount, fee, timestamp)

Dashboards and exports recompute nothing. They read Allocation events with the share applied, which is what makes "why did I receive this amount" answerable from the record.

share versions

Assignment and dilution are share-change events, each written as the next numbered version with a basis document attached. Prior versions are retained: payments already made resolve to the version used, later payments split by the new one. The data model is append-only — nothing is erased, only covered.

document binding

Every structural change requires an attached instrument, hashed into the registry. This is what keeps the on-chain record and the paper contract from becoming two conflicting sources of truth in a dispute.

version
instrument
sha256
v1
revenue-sharing schedule
4a71c0…9e12
v2
deed of assignment
b8d2f4…07aa
v3
subscription agreement
9f2c41…d0b8

limits

  • The registry attaches to assets already minted; the protocol does not mint.
  • Payment routing is stablecoin only; the payer must accept stablecoin settlement.
  • The first release records entitlements that already exist between identified parties. No secondary market for shares.
  • Batch portfolio import, multi-institution aggregation, API and webhooks, and multi-signature approval flows are later-phase surfaces.
roadmap

phases, in the order the money requires them

P0
core
asset-bound ownership registry
stablecoin revenue splitter
fee per split, enforced in flow
versioned share-change events
admin console for the TTO
independent security audit

Enough to take a single paying licence from paper contract to automatic split.

P1
read & receive surfaces
owner dashboard
licence terms vault
licensee payment page
accounting and tax exports

Built on the same registry data — no second source of truth.

P2
scale layer
batch portfolio import
multi-institution aggregation
API and webhooks
multi-signature approval flow

For offices running hundreds of patents and funds holding scattered entitlements.

what has to be true

real royalty flow to run through

First customers are selected for having a paying licence agreement — not for already holding an on-chain asset.

the institution can buy

The console must not require the organisation to hold private keys, and engagements start with one pilot asset.

correct splits on real money

An error in the split contract or version logic misallocates funds that are hard to recover. Independent audit precedes live cash flow.

the record matches the paper

Basis documents are mandatory and hashed on every change, so a dispute has one reconcilable record.
security and legal posture

the split moves real money, so the record has to hold up

audit before live cash flow

An error in the split contract, or in how a share version is applied, misallocates funds that are difficult to recover. Independent security audit is a precondition for handling real royalty payments, not a later milestone.

no custody of owner funds

Allocation happens inside the receiving transaction and owners are paid direct to their own wallets. The protocol does not hold balances between receipt and distribution.

one reconcilable record

If the on-chain record drifts from the paper contract, a dispute has two conflicting sources of truth. Every change requires an attached instrument with its hash stored in the registry.

deliberate regulatory narrowness

Fractional ownership can be treated as a security in some jurisdictions, and routing payments can trigger KYC/AML and money-transmitter obligations. The first release records entitlements that already exist between identified parties and opens no secondary market.

controls on every write

{{ c.name }}
{{ c.desc }}

open risks, stated plainly

  • The number of on-chain research assets actually producing revenue is small, so a per-split fee may not carry the product early.
  • Institutional sales cycles run through legal, finance and IT; many offices cannot operate a wallet at all.
  • Traditional payers may refuse stablecoin settlement on internal policy grounds.
  • Legal characterisation of fractional entitlement differs by jurisdiction and constrains where the registry can operate.
about · contact

a registry, a splitter, and a filing cabinet that cannot be edited quietly

Research intellectual property has always been a stack of paper: applications, deeds of assignment, revenue-sharing addenda, lab notebooks signed and dated. Putting it on chain does not remove that stack — it only makes it impossible to alter unnoticed.

Rightsheet is the layer after the mint: the owner list and shares on chain, the splitter that allocates every stablecoin payment, and a console the technology transfer office can actually operate. Each cap-table change is a new sheet pasted over the last, with the edges of the old one still showing.

pilots    pilots@rightsheet.xyz
docs     technical reference
community telegram · x
request a pilot

One asset, one paying licence, named beneficiaries. Tell us what is already flowing.

{{ formNotice }}