The protocol does not perform automatic tax withholding at the smart-contract level. Smart contracts handle distribution deterministically, but taxation remains a jurisdiction-dependent, off-chain responsibility.
The DID and compliance layer can be used to gate participation (for example, restricting access to users from certain jurisdictions or investor classes), but it does not encode tax rules or calculate withholdings on-chain. This is intentional, as cross-border tax obligations vary widely and change over time, making them unsuitable for immutable on-chain enforcement.
In practice, there are two supported models. In the default model, users receive staking or rental rewards directly and are responsible for manual tax reporting according to their local regulations. In a more regulated setup, the DAO or asset issuer can route distributions through an off-chain compliant entity (SPV, trustee, or administrator) that performs jurisdiction-specific withholding before funds are distributed on-chain. That enforcement happens outside the protocol, with the smart contract acting only as the final settlement layer.
So the protocol enables compliance-aware access control, but tax calculation and withholding are deliberately left off-chain, either to the user or to regulated intermediaries chosen by the DAO.
The UX is designed to be explicit, not opaque. When a user attempts to stake or participate, the compliance check happens before any on-chain action is submitted. If the user does not meet the requirements for that pool or jurisdiction, the transaction is blocked with a clear, machine-readable reason code.
Wallets and dApps are expected to surface this as a human-readable explanation, such as missing KYC level, jurisdictional restriction, or accreditation requirement, rather than a generic transaction failure. The DID layer exposes compliance status in a way that frontends can query and display before the user signs anything.
From the user’s perspective, this means they see upfront whether they are eligible, why they are not, and what (if anything) can be done to become eligible. The goal is predictable, transparent feedback in the wallet or app, not cryptic on-chain reverts.
Yes, secondary markets for staked positions are explicitly supported, but they are opt-in and asset-specific, not automatic.
When a property token is staked, the protocol can mint a non-rebasing, transferable receipt token that represents the staked position and its future cash-flow rights. That receipt token can be listed on DEXs, used as collateral, or transferred peer-to-peer, subject to the same compliance rules as the underlying asset.
Whether a secondary market exists depends on how the DAO configures the asset. Some issuers may allow full transferability of the staked receipt to maximize liquidity, while others may restrict transfers or limit them to verified counterparties only. Those constraints are enforced at the token or permission layer, not informally.
So the framework supports liquid, composable staked representations by design, but the final shape of the secondary market is a governance and compliance choice per asset, rather than a protocol-wide assumption.
Payouts are fully variable by default and track the actual rental income generated by the asset. If rental revenue drops in a given period, distributions for that period decrease accordingly. There is no implicit guarantee or fixed yield encoded at the protocol level.
That said, the framework allows optional smoothing mechanisms if the DAO chooses to enable them. For example, a DAO can route income through a reserve buffer, apply rolling averages over multiple periods, or maintain a stabilization pool funded during high-income months. These mechanisms are implemented as treasury or distribution rules governed by DAO proposals, not as hardcoded protocol behavior.
So the base model reflects real cash flow, while any yield smoothing is an explicit, transparent design choice controlled by governance rather than an assumption built into the system.
Governance does not assume a fixed yield or automatic protection against revenue drops. If rental income falls sharply due to vacancies or market conditions, payouts simply reflect the lower cash flow.
However, the framework supports explicit reserve and buffer strategies if the DAO decides to adopt them. A DAO can vote to allocate part of incoming rental income to a reserve treasury, define minimum payout thresholds, or temporarily suspend distributions during stress periods. Those rules are enforced by the DAO’s treasury and distribution logic once approved.
In practice, this means risk management is handled transparently through governance. Any use of buffers, reserves, or payout adjustments is a deliberate decision made by token holders and executed on-chain, rather than a hidden or automatic mechanism baked into the protocol.