Summary:

This proposal aims to determine the distribution method for REGs resulting from RealTokens revaluations. Three options are presented:

• A: The initial direct distribution system.
• B: A vault system that stores the value in $ convertible to REG.
• C: A vault system that stores the number of REGs created.

The vote on this proposal asks the DAO to validate option B, which offers a compromise between two investor philosophies. In case of rejection, a new vote will be launched to validate option C. If rejected, option A will be implemented for a minimum period of 6 months (new vote possible after 6 months).

Motivation:

It is crucial to choose a distribution system that is equitable, transparent, and efficient while considering the advantages and disadvantages of each approach for the Realtoken ecosystem.

Context:

After the SOON converter implementation, new house revaluations that have never been revalued are allocated a budget in newly created REG (see tokenomics), adding to the existing supply. This REG inflation aims to reward property owners who have invested in tokenized assets, encouraging them to maintain their investments, and allow newcomers to access the DAO without having to invest. This also allows for better distribution of voting power over time to limit power concentration within the DAO.

Description of options:

1. Option A: System initially planned and proposed by RealT
   • Conversion of dollar amount to REG at market price at distribution time
   • Direct distribution to beneficiaries' wallets at rent payment address
2. Option B: On-demand conversion system with automatic claim option
   • Extension of SOON to REG conversion system for future distributions
   • Storage of $ value convertible to REG in a vault
   • Beneficiary's choice of conversion timing
   • No time limit for conversion
   • Use of merkle tree for conversion rights management
   • Automatic claim option to be activated in vault Smart Contract (disabled by default)
   • Conversion rate set by an oracle (with anti-price manipulation calculation system)
   • Conversion triggers claim of all amounts due to beneficiary
   • Possibility to activate fees for automatic claims (0% by default)
3. Option C: Vault system storing created REG amount
   • Storage of created REG amount in a vault
   • Beneficiary's choice of when to claim allocated REG amount
   • No time limit for claiming
   • Use of merkle tree for conversion rights management

Comparison of options:

Option A (Initial System): Advantages:

• Simple to implement and use
• Transparency on inflation and distributions
• Prevents price manipulation
• Smooths REG value received over time (DCA)
• Immediate voting power benefit from REGs upon snapshot power update

Disadvantages:

• Systematic REG emission, even for inactive users

Option B (On-demand conversion system with automatic claim): Advantages:

• Potentially limits number of REGs issued
• Allows beneficiaries to choose between manual or automatic claim
• DCA possible for users who activate automatic claim
• Ability to choose conversion timing for users who don't activate automatic claim

Disadvantages:

• Market manipulation risks
• Initial complexity for automatic system setup
• Complexity for newcomers to understand
• Difficulty quantifying inflation
• No voting rights for unclaimed REGs
• Potential fees needed for automatic claims (benefiting those who execute automatic claim transactions, gas fee compensation)

Option C (Vault system storing created REG amount): Advantages:

• No price manipulation
• Automatic DCA for all beneficiaries
• Easily calculable potential maximum supply

Disadvantages:

• No choice of conversion rate for those who would have wanted it
• No voting rights for unclaimed REGs
• Inflation similar to option A, but reduced by unclaimed REGs
• Must claim to benefit from voting power and REGs
• System implementation complexity requiring 2 vaults (one for SOON, one for REG)

Important note:

If options B and C are rejected, option A will automatically be implemented for a minimum of 6 months, after which the DAO can vote again on a new proposal to modify the REG distribution method.

Implementation steps:

1. Community vote to validate or reject option B
2. If option B is rejected, vote will be launched to validate option C
3. If option C is rejected, option A will be implemented for minimum 6 months
4. Smart contract adjustment according to DAO's chosen option
5. Implementation of chosen system
6. Community communication about new system

Team:

• RealT technical team for development and implementation

Budget:

Option A: $0 Option B: $5,000 to $10,000 (development, testing, automation implementation) Option C: $7,000 to $12,000 (development, testing, automation implementation)

*Note: Option B development costs are related to necessary adaptations for functionality and automatic claim at smart contract and user interface level. Option C costs are related to implementation/development of 2 vaults, their operation, and interface that must abstract this complexity for users.

*Note 2: Smart contract audit if necessary will be performed by third party, cost is approximately $30 per line of code, internal audit is included in options B and C cost.

Financial implications:

• Development and smart contract audit costs
• Potential impact on inflation and REG value depending on chosen option

Roadmap:

• Forum discussion: 7 days minimum
• Proposal publication: 1 day
• DAO vote: 7 days
• Queue: 2 days
• Development and audit: 2-3 weeks
• Launch: Date to be determined based on next revaluation

Success metrics:

1. Vote participation rate
2. Community satisfaction with chosen system
3. Efficiency and transparency of future distributions
4. Impact on REG price stability

Mission alignment:

This proposal aligns with Realtoken DAO's mission by seeking to optimize REG distribution and strengthen participatory governance of the ecosystem. As REG belongs to the DAO, giving choice on distribution method is an important point for DAO governance.

Key terms:

• REG: Realtoken DAO governance token
• SOON: Temporary token representing $1 value, this token will be destroyed when converter vault is implemented
• Merkle tree: Data structure used for efficient rights verification

Proposal on the governance forum