2. ETF mechanics

This section explains how the ETF behaves once it is live. It follows the full lifecycle from the moment a user deposits USDC, to the moment capital is allocated into properties, accrues value over time, and eventually comes back as USDC for withdrawals.

2.1 Lifecycle overview

When a user deposits USDC into the ETF, the ETF program transfers that USDC into its vault and mints RETF shares to the user at the current Price Per Share. From that moment the user has a proportional claim on the entire ETF portfolio. They do not own specific RPST tokens, they own a slice of the fund represented by their RETF balance.

On the fund side, this USDC initially sits in the liquid bucket. The ETF operates conceptually with two buckets. The liquid bucket is the part of the fund that is available for withdrawals on demand and may also be parked in strictly instant redeem DeFi strategies. The locked bucket is the part that is deployed into property fundraising rounds and other longer horizon uses. Moving capital from the liquid bucket into the locked bucket is an allocation decision taken by admins according to the strategy of the ETF.

When fund managers decide to allocate capital, they instruct the ETF program to join the crowdfund of one or more properties. Under the hood, the ETF program deposits USDC into the property contract and receives RPST in return. Internally, the ETF records that this property now has an allocation, with an amount, an expected APY and a timeline.

From the point of view of NAV, while the property is still in fundraising, RPST is carried at par, usually one dollar per RPST. Once the property is fully funded and begins its economic life, the ETF starts applying the linear accrual model described in the NAV section so that NAV grows gradually according to the expected returns of that property.

As time passes, the ETF updates NAV combining two things. On one side, it adds realized cash that actually comes back into the vault, such as rental income, principal plus yield from matured properties or harvested DeFi positions.

At any moment, a user can request a withdrawal. If the requested amount and the current state of the liquid bucket satisfy the instant withdrawal conditions, the ETF burns the corresponding RETF and immediately sends USDC from the vault. If not, the withdrawal is stored as a pending request to be approved by an admin within a configured time limit.

In both cases the amount paid is based on PPS at the effective time of the withdrawal, either at request time for instant flows or at approval time for pending flows.

Eventually, properties reach maturity. Property managers settle the real estate deal and the property program allows RPST to be redeemed for principal plus rewards. The ETF burns its RPST, receives USDC, and this new cash is added to the vault. NAV increases, PPS goes up and the ETF can either keep this liquidity in the buffer for withdrawals or re deploy it into new properties.

2.2 Deposits and RETF shares

In the first version the ETF accepts deposits in a single stablecoin, USDC. When a user wants to enter the fund, they start a deposit flow in the interface that guides them through sending USDC to the ETF.

The on chain deposit instruction does two things. It transfers the chosen amount of USDC from the user wallet into the ETF vault token account, which is controlled by the ETF program, and it mints the corresponding amount of RETF shares to the user wallet.

The number of RETF minted depends on the current Price Per Share. Conceptually, PPS is defined as NAV divided by the total number of RETF shares in circulation. If NAV is 1 000 000 and there are 1 000 000 RETF, PPS is 1. If a user deposits 10 000 USDC at that moment, the program mints around 10 000 RETF so the user ends with a position equivalent to one percent of the fund. If a user deposits when PPS is higher than 1, they receive fewer shares for the same USDC value.

Internally, after a deposit, NAV increases by the amount of USDC that has entered the vault. The accrual logic then continues operating as time passes, so deposits and the growth of the underlying properties are combined into a single NAV number and a single PPS.

2.3 NAV and PPS

NAV and PPS are the core accounting metrics of the ETF.

NAV represents the total value of the fund expressed in USDC terms. In the v1.0 model, NAV combines the USDC balance in the ETF vault, the RPST balances held by the ETF valued at par while properties are still in fundraising, any yields that have already been realized and brought back into the vault, and it subtracts accrued fees and any impairment reserves if the ETF decides to book potential losses or risk adjustments.

On top of this base, the ETF applies a linear accrual model for properties that have started their economic timeline. For each allocation the program knows how much was invested, what APY is expected and what the planned duration is. From this, it can calculate a daily or per slot accrual amount.

These accrual amounts are added into NAV at regular intervals to experiment a smooth growth curve that anticipates the final payout of each property. In simple terms, instead of waiting for a big jump in value on the day a flip property settles, the ETF spreads that expected gain over the entire holding period.

When the ETF receives rental income or realizes profit from a sale, NAV increases while the RETF supply stays the same, so PPS goes up

PPS, the Price Per Share, is calculated as NAV divided by the total supply of RETF. Any change in NAV or in RETF supply implies a change in PPS. When the ETF receives rental income or realizes profit from a sale, NAV increases while the RETF supply stays the same, so PPS goes up. When users deposit, both NAV and supply go up, and PPS may remain stable or adjust slightly depending on the timing and the exact accounting choices.

For users, the important point is that PPS is the conversion rate between RETF and USDC. When they deposit, PPS tells them how many shares they receive. When they withdraw, PPS tells them how much USDC they get per share. NAV is the aggregate number behind that price.

2.4 Buckets and liquidity model

The liquidity model of the ETF is based on two buckets and a small set of parameters that fund managers can tune.

The liquid bucket is the part of the ETF that backs withdrawals on demand. In practice, it includes USDC in the ETF vault and any positions that can be redeemed instantly for USDC without delay and without taking unusual risk. The size of this bucket is guided by a target liquid buffer percentage and a minimum USDC floor. For example, the configuration can specify that at least 40% of NAV should stay liquid and that the vault balance should not fall below a certain minimum amount.

The locked bucket is the part of the capital that is committed to property deals and other non trivial uses. When the ETF allocates into a crowdfund, it moves USDC from the vault into the property program and receives RPST. From a performance perspective, that allocation is still part of NAV, but from a liquidity perspective it is no longer available for immediate withdrawals.

When a user initiates a withdrawal, the ETF compares the requested amount with the available liquidity and a configurable instant withdrawal limit. If after honoring the withdrawal the USDC vault balance remains above the floor and the requested amount is below the instant limit, the ETF processes the withdrawal immediately. It burns the specified amount of RETF and transfers USDC from the vault using the current PPS.

If these conditions are not met, the program records a pending withdrawal. The user sees a request with a timestamp, the amount of RETF they are redeeming and an estimated USDC value based on the PPS at request time, together with copy explaining that the final amount will be computed at approval time. Admins use their dashboard to review these requests and approve them once enough liquidity is available.

Approval burns the RETF in question and transfers USDC from the vault at the PPS that applies at that moment. If necessary, the ETF can also support partial approvals, where part of a large withdrawal is paid now and the rest remains pending until more capital comes back into the liquid bucket.

Each pending request carries its creation time, and the ETF configuration includes a maximum target age, for example 48 hours. This lets the system expose simple service expectations to users and also gives admins clear signals if pending withdrawals are getting too old relative to the configured target. Combined with buffer utilization and NAV evolution, these signals help fund managers keep the ETF in a healthy liquidity zone.