Skip to main content

Risk Disclosure

This disclosure is provided for informational transparency and should be read together with Compliance, Protocol Legal Aspects, and Risk Model and Safeguards.

Its purpose is to set realistic expectations for users, integrators, and operators regarding technical behavior, market uncertainty, governance variability, and jurisdictional constraints.

General disclosure scope​

Materials are provided for information purposes only and do not constitute legal, tax, investment, accounting, or other professional advice.

Nothing in these materials should be interpreted as a recommendation to buy, sell, or hold any token or asset, a guarantee of protocol performance or financial outcome, or a representation that participation is legally permitted in every jurisdiction.

Any decision to interact with protocol-related services should be based on independent analysis, local legal context, and personal risk tolerance rather than on generalized documentation alone.

Software and infrastructure basis​

Protocol software and related infrastructure are provided on an "as is" and "as available" basis, subject to technical constraints, on-chain conditions, governance outcomes, and external dependencies.

This includes potential limitations from network congestion, third-party infrastructure, indexer lag, external integrations, and user-side wallet/tooling conditions. In decentralized environments, these factors can materially influence usability, timing, execution quality, and perceived service continuity.

Protocol correctness and service experience are related but not identical. Users should account for infrastructure variability when assessing reliability.

Core risk categories​

1) Smart contract and integration risk​

Even audited contracts can contain unknown defects or edge-case behavior. Integration mismatches between modules, registries, and interface infrastructure can also produce incorrect assumptions about state and process. Upgrades and parameter changes, while governed, may introduce new interactions that are not fully anticipated in prior environments.

Because of this, users and operators should treat any software system as probabilistic in risk terms, not as absolutely failure-proof.

2) Market and liquidity risk​

Liquidity can vary materially across markets and time windows. As a result, slippage and volatility can significantly affect execution quality. During stressed periods, rapid repricing and temporary dislocations may occur even when contracts perform as intended, and these conditions can create outcomes that differ from user expectations.

Market participation should therefore be sized according to risk capacity, not only expected upside.

3) Governance and parameter risk​

Governance outcomes can change protocol-level parameters, including fees, thresholds, and operational constraints. Participation imbalance or delayed decision execution may affect policy quality and timing. Users and operators should account for the fact that governance is a dynamic process rather than a fixed static configuration.

This means assumptions that were valid in one governance epoch may not remain valid indefinitely.

4) Operational and infrastructure risk​

Operational dependencies such as RPC endpoints, indexers, and frontend infrastructure can fail or degrade. Incident response quality varies by service provider and can influence user-facing impact. Third-party provider failures or delays may reduce access quality and data timeliness.

Operational resilience therefore depends on both protocol design and service-layer execution quality.

Legal classification and treatment of decentralized systems can differ by jurisdiction and may evolve over time. Regulatory guidance can shift, and enforcement posture may vary significantly across regions. This creates ongoing legal uncertainty for both users and operators.

Users and operators should periodically reassess legal assumptions rather than relying on one-time interpretations.

6) Operator and interface risk​

Operators and interface providers may implement different eligibility standards, policy controls, and user restrictions based on local legal obligations. Access conditions can therefore vary across service layers even on shared protocol rails. Local terms and disclosures may supersede generalized documentation in specific jurisdictions.

Before using a service, participants should review the specific operator’s terms, eligibility policy, and disclosure stack.

User responsibility​

Participants are responsible for evaluating legal eligibility, technical suitability, and financial risk tolerance before and during use. This includes wallet security, transaction-flow reliability, dependency risk of third-party interfaces, and local legal restrictions. Users should independently verify critical information and seek qualified professional advice where necessary.

Risk responsibility in decentralized systems is shared, and user-side due diligence remains a core safety mechanism.

Forward-looking uncertainty​

Future functionality, integrations, governance outcomes, and legal treatment are uncertain and may change. No statement in documentation should be treated as a promise of future availability, profitability, or legal status.

Past behavior, current metrics, and roadmap items do not guarantee future outcomes.

This applies equally to protocol features, ecosystem integrations, and service distribution models.

No warranty and limitation context​

The following limitations apply:

  • No implied warranty of uninterrupted service

    • Availability may be affected by network, infrastructure, or integration constraints.

  • No implied warranty of merchantability or fitness for a specific purpose

    • Materials describe the protocol and related risks but do not guarantee suitability for individual use cases.

  • No implied warranty of non-infringement in all contexts

    • Ecosystem participants remain responsible for their own implementation, distribution, and service-layer compliance posture.

  • Participant risk assumption

    • Interaction with decentralized infrastructure and volatile markets is undertaken at the participant’s own risk.

  • Service-layer responsibility

    • Jurisdiction-specific service obligations remain with the relevant operator entity.

By continuing to interact with protocol-related services, users acknowledge these risk conditions and the need for ongoing independent assessment.

See also​