Can Rights in Tokenized Securities Be Calculated by Holding Period?

For a time, discussions of RWAs and tokenized securities focused on how finely an asset could be divided for trading.

Real-world assets that are difficult to trade or costly to access—real estate, music copyrights, artwork, and accounts receivable—could be represented as digital tokens, allowing fractional interests or claims to be held and transferred in smaller units. The first promise of tokenization was that rights with little liquidity could become tradable in new ways.

But making the units smaller does not, by itself, change how finance works.

Real estate produces rent. Music and patents produce royalties. Loans and accounts receivable accrue interest and repayments. Once the rights to those assets are divided into tokens and circulated, a harder question remains after the trade.

How should the income an asset produces—and the power to make policy decisions about that asset—be allocated among token holders who keep changing over time?

How Far Has Tokenization Come?

As of August 2026, global tokenization has not reached a stage where conventional securities have moved en masse onto distributed ledgers. The market is closer to a transition from regulated proofs of concept to controlled transactions involving real value and early commercialization, centered on bonds, funds, and deposits. The European Union is testing the trading and settlement of DLT-based financial instruments through the DLT Pilot Regime. Singapore is supporting the commercialization of Project Guardian, while participating institutions are working to build related networks. In November 2025, the Hong Kong Monetary Authority launched EnsembleTX, moving the project into a controlled pilot with real-value transactions. The BIS sees the potential of tokenization in combining asset records and transfer rules on a single programmable platform.

That does not mean the transition is complete. The Financial Stability Board has characterized adoption as very low, though growing. Early participation in Europe has also been limited. The market remains small, and many expected benefits—including efficiency, transparency, and accessibility—still require further validation. Chapter III of the BIS Annual Economic Report 2025, the BIS FSI assessment of tokenization, the Financial Stability Board's 2024 assessment, ESMA's review of the DLT Pilot Regime, the Monetary Authority of Singapore's plans to support the commercialization of Project Guardian, and the Hong Kong Monetary Authority's Project Ensemble update show both the potential and the remaining gaps in institutions and infrastructure.

Korea is also opening an institutional path. In its 2023 security token framework, the Financial Services Commission described a security token not as a separate new type of asset, but as a new issuance format that digitizes a security under the Financial Investment Services and Capital Markets Act (FSCMA) by using distributed ledger technology. In 2026, related amendments to the Act on Electronic Registration of Stocks and Bonds (Electronic Registration Act) and the FSCMA passed the National Assembly and were promulgated. The amended Electronic Registration Act is scheduled to take effect on February 4, 2027. Until then, Korea remains in a transition phase, developing requirements for distributed ledgers along with issuance, secondary-market trading, and settlement infrastructure. The FSC has also formed a consultative body to discuss a phased roadmap that includes tokenizing conventional securities and onchain settlement. The FSC's 2023 framework, its 2026 announcement of the legislative amendments, the amended Electronic Registration Act, and the security token consultative body's phased-roadmap discussion define the boundaries of this change.

Before this institutionalization gathered momentum, our interest in 2023 was in a more specific possibility that a distributed ledger might open.

Could we go beyond copying existing rights onto a distributed ledger and use the ledger's temporal history and programmability to create new ways of calculating those rights?

Rights Keep Moving After the Trade

RWA and security token are not synonyms. RWA is a broad industry label for offchain assets or claims represented or tokenized on a ledger. Calling something an RWA token does not, by itself, confer legal ownership of the underlying asset or make the token a security. Under Korea's framework, once the amended Act takes effect, a security token will be a qualifying DLT-based form of issuance and registration for a right that legally constitutes a security. An STO is the act of issuing and offering security tokens. The proof of holding period discussed here sits one layer below those questions: it asks how the history of an issued right can be used to calculate income and decision-making authority.

RWA                An offchain asset or claim represented or tokenized on a ledger
Security token     A qualifying DLT-based issuance and registration form for a right that legally constitutes a security
STO                The act of issuing and offering security tokens
Rights calculator  How income and decision-making authority are calculated and executed after issuance

Recording a security in security token form does not automatically change the substance of the security. Rules for investor protection, disclosure, entitlement determination, and market integrity do not disappear. In a framework that recognizes a qualifying distributed ledger as a securities registry, what may change is the foundation used to record rightsholders and transfers, and the range of calculations that can run on top of that history. Not every RWA token automatically becomes an entry on such a legal registry.

