Skip to main content

Proposals

This page explains how to create, evaluate, and vote on governance proposals in the RWAPool protocol.

Understanding Proposals

Governance proposals are the primary mechanism for making changes to the RWAPool protocol. They allow token holders to collectively decide on important matters such as:

  • Protocol parameter adjustments
  • Smart contract upgrades
  • Treasury fund allocations
  • New asset type integrations
  • Fee structure modifications
  • Governance system changes

Proposal Types

RWAPool supports several types of proposals:

Parameter Change Proposals

These proposals modify specific protocol parameters without changing the underlying code:

  • Interest rate models
  • Fee percentages
  • Collateralization ratios
  • Minimum investment amounts
  • Redemption notice periods
  • Risk parameters

Code Change Proposals

These proposals modify the protocol's smart contract code:

  • Bug fixes
  • New features
  • Security improvements
  • Architecture changes
  • Integration with other protocols

Treasury Proposals

These proposals allocate funds from the community treasury:

  • Grants for developers
  • Marketing initiatives
  • Liquidity mining programs
  • Strategic investments
  • Protocol insurance funds

Asset Onboarding Proposals

These proposals add support for new asset types:

  • New real-world asset classes
  • Integration with new custodians
  • New tokenization methods
  • Asset verification frameworks

Governance Proposals

These proposals modify the governance system itself:

  • Voting mechanisms
  • Proposal thresholds
  • Timelock durations
  • Governance token economics
  • Council structure

Proposal Requirements

To submit a proposal, you must meet the following requirements:

  • Hold or be delegated at least 100,000 RWA tokens (1% of total supply)
  • Complete the standard proposal template
  • Provide technical specifications for implementation
  • Include a clear rationale and expected impact
  • Address potential risks and mitigations

Creating a Proposal

Step 1: Discussion Phase

Before submitting a formal proposal:

  1. Share your idea in the Governance Forum
  2. Use the "Proposal Discussion" category
  3. Gather community feedback
  4. Refine your proposal based on input
  5. Build consensus around your idea

A discussion period of at least 7 days is recommended before moving to a formal proposal.

Step 2: Draft Proposal

Create a comprehensive proposal document including:

  • Title: Clear, concise title describing the proposal
  • Summary: Brief overview of the proposed change
  • Motivation: Why this change is needed
  • Specification: Detailed description of the implementation
  • Technical Implementation: Code changes or parameter adjustments
  • Economic Rationale: Impact on protocol economics
  • Risk Assessment: Potential risks and mitigations
  • Timeline: Implementation schedule
  • Success Metrics: How to measure the proposal's success

Step 3: Formal Submission

Submit your proposal through the Governance Portal:

  1. Connect your wallet
  2. Navigate to "Create Proposal"
  3. Fill in the proposal details
  4. Upload any supporting documents
  5. Specify the on-chain actions to be executed
  6. Submit the proposal (requires minimum token threshold)

Step 4: Review Period

Once submitted, your proposal enters a 3-day review period:

  • Community members can discuss the proposal
  • The Governance Council reviews and provides feedback
  • Technical team assesses implementation feasibility
  • You can make clarifications but not substantial changes

Step 5: Voting Period

After the review period, the proposal enters a 5-day voting period:

  • All token holders can vote For, Against, or Abstain
  • Voting power is determined by token holdings and staking duration
  • Votes are binding and cannot be changed once cast
  • Real-time voting results are visible to all

Step 6: Execution

If approved, the proposal enters a 2-day timelock before execution:

  • Parameter changes are executed automatically
  • Code changes require implementation by the development team
  • Treasury allocations are processed by the treasury multisig
  • Results are documented and communicated to the community

Proposal Lifecycle States

A proposal can be in one of the following states:

  • Draft: Being prepared, not yet submitted on-chain
  • Submitted: Formally submitted, in review period
  • Active: In voting period
  • Succeeded: Passed voting, waiting for execution
  • Queued: Passed voting, in timelock period
  • Executed: Successfully implemented
  • Defeated: Failed to reach required votes
  • Expired: Passed but not executed within timeframe
  • Canceled: Withdrawn by the proposer

Voting on Proposals

How to Vote

  1. Connect your wallet to the Governance Portal
  2. Navigate to "Active Proposals"
  3. Review the proposal details
  4. Select your vote: For, Against, or Abstain
  5. Confirm the transaction in your wallet

Voting Strategies

Consider these factors when voting:

  • Protocol Health: Will this improve the protocol's security and stability?
  • User Impact: How will this affect protocol users?
  • Economic Impact: What are the financial implications?
  • Technical Feasibility: Can this be implemented effectively?
  • Alignment with Vision: Does this align with RWAPool's long-term goals?

Delegation

If you cannot actively participate in governance, you can delegate your voting power:

  1. Navigate to the "Delegation" section in the Governance Portal
  2. Enter the address of your chosen delegate
  3. Confirm the delegation transaction
  4. Your delegate can now vote with your voting power
  5. You can change or revoke delegation at any time

Proposal Templates

RWAPool provides standard templates for different proposal types:

Parameter Change Template

# Parameter Change Proposal: [Title]

## Summary
[Brief description of the parameter change]

## Current Value
[Current parameter value]

## Proposed Value
[Proposed new value]

## Motivation
[Why this change is needed]

## Impact Analysis
[How this change will affect the protocol]

## Technical Implementation
[Specific contract and function to be called]

## Timeline
[When this change should be implemented]

Code Change Template

# Code Change Proposal: [Title]

## Summary
[Brief description of the code change]

## Motivation
[Why this change is needed]

## Functional Specification
[What the code will do]

## Technical Specification
[How the code will be implemented]

## Test Plan
[How the change will be tested]

## Security Considerations
[Potential security implications]

## Backwards Compatibility
[Impact on existing functionality]

## Implementation Timeline
[Development and deployment schedule]

Treasury Allocation Template

# Treasury Allocation Proposal: [Title]

## Summary
[Brief description of the allocation]

## Amount Requested
[Amount of tokens or funds requested]

## Recipient
[Who will receive the funds]

## Purpose
[What the funds will be used for]

## Expected Outcomes
[Measurable results expected]

## Reporting Plan
[How progress will be reported]

## Disbursement Schedule
[When and how funds will be distributed]

Proposal Examples

Example 1: Fee Adjustment

# Parameter Change Proposal: Reduce Protocol Fee from 1% to 0.75%

## Summary
This proposal aims to reduce the protocol fee from 1% to 0.75% to increase competitiveness and attract more users.

## Current Value
Protocol Fee: 1% of all yield generated

## Proposed Value
Protocol Fee: 0.75% of all yield generated

## Motivation
Analysis shows that reducing the fee can lead to higher overall protocol revenue by attracting more TVL, while remaining sustainable for protocol operations.

## Impact Analysis
- Projected 25% increase in TVL over 6 months
- Estimated 15% increase in total fee revenue despite lower percentage
- Improved competitive position against similar protocols

## Technical Implementation
Call setProtocolFee(75) on FeeController contract at 0x1a2b3c...

## Timeline
Implement immediately after proposal approval and timelock period

Example 2: New Asset Class

# Asset Onboarding Proposal: Add Support for Commercial Mortgage-Backed Securities (CMBS)

## Summary
This proposal seeks to add CMBS as a supported asset class in RWAPool, enabling the creation of CMBS-backed pools.

## Motivation
CMBS represent a $500B market with stable yields that would benefit from on-chain access and liquidity.

## Specification
- Asset Class: Commercial Mortgage-Backed Securities
- Risk Classification: Medium
- Collateralization Ratio: 130%
- Custodian Partners: Institutional Partner X, Y
- Verification Requirements: Rating agency confirmation, legal documentation, servicer reports

## Technical Implementation
- Add CMBS asset type to AssetRegistry
- Deploy CMBS-specific price oracle
- Implement CMBS valuation model
- Create verification framework for CMBS assets

## Legal Considerations
- Securities compliance framework in place
- Jurisdictional restrictions implemented
- Accreditation requirements enforced

## Timeline
- Development: 6 weeks
- Audit: 3 weeks
- Deployment: 2 weeks after approval

Best Practices

For Proposers

  • Research Thoroughly: Understand the full impact of your proposal
  • Build Consensus: Gather support before formal submission
  • Be Specific: Provide detailed implementation plans
  • Consider Alternatives: Evaluate different approaches
  • Address Feedback: Respond to community concerns
  • Plan Implementation: Have a clear execution strategy

For Voters

  • Due Diligence: Research proposals before voting
  • Consider Long-Term Impact: Look beyond immediate effects
  • Evaluate Trade-offs: Consider both benefits and drawbacks
  • Participate Actively: Vote on all proposals, not just controversial ones
  • Explain Your Vote: Share your reasoning to help others

Proposal Analytics

The Governance Analytics Dashboard provides insights into proposal patterns:

  • Proposal submission frequency
  • Voting participation rates
  • Approval/rejection ratios
  • Voter distribution analysis
  • Historical proposal outcomes

Resources