Can Rights in Tokenized Securities Be Calculated by Holding Period?

Rent accrues over a month. During that month, the rights to the asset move from C to A, and part of the position moves again to B. When the income is paid, who should receive how much?

One method establishes entitled holders at a single point. Another considers the interests held throughout the period in which income accrues. The right choice depends on the product's terms. Making the asset tradable in smaller tokens does not answer this question by itself.

In 2023, we explored the second approach.

If we record the balance and time whenever a token moves, can we calculate rights from who held how much, and for how long?

This post revisits that proof of holding period idea through revenue distribution and governance voting. Here, proof means an auditable accounting calculation that reconstructs historical positions from ledger balance records, not a new cryptographic proof.

Dividing 100,000 Units of Revenue Among Three Holders

For illustration, use block numbers instead of calendar time. An income provider distributes 100,000 revenue tokens over [58,98). The start, 58, is included and the end, 98, excluded: 40 block-height intervals from 58 through 97. Eligible security token supply remains 1,000 throughout, and the policy allocates revenue evenly at 2,500 per block.

C holds all 1,000 at block 58. At 73, C transfers the entire position to A. At 83, A sends 500 to B, and at 90, B sends the 500 back to A. In this example, the balance assigned to a transfer's block is the balance after all transfers within that block have finished.

Interval	Blocks	C / A / B balances
[58,73)	15	1,000 / 0 / 0
[73,83)	10	0 / 1,000 / 0
[83,90)	7	0 / 500 / 500
[90,98)	8	0 / 1,000 / 0

Follow A's calculation to the end. Multiplying balance by holding duration produces an area measured in security token-blocks, not yet a quantity of revenue tokens.