Centralized systems can also calculate rights by holding period in theory. The issue is less impossibility than cost and standardization. Ownership, transfer, and settlement records spread across institutions must be reconciled, and each product's calculation must be implemented separately. Distributed ledgers and smart contracts offer the possibility of placing different rights calculators on top of a shared history of on-ledger positions and transfers.

The Dividend Record Date as a Snapshot

Conventional stock dividends generally determine who held how much on a specified record date. This rule did not survive simply because it is old. It performs an important function within today's market structure by establishing entitled holders clearly and supporting large-scale settlement and market-price adjustments, including the ex-dividend adjustment.

We therefore cannot say that time-weighted holding is fairer than every conventional dividend, or that it should replace the record date for stock dividends.

But an asset whose cash flow accrues continuously over time invites a different question. If rent accrued throughout a month, does giving the same economic share to someone who acquired the right immediately before the record date and someone who held it for the entire month match the product's intent? For cash flows that accumulate over a period—music royalties, loan interest, and infrastructure operating income—the share held throughout the entire period may fit better than the balance at one instant.

A snapshot is one photograph. A distributed ledger's transfer history is closer to a strip of film unfolding over time.

The Question We Asked in 2023

While preparing for a blockchain problem-solving challenge in 2023, we asked a simple question.

If we record both the balance and block height whenever a token moves, could we calculate who held how much, and for how long, during a specified historical interval?

Our project plan proposed recording each address's balance together with the block height, then allowing an income provider to specify a past block interval and the revenue token to distribute. A token holder could later claim income based on the share they held during that interval. The project records state that we built a prototype in Rust using Substrate's pallet-contracts and Ink!, with balance capture, revenue deposit, and withdrawal functionality.

The idea was later formalized in Korean Registered Patent No. 10-2670671, held by Bankware Global Co., Ltd., titled "System and Method for Distributing Returns on Security Tokens." It was filed on October 16, 2023, and registered on May 27, 2024.

Here, proof of holding period does not mean a new zero-knowledge proof or cryptographic proof. More precisely, it is an accounting algorithm that uses checkpoints recorded on a ledger to reconstruct historical, time-weighted ownership shares in an auditable way.

Calculating an Area, Not a Point

Put address A's balance on the vertical axis and block height on the horizontal axis. While the balance remains unchanged, the graph is a horizontal line. Multiplying the balance by the number of blocks for which it remained in effect gives the area of a rectangle.

ownershipArea(A, H0, H1)
  = sum(balance_A(segment) * segmentLength)

TWAB(A, H0, H1)
  = ownershipArea(A, H0, H1) / (H1 - H0)

TWAB means time-weighted average balance. There is no need to store the state of every block individually. If we keep a checkpoint only when a balance changes, together with the new balance at that point, we can calculate the area between consecutive checkpoints.

The interval boundary must be defined first. Throughout this article, every interval uses [start, end). The state at the starting point is included, while a change at the ending point belongs to the next interval. Thus [58, 98) spans exactly 40 block-height intervals, from 58 through 97.

Redistributing 100,000 Units of Revenue

Suppose an income provider distributes 100,000 units of a revenue token over [58, 98). The eligible security token supply remains fixed at 1,000 throughout the interval, and revenue accrues at 2,500 units per block.

• The previous holder transfers all 1,000 units to A at block 73.
• A sends 500 units to B at block 83.
• B sends 500 units back to A at block 90.

Interval	Blocks	A balance	B balance	A revenue	B revenue
[58, 73)	15	0	0	0	0
[73, 83)	10	1,000	0	25,000	0
[83, 90)	7	500	500	8,750	8,750
[90, 98)	8	1,000	0	20,000	0

A receives 53,750 units and B receives 8,750. When the previous holder receives 37,500 units for holding all 1,000 units during [58, 73), the total distribution is exactly 100,000.

If total supply changes, the balance area alone is not enough. Checkpoints for total supply must also record every mint and burn, and each interval must calculate the following ownership share:

shareArea(A, H0, H1)
  = sum(balance_A(segment) / eligibleSupply(segment) * segmentLength)

