1. High level architecture

This section describes how the RECC ETF is structured at a high level: who the actors are, which on chain programs are involved, and what kind of state the system needs to keep in order to compute NAV, PPS and handle deposits, withdrawals and allocations safely.

The ETF lives on Solana as a smart contract that sits on top of the existing RECC property infrastructure. The basic idea is simple: investors interact only with the ETF program and the RETF token, while fund managers and supporting services coordinate interactions with property programs, DeFi adapters and the ETF liquidity settings. All of this is driven by a set of accounts that store global configuration, per property exposure and per user positions.

1.1 Actors and roles

There are four main groups of actors around the ETF.

Investors

Investors are the users who deposit USDC into the ETF and receive RETF shares. From their point of view, the system should look similar to a DeFi pool. They see their RETF balance, the current PPS, their portfolio value and the breakdown of allocations across properties and DeFi parking, and they can start deposit or withdraw flows.

Admins

Admins or fund managers are the operators of the ETF. They are responsible for setting the global parameters of the fund, such as the target liquidity buffer, the minimum USDC floor, the instant withdraw limits and the maximum age for pending withdrawals. They also decide which properties receive ETF allocations, how much capital to allocate to each one, when to redeem RPST and bring cash back to the vault, and whether to use any whitelisted DeFi parking strategies.

In the on chain model they are represented by signer addresses that are allowed to call specific admin instructions on the ETF program.

Program

The RECC backend and automation layer supports the ETF with off chain services. This typically includes cranks or scheduled jobs that call the program periodically in order to update linear accrual, refresh NAV based on property timelines, process batches of pending withdrawals or synchronize off vault movements when cash returns from properties.

These services do not have special privileges beyond what on chain instructions allow, but they provide regularity and reliability to the flows.

Property Managers

Property managers are the entities that handle the underlying real estate deals. They operate at the level of individual properties, not at the ETF layer. Their main interactions with the ETF are indirect: they run crowdfunds that the ETF can join and at maturity they provide the principal plus yield of properties.

1.2 On chain components

The core on chain component is the ETF program itself. This program owns the ETF vault where USDC is held under program custody, mints and burns RETF shares, keeps track of global configuration and per property allocations, and enforces the rules for deposits, withdrawals, pending requests and admin actions.

A key element is the ETF vault token account that holds USDC. This account is a program derived address controlled by the ETF program. All user deposits end up here through a deposit instruction that transfers USDC from the user to the vault and mints RETF in exchange.

All redemptions burn RETF and transfer USDC from the vault to the user, either instantly if liquidity conditions are satisfied or after an admin approval if the withdrawal is in pending state. Any external movement of funds that bypasses this vault, such as sending USDC directly from a property program to an off chain wallet, is considered off vault and must be reflected carefully in the accounting so that Real NAV remains accurate.

On the token side, RETF is a standard SPL token mint controlled by the ETF program. RPST are also SPL mints, one per property, controlled by the property program. The ETF program holds RPST balances in its own token accounts as a representation of its exposure to each property. Users do not directly hold RPST through the ETF. Their exposure is abstracted behind their RETF balance.

1.3 Data model overview

To compute NAV, PPS and to manage deposits and withdrawals, the ETF program keeps several categories of state.

At the top level there is a global ETF state account. This account stores configuration parameters such as the chosen the RETF mint, the current USDC vault address and DeFi adapters that have been whitelisted.

It also keeps numeric parameters like the target liquid buffer percentage, the minimum USDC floor, the instant withdraw limit, the maximum age for pending withdrawals and any global fee configuration. This account is the single source of truth for fund level settings.

For each property in which the ETF allocates capital there is a per property allocation record. This record links the property identifier or RPST mint to the ETF state and stores how much USDC was allocated, how many RPST the ETF currently holds, the expected APY and the planned timeline for linear accrual, the current status of the property from the ETF point of view and the accumulated accrual and realized yield so far.

Users are represented through position accounts that track how many RETF shares each address owns and, depending on the final design, some cached values that make front end queries easier.

However, for withdrawals the program usually keeps a separate set of withdrawal request accounts. Each withdrawal request links a user to a specific amount of RETF they want to redeem, the timestamp of the request, the estimated USDC value at request time and the current status of the withdrawal, which can be pending, approved, paid, canceled or partially filled in more advanced versions. These accounts are what the UI shows in the Pending withdrawals panel and what the admin dashboard uses when listing requests waiting for approval.

Finally, there are ledger fields that belong to the ETF state and per property records and that are needed for analytics and safety. Examples are the current NAV values as seen by the program, the computed Delta, the total supply of RETF used for PPS calculations, daily accrual counters, accrued to date yield across all properties and DeFi adapters and any impairment reserves that have been booked.

These values allow the front end to display a clear picture of the fund and allow admins to see when liquidity is drifting away from targets or when Delta has grown to a level that deserves action.