$$\begin{aligned} \text{A's area}&=1{,}000\times10+500\times7\\ &\quad+1{,}000\times8=21{,}500\\ \text{A's average}&=\frac{21{,}500}{40}=537.5\\ \text{A's revenue}&=100{,}000\times\frac{537.5}{1{,}000}\\ &=53{,}750 \end{aligned}$$

Holder	Revenue tokens paid
C	37,500
A	53,750
B	8,750
Total	100,000

Even though A is the only holder at the end, C and B retain income attributable to earlier intervals. Revenue distribution asks who held which share during the chosen distribution period, not merely who holds the token on the payment date.

Record Changes Instead of Copying Every Block

A checkpoint records a changed balance and its time. For A, the example needs records of 1,000 at block 73, 500 at 83, and 1,000 at 90. We also need the last state before the interval begins. There is no need to store the same balance again in every unchanged block.

Adding the rectangles gives holding area; dividing by duration gives the time-weighted average balance, or TWAB. For holder $i$, let $b_{i,s}$ be the balance in segment $s$, $\Delta h_s$ its length, and $[H_0,H_1)$ the full interval:

$$A_i=\sum_s b_{i,s}\Delta h_s$$ $$\overline b_i=\frac{A_i}{H_1-H_0}$$

Block count is not wall-clock time. A timestamp may be more suitable for income proportional to elapsed time. Whichever clock is used, define interval boundaries and the treatment of multiple transfers at the same timepoint first.

What If Supply or the Revenue Rate Changes?

The earlier example can use average balance because supply is fixed and revenue is allocated evenly. If minting or burning changes supply, each segment needs its own ownership fraction. If actual income also differs between segments, that amount must be included too.

Let $b_{i,s}$ be holder $i$'s balance, $E_s$ the eligible supply, and $R_s$ the revenue-token quantity allocated to segment $s$. Split the timeline whenever balances, supply, or the revenue rate changes. The payout is:

$$P_i=\sum_s R_s\frac{b_{i,s}}{E_s}$$

In words, add “each segment's revenue × my share at that time.” For even allocation, $R_s=r\Delta h_s$; the earlier example uses $r=2{,}500$ per block. The formula applies where $E_s>0$. Undistributed revenue during zero-supply segments and small remainders from integer division need separate policies.

If two equal-length segments earn 0 and 100 respectively, someone holding only during the first does not automatically have to receive 50. Allocating total revenue evenly over time and allocating it by actual accrual are different policies. Whether treasury holdings are excluded from the denominator also belongs to the product's terms, not to the formula itself.

Why We Tried This in 2023

While preparing for a blockchain problem-solving challenge, our project plan proposed recording address balances with block heights and letting an income provider select a historical interval and payment asset. Holders could later claim income based on their positions during that period. Project records describe a prototype using Substrate's pallet-contracts, Ink!, and Rust for balance capture, income deposits, and withdrawals. That record is not the same as a verified feature of a current product.

Centralized systems can also calculate holding periods. The difficulty is reconciling ownership, transfer, and settlement records across institutions and repeatedly implementing product-specific rules. We were interested in placing different rights calculations on top of a common ownership history.

Conventional stock-dividend record dates likewise serve entitlement determination and large-scale settlement, together with market-price adjustments such as the ex-dividend adjustment. Time-weighting is not universally fairer and need not replace record dates. It is a way to examine which allocation matches the intent of products generating rent, royalties, interest, or similar cash flows.

The Same Holding History, a Different Voting Rule

Past holders may still receive revenue. Whether someone who sold an entire position should continue to vote on policy is a different question. Consider operating policies, such as replacing an asset manager or setting maintenance budgets, where the issuance terms and applicable law permit such decisions.

An ordinary snapshot vote looks up voting power at one historical point. This helps prevent voting, transferring the tokens, and voting again from another address; a flash loan borrowed and repaid in one transaction also cannot create past votes. OpenZeppelin's governance guide explains this model using ERC20Votes checkpoints of delegated voting power.

Adding duration can distinguish long-term holding from a last-minute purchase. Let $V$ be the start of block 1,000, when a proposal becomes public, and use the preceding 100 blocks, [900,1000), as the lookback. A held 100 throughout; B acquired 100 at block 990. Both hold 100 immediately before the reference point, but their average balances are A=100 and B=10.

Rather than use the historical average alone, cap it by the balance immediately before the reference point. Someone who sold everything before then receives zero. Calling the mixing weight $\lambda$ makes the policy choice visible:

Policy	A's votes	B's votes
Snapshot only ($\lambda=0$)	100	100
Equal blend ($\lambda=0.5$)	100	55
Time-weighted ($\lambda=1$)	100	10

B receives the same discount even as a legitimate new investor. Time-weighting reduces the influence of briefly held capital by delaying new participants' influence. It does not solve the concentration of entrenched large holdings.

Make “Immediately Before” Precise

The snapshot balance here is $b_i(V^-)$: the state immediately before block 1,000 begins. With end-of-block checkpoints, this corresponds to the end-of-block checkpoint for block 999. It excludes purchases and delegations in the proposal's block; it does not mean passing the current block to a historical lookup API. ERC-5805 also distinguishes the current clock from past lookup timepoints.

Let $b_i(V^-)$ be the pre-reference balance, $\overline b_i$ the lookback average, and $w_i$ the eligible voting units:

$$\begin{aligned} w_i&=(1-\lambda)b_i(V^-)\\ &\quad+\lambda\min\!\left(b_i(V^-),\overline b_i\right),\\ &\hspace{2em}0\le\lambda\le1 \end{aligned}$$

Selling everything by the end of block 999 leaves a zero reference balance and zero votes. Preventing votes after a sale in block 1,000 or later requires a lock or another eligibility check at voting time. A deliberation period can follow the fixed reference point; its votingDelay and the choice of when to freeze votes are separate decisions.

The Order of Aggregating Addresses and Delegation Matters

For identified security token holders, calculate by beneficial owner first, including that owner's multiple wallets, then add the eligible units to the delegate chosen immediately before the reference point. New holdings must not inherit a long-term holder's history simply because both chose the same delegate. Rewarding the duration of delegation itself would require separate delegation history.

Nonlinear weights per address are also vulnerable to wallet splitting. Taking a square root per wallet changes the result even though the same 100 tokens are held:

$$\sqrt{100}=10,\qquad 2\sqrt{50}\approx14.14$$

This is a counterexample to a simple per-address square-root weight, not a definition of quadratic voting as a whole. Transfers between one's own wallets, a custodian's customer sub-ledger, and prevention of duplicate aggregation must likewise connect to the beneficial owner.

The quorum denominator cannot simply reuse ordinary total supply. A percentage of eligible units $\sum_i w_i$ requires aggregating and verifying all holders; a fixed absolute threshold is less responsive to supply changes. Either policy must be fixed when the proposal is created. A timelock provides response time before execution but does not automatically prevent vote buying or collusion.

What Holding History Cannot Tell Us

Maintaining an on-ledger position is different from bearing its economic risk. Balance history alone does not reveal whether securities were borrowed or their risk hedged with derivatives. Development, analysis, operations, and oversight contributions are separate facts as well.

Input	What it informs
Ownership history + revenue policy	Income entitlement over the period
Ownership and delegation history + voting policy	Eligible votes from holdings
Separate contribution evidence and assessments	Contributor eligibility and authority

Simply adding contribution points to a holding score lets whichever scale is larger dominate the other. For decisions needing both perspectives, such as an asset sale, separate approval by holder and contributor channels is one option. Not every decision needs a bicameral process. Evidence issuance, revocation, appeals, and capture of the assessment process remain design problems.

Other time-based governance models use different inputs. Vote-escrow uses a future lock period, and conviction voting uses the duration of support for a proposal. This article uses pre-proposal holding history. Curve's VotingEscrow and BlockScience's conviction voting materials illustrate those differences. ERC-5805 proposes historical delegated-vote lookups and remained Stagnant when checked on September 7, 2026.

Recorded Does Not Mean Cheap to Calculate

Depositing a token into an AMM makes the pool contract its direct holder. The 2023 model also considered reconstructing indirect holdings by multiplying the pool's security token balance by the user's share of LP tokens. Not every pool uses that rule. Giving both the wrapper and the underlying asset the same income or votes double-counts the position. The design must specify which wrapper represents the rights, and technical possession alone does not establish the legal rightsholder.

Contract-side calculation also requires dedicated state. An EVM contract cannot directly read arbitrary storage from a past block, and an ordinary mapping cannot enumerate its keys. Implementation choices include:

Approach	Main trade-off
Traverse checkpoints at claim time	Direct, but long histories can reach gas limits
Cumulative area and binary search	Fewer queries, with complex supply and delegation composition
Offchain calculation + Merkle root	Less onchain work, with reproducibility and challenge requirements

Partial claims, duplicate-payment prevention, and small remainder handling are also part of the protocol. A separate 2023 Solidity prototype is examined with code in Recording Holding Periods Without a Hard Fork: A Design Review of SecurityToken.sol.

Institutional Boundaries of Tokenization and Rights Calculation

This idea does not automatically change the rights in every security. Four terms help define its scope:

Term	Meaning in this article
RWA	A broad industry category for tokenizing real-world assets or claims
Security token	A DLT-based form for issuing and recording a right that legally constitutes a security
STO	The issuance and offering of security tokens
Rights calculator	Rules deriving income or policy authority from history under the issuance terms

Calling a token an RWA does not confer legal ownership or make it a security. Security tokens retain the substance of securities and the applicable investor-protection and disclosure rules. A contract cannot unilaterally change statutory voting rights at a shareholder meeting.

Korea's Financial Services Commission described security tokens as a new issuance form in its 2023 framework. Related amendments passed the National Assembly in 2026, and the amended Electronic Registration Act is scheduled to take effect on February 4, 2027. When checked in September 2026, it was still before implementation: qualifying ledgers and supporting infrastructure remained part of the transition.

International sources likewise distinguish potential from adoption. The BIS's 2025 report discusses combining asset records and execution rules on programmable platforms. The FSB's 2024 assessment described adoption at that time as very low but growing; ESMA's 2025 DLT Pilot review also described limited initial uptake. These are not evidence that the entire market had already transitioned by 2026.

Programmable Rights Are Programmable Power

The idea was documented in Bankware Global Co., Ltd.'s Korean Registered Patent No. 10-2670671, “System and Method for Distributing Returns on Security Tokens” (filed October 16, 2023; registered May 27, 2024). It covers issuance, transfers, distribution rules, holding-period queries, payouts, and duplicate-payment prevention, with indirect-holding calculations among its detailed embodiments. This records design history, not proof of scalability or fairness and not a license to use the patent.

Revenue rights ask who receives which period's income; voting rights ask who should have how much decision-making authority. Different questions produce different calculations even from the same history. Contribution begins with different evidence altogether.

A ledger can record the history of ownership. The weight that history receives is determined by the people and code choosing the observation period, denominator, and allocation rule, together with the institutions governing the product.