Whether the denominator is total supply or eligible supply excluding treasury holdings and tokens scheduled for burning is not a technical fact. It is part of the product's rights policy. The formula does not make that policy disappear.

One History, Different Rights

There is one ownership history, but it does not always have to produce the same kind of right.

Ownership and delegation checkpoints
        |
        +--> Revenue-rights calculator: payment based on the economic interest recorded in each interval
        |
        +--> Voting-rights calculator: sustained on-ledger holdings during the lookback before a proposal
        |
        +--> Contribution ledger: separate evidence, assessment, decay, and revocation rules

Revenue rights ask about the economic interest recorded during the period in which income actually accrued. Governance voting can ask who continuously held an on-ledger interest before the proposal appeared. Contribution is not about how much capital someone held, but about who contributed analysis, development, operations, oversight, or community work.

Because these three questions have different purposes, their scores should remain separate.

Can Time Be Added to Governance Voting?

What a Single Snapshot Prevents—and Misses

Typical token voting uses balances recorded at a particular historical snapshot. Looking up a past checkpoint instead of a current balance can reduce attacks in which someone votes, transfers the tokens to another address, and votes again, or borrows votes through a same-transaction flash loan. OpenZeppelin's governance guide likewise uses ERC20Votes checkpoints so that a Governor can look up voting power at a specified point.

But a snapshot at one instant cannot distinguish between someone who accumulated tokens immediately before the cutoff and someone who held the same amount for a long time. This is where a holding-period calculation can be applied to voting. If the design intends to exclude purchases and delegations made after a proposal becomes public, the reference point V must be fixed at the proposal's publication time or at an earlier epoch. The votingDelay then becomes the deliberation period that follows.

Suppose the proposal's reference point is block 1,000 and its lookback interval is [900, 1000).

• A held 100 units continuously for 100 blocks.
• B acquired 100 units at block 990.
• Immediately before block 1,000, both have a current balance of 100 units.

A ownershipArea = 100 * 100 = 10,000
A TWAB          = 10,000 / 100 = 100

B ownershipArea = 100 * 10 = 1,000
B TWAB          = 1,000 / 100 = 10

Under a single snapshot, both receive 100 base voting units. Under a fully linear time-weighting policy, A receives 100 and B receives 10. A flash loan borrowed and repaid within the same block has effectively no influence on the average over the lookback, while the effect of last-minute accumulation is reduced in proportion to how long the tokens were held.

This property is both an advantage and a political choice. B receives the same discount even if B is a legitimate new investor rather than an attacker. Conversely, a participant who has held a large position for a long time can retain strong influence for a long time. Time-weighting weakens attacks by momentary capital; it does not solve the concentration of entrenched capital.

Combining Snapshot Holdings with Historical Averages

There is another problem. If voting power comes only from the historical average balance, a rightsholder who disposed of the entire position before the reference point could still vote based solely on past holdings. It is therefore better to require both holdings at the reference point and a holding history. The calculation should be performed by beneficial owner first, not by delegate.

snapshotBalance(owner)
  = beneficialOwnerBalance(owner, V)

historicalBalance(owner)
  = TWAB(beneficialOwnerBalance(owner), V-L, V)

ownerVotingUnits(owner)
  = (1 - lambda) * snapshotBalance(owner)
    + lambda * min(snapshotBalance(owner), historicalBalance(owner))

delegateVotingUnits(delegate)
  = sum(ownerVotingUnits(owner) where delegateAt(owner, V) = delegate)

When lambda is 0, this is equivalent to an ordinary snapshot. When it is 1, the time-weighted balance is capped by the balance at the reference point. In the example above, lambda = 0.5 gives A 100 units and B 55. The lookback and lambda are explicit policy variables that determine how quickly a new participant's voice grows. Preventing someone who disposes of the position after the reference point from voting also requires a token lock or an additional eligibility check at voting time, together with a rule against double voting.

The order of calculating by rightsholder first matters. A new purchase must not inherit a long holding history merely because both the long-term holder and the new buyer delegate to the same address. If the model should also reflect how long a delegation has remained in place, delegation history must be checkpointed separately from holding history and subject to a cooldown.

The denominator for quorum must also be redefined.

eligibleVotingSupply
  = sum(ownerVotingUnits(owner))

After time-weighting, the total eligible vote may be smaller than the ordinary historical total supply. Reusing a quorum defined as a percentage of total supply can prevent legitimate proposals from passing. The policy must therefore choose between a percentage of total eligible voting units and a fixed absolute threshold. The former carries the cost and verification problem of aggregating all rightsholders, while the latter is less responsive to changes in circulating supply.

Caps, quorums, and vetoes must also be separated by type of decision. Applying a per-address cap or sqrt(balance) directly can be circumvented by splitting one person's holdings across multiple wallets. Material decisions such as the sale of an asset may require a higher quorum and a separate veto. No single formula should be assumed to fit every decision.

Governance Models That Use Time Differently

Not every governance model that uses time is the same.

Model	How it uses time	Difference from time-weighted holding
snapshot / ERC20Votes	Delegated balance at one historical point	Does not calculate duration
time-weighted voting	On-ledger holdings during a lookback before the proposal	Caps historical holdings at the balance held at the reference point
vote-escrow	The period for which tokens will be locked in the future	A future lock commitment, not past holding
conviction voting	The period for which a particular proposal has received continuous support	Accumulates support for an issue rather than holding history

ERC-5805 is a proposal to standardize snapshot-based lookups of delegated balances at historical points; its current status is Stagnant. Curve's VotingEscrow implementation and BlockScience's conviction voting materials assign different meanings to time. Rather than grouping them together, the design in this article treats actual pre-proposal holding history as a separate input.

Beneficial Owners, Not Addresses

For products such as security tokens, where rightsholders are identified, the unit of calculation should be the verified beneficial owner rather than an address. Moving tokens between wallets controlled by one person should not reset the holding period, nor should splitting them across wallets bypass a cap. If a custodian holds tokens for multiple customers in an omnibus wallet, the custodian's sub-ledger must provide auditable evidence of each customer's holding period and delegation. Address history on the ledger does not always identify the legal rightsholder.

Even after identifying the beneficial owner, the ledger proves only the continuity of the position recorded on-ledger. Balance history does not reveal whether the position was borrowed through securities lending or whether its price risk was eliminated with a derivative or an offsetting position. Time-weighted holding should therefore not be called a complete proof of loyalty or genuine economic risk-bearing.

Nor does this model mean that a smart contract can unilaterally change statutory voting rights at a shareholder meeting. If the right is part of the terms of a security, the issuance terms, disclosures, and applicable law come first. The voting examples in this article focus on asset-operation or protocol policies to the extent the issuance terms and applicable law permit.

Examples include:

• Maintenance budgets and revenue-retention rates for a rental asset
• Replacement of an asset manager or data verifier
• Royalty licensing policy
• Protocol fees and treasury spending
• Emergency stops, upgrades, and risk limits

Why Contribution Needs a Separate Ledger

Holding capital for a long time and contributing to a community are different facts.

A long-term holder provides one signal relevant to policy decisions by maintaining an on-ledger position over time. But the contributions of someone who analyzes the asset, writes code, monitors operational risk, or verifies field data do not come from a token balance.

Simply adding the two creates problems:

final voting power = holding score + contribution score

If the unit of holdings is large, capital overwhelms every form of contribution. Conversely, if the issuer of contribution scores is powerful, it can bypass the economic rights of token holders. Combining different units in one number also obscures the value judgment being made.

A better starting point is to separate authority.

Economic-interest decisions: time-weighted holder channel
Operational and technical decisions: verified contributor channel

Passage of a material policy
  = holder channel approval AND contributor channel approval

Not every issue needs a bicameral process. Revenue distribution can follow only the economic-ownership rule, while an authorized channel of expert contributors can handle purely technical parameters. Only issues that require both perspectives, such as selling an asset or replacing its manager, may need approval from both channels.

A contribution ledger does not become trustworthy automatically. The design must decide what counts as evidence, who may issue an attestation, whether a score decays over time, and how an erroneous contribution can be revoked and appealed. Making contribution non-transferable does not by itself eliminate Sybil attacks, collusion, or capture of the assessment process.

Who Holds the Rights When Tokens Are Deposited or Wrapped?

The 2023 model also considered what happens when a token is deposited into an AMM. The direct owner of the security token visible on the ledger is the token-pair contract, while the economic interest may remain with the liquidity provider who holds the LP token.

The idea at the time was to checkpoint the pool's security token balance together with LP-token balances and total supply, then reconstruct the indirect share.

indirect security token share
  = security token balance held by the pool
    * user's LP-token balance / total LP-token supply

This approach is useful for explaining one AMM case, but it is not a standard solution for every delegation model. The LP token itself can be transferred, and a receipt token can be deposited into yet another protocol. If both the underlying and the wrapper receive revenue or voting rights, the same economic position is counted twice. The legal beneficiary of revenue or voting rights is not determined solely by the token's technical holder either.

An actual system therefore needs an adapter registry that specifies which wrapper represents the underlying asset's rights, together with rules preventing double counting.

Recorded Does Not Mean Cheap to Calculate

"It is on the blockchain, so we can just read the historical state" is not a sufficient explanation for a smart-contract implementation.

An EVM contract cannot directly read arbitrary storage from a past block. Nor can it enumerate the keys of an ordinary mapping. The system must therefore store a sorted checkpoint array for each address and use binary search, precompute cumulative balance-blocks, or have an offchain indexer calculate the result and register a Merkle root.

Each approach has different trust assumptions and costs.

Approach	Advantage	Main cost and risk
Traverse checkpoints at claim time	Direct and easy to understand	Long histories create gas-limit and DoS risks
Cumulative area with binary search	Fast queries over fixed intervals	Supply changes and delegation composition complicate the logic
Offchain calculation + Merkle root	Can reduce the cost of large distributions	Requires reproducible indexing and a process for challenging the root

When multiple transfers occur within the same block, the protocol must decide which balance counts for that block. If the income follows real time, a timestamp may be a better clock than block height. Dust from integer division, partial claims, overlapping income campaigns, and state preventing duplicate payments are all part of the protocol as well.

Voting adds another attack surface. Historical average balance weakens flash loans and last-minute accumulation, but it does not stop entrenched whales, borrowed or hedged positions, concentrated delegation, low participation, or vote buying. To exclude purchases made after a proposal becomes public, the design should not set the reference point after a votingDelay, as in a common Governor configuration. It must instead freeze voting units when the proposal is published or at an earlier epoch. Timelocks, quorums, delegation-change cooldowns, late-quorum extensions, and emergency stop procedures can then be considered on top. A quorum can prevent decisions made under low participation but can also create deadlock. A timelock provides time for detection and response rather than preventing vote buying. Ethereum.org's smart-contract security documentation also identifies the use of flash loans to obtain temporary voting power as a representative onchain-governance risk. The 2022 Beanstalk governance exploit post-mortem shows how borrowed votes combined with immediate execution can lead to real losses.

Why Revisit the Patent?

Korean Registered Patent No. 10-2670671 organizes security token issuance and transfers, registration of revenue- distribution rules, holding-period queries, payout calculation, and duplicate-payment prevention into one system and method. Staking and the calculation of indirect holdings through LP tokens appear in its detailed embodiments.

The fact that the patent was registered does not mean the algorithm's scalability, economic fairness, or suitability for an actual market has been verified. We disclose the patent here to preserve the record of how the question we began asking in 2023 was documented and made public. Judgments about the patent's scope or licensing are also outside the role of this article.

This reconstruction treats proof of holding period not as a finished answer, but as a first model that prompted us to rethink rights on a ledger.

Programmable Rights Are Programmable Power

Moving securities onto a distributed ledger does not solve every problem automatically. We might do no more than copy existing rights into smaller tokens. Or we might use the ledger's temporal history and programmability to make rights calculations that were previously nonstandard and costly part of the product itself.

Time-weighted revenue distribution links the period in which income accrues to the economic interest recorded during that period. Time-weighted voting can give more weight to sustained on-ledger holdings than to the balance at a single instant. A separate contribution ledger opens the possibility of reflecting labor and responsibility that cannot be reduced to capital in decision-making.

But formulas are not neutral. The observation period, the supply used as the denominator, and the balance between new participants and long-term holders are all policy decisions. Revenue rights, voting rights, and contribution should not be mixed into one number; each needs its own purpose and attack surface to be made explicit.

A distributed ledger records a history of on-ledger positions and transfers. The weight that history receives in the calculation of rights is ultimately determined by the code and institutions we create.