Risk Disclaimer
RSVP Token ($RSVP) · BEP-20 · BNB Smart Chain · Based on Whitepaper v1.6 §8 & §12
What can go wrong when you acquire, hold or use RSVP, and what the project does about each risk.
Material risks. Acquiring, holding or using RSVP involves material risks. Read this page in its entirety and seek independent professional advice where appropriate. RSVP is not a capital-protected product, earns no yield and may lose all of its value.
1. What RSVP Is, and Is Not
RSVP is a governance utility token. It is not backed by anything, pays nothing, and its price is set by the market alone.
| Item | Position |
|---|---|
| Classification | Governance utility token for the RSVP Financial DAO Framework |
| Underlying asset | None. RSVP is not backed by, or redeemable for, any currency or other asset, and its price is not managed |
| Holder return | None. RSVP pays no yield, interest, dividend or coupon, and no share of fees, profits or revenue |
| Ownership | RSVP is not a share, bond, loan or other interest in the project, the Foundation or any framework DAO |
| Staking | Gives on-chain voting weight only. Staked RSVP does not grow; the holder withdraws the same amount that was staked |
| Bonds | Security for a role, not a deposit. A bond earns nothing and can only shrink, if withheld for a proven breach of duty |
| Participation rewards | Payment for governance work, set by ecosystem vote, may change or stop, and never calculated as a percentage of RSVP held or staked |
| Framework DAO returns | Any return a framework DAO earns belongs to that DAO and its members. It does not flow to RSVP or to RSVP holders |
2. Price Risk
2.1 Volatility and loss of value
RSVP trades freely and its price may be volatile or fall to zero. Its market price is not managed and may rise or fall sharply.
Mitigation: None can remove this risk. The project does not manage the price and promises no return.
2.2 Liquidity
Markets for RSVP may be thin, making it hard to buy or sell at a fair price.
Mitigation: A 10% allocation supports exchange liquidity and market-making arrangements, but no market, depth or price is guaranteed.
3. Administrative Key Risk
Today, every administrative power in the deployed contract sits with one ordinary wallet. That changes in Phase 2, before public launch.
At the time of writing, the deployed contract contains the administrative functions below, all controlled by a single administrative address that is an ordinary wallet rather than a multi-signature contract. Until ownership moves to the multi-signature and timelock, administrative powers rest with that single address.
| Power | What it allows | Commitment |
|---|---|---|
| Mint | Creating new RSVP beyond the issued supply | Removed or permanently capped at 1,000,000,000 by audited upgrade |
| Minter roles | Authorising other addresses to mint up to an allowance | No minter is authorised today; the role is removed together with the mint function |
| Upgrade | Replacing the contract logic behind the proxy | Placed behind a 3-of-5 multi-signature and a 72-hour timelock |
| Pause | Halting all transfers | Limited to active security incidents; held by the multi-signature |
| Address restriction | Blocking a specific address from transferring | Used only for stolen funds or a binding legal order, each use disclosed |
| Forced burn | Destroying the balance of a restricted address | Held by the multi-signature; used only under a binding legal order, each use disclosed |
| Transfer mode | Switching transfers to an approved-address list | Held by the multi-signature; any change announced through official channels before it takes effect |
| Token recovery | Recovering other tokens sent to the contract by mistake | Used only to return assets to the sender, each use disclosed |
| Ownership | Holding all of the above | Transferred from the single address to the multi-signature and timelock |
Administrative functions were identified from the deployed contract on BNB Smart Chain in October 2026. The supply limit of 1,000,000,000 RSVP is a policy today and becomes enforced by code only after the audited upgrade.
Mitigation: Ownership is transferred to a 3-of-5 multi-signature with independent signers and a 72-hour timelock in Phase 2, before public launch. Pause, address restriction and forced burn are used narrowly, and every use of an administrative power is disclosed.
4. Technology Risk
4.1 Upgrade risk
An upgradeable contract can be changed; a faulty or malicious upgrade could harm holders.
Mitigation: A public timelock applies before any upgrade takes effect, two independent audits cover the token upgrade, and verified source code lets anyone match audited code to deployed code.
4.2 Smart contract risk
Audited code can still contain flaws that have not been discovered.
Mitigation: Two independent audits of the token upgrade and every framework module before mainnet deployment, with all findings published; verified source code on BscScan; and full-lifecycle testnet operation covering staking, tiered voting, bonds, timelock execution and payments.
5. Framework, Regulatory and Delivery Risk
5.1 Framework DAO risk
DAOs using the Framework may make poor decisions, suffer losses, or be captured by a few participants.
Mitigation: Mandates, tiered quorums and delays, bonded delegates and independent reviewers. The RSVP Foundation does not hold, manage or direct any framework DAO’s funds, and each DAO’s members bear its outcomes.
5.2 Regulatory risk
Laws on investment, lending, insurance and savings activity may restrict framework DAOs or framework services.
Mitigation: Each DAO answers for its own legal structure, licences and member eligibility; optional identity and eligibility modules are available; the project will obtain any approval or registration a market requires before framework services are offered there.
5.3 Delivery risk
Roadmap phases may be delayed, changed or not completed.
Mitigation: Phases are ordered by dependency, each beginning only once the previous one has reached its exit milestone, and security gates are never shortened to save time. Progress is measured publicly through the accountability scorecard and monthly reports.
6. Impersonation and Phishing Risk
6.1 Fake websites, contracts and accounts
Fake websites, contracts or support accounts may target holders.
Mitigation: Official contract addresses are published only through the official channels. No RSVP contributor will request your recovery phrase or private keys, and no official channel will ask you to send tokens in order to “verify” a wallet.
| Official channel | Purpose |
|---|---|
| rsvptoken.com | Official website: project information, whitepaper and announcements |
| X: @RSVPToken | Announcements |
| team@rsvptoken.com | Questions, feedback and complaints |
| Telegram: @RSVPToken | Questions, feedback and complaints |
| Contract | 0xca891a9fb2807028b68a2c853fc796c812aab6c9 |
7. Holder Safeguards and Their Status
Some protections are guaranteed by code, some depend on votes, and some are promises still to be delivered. Each is labelled so you can judge it.
| Label | Meaning |
|---|---|
| Code-enforced | Built into audited contract logic that anyone can read on BscScan; no individual or committee can override it |
| Governance-bound | Set through the governance process, and changeable only by a vote that meets the required tier |
| Operational pledge | A promise the project has made and must still deliver; judge it by published audits, disclosures and on-chain changes |
| Safeguard | Mechanism | Status |
|---|---|---|
| Voting power cannot be borrowed mid-vote | Staking checkpoints recorded before voting opens | Code-enforced |
| Approved actions wait before executing | Tier-based timelock | Code-enforced |
| Mandate limits are checked before payment | Charter registry read by execution modules | Code-enforced |
| Proposals need a bond | Governor checks bond before filing | Code-enforced |
| Delegates and committees answer for their votes | Bonds and recall by vote | Governance-bound |
| Framework floors bind every DAO | Set by ecosystem governance | Governance-bound |
| Supply limited to 1,000,000,000 | Policy today; code after the audited upgrade | Operational pledge |
| Admin powers move to multi-sig and timelock | Ownership transfer before public launch | Operational pledge |
| Pause, restriction and forced burn used narrowly | Disclosure of every use | Operational pledge |
| Audits before launch | Two published audit reports | Operational pledge |
Framework modules are in development for testnet during Phase 1. Code-enforced safeguards apply once those modules are audited and deployed.
8. Important Notice
Important. Every party must take note of all risks that may arise from transacting in or using RSVP. The Developer does not guarantee any benefit and/or economic value, in any form, that may arise in the future. Parties transacting in RSVP are required to understand every risk and are advised not to transact if they do not understand or agree to every risk that may exist. By transacting with RSVP, each party is deemed to know and understand all the risks of that transaction.
9. General Disclaimer
This page and the whitepaper are published for informational purposes only and do not constitute an offer to sell, a solicitation to buy, a public offering, or a recommendation of any security, financial instrument or investment product. No part of them forms a prospectus or targets readers in any place where their distribution would break the law.
RSVP and framework services are made available only where lawful. Nothing here should be construed as legal, tax, accounting or investment advice. Consult qualified independent advisors before acquiring, holding or using RSVP, or before forming or joining any financial DAO.
All figures and examples, including default decision-tier values, archetype configurations, scorecard targets, the allocation framework and the roadmap, are illustrative or forward-looking. They reflect current intentions and assumptions, and actual outcomes may differ materially.
- The project may amend the token design, the Framework or any terms based on legal requirements, audit findings or operational developments, and will publish any material change through the official channels under a new version number.
- No representation or warranty is given as to the accuracy, completeness or reliability of this information, which may be revised without notice.
- Participants are responsible for complying with the laws that apply to them.
By acquiring or using RSVP, you confirm that you have read and accept the risks described on this page and in Section 8 of the RSVP Token Whitepaper v1.6. See also the Terms & Conditions.