Security and risks

Status

Abyss is experimental and unaudited. Repository testing, machine review, penetration exercises, reproducible deployment evidence, and provenance controls do not replace an independent audit or establish safety.

User-level safeguards

• Verify the RISE Mainnet chain ID before every write.
• Verify token and contract addresses, not symbols.
• Simulate the exact call before requesting a wallet signature.
• Use amount minimums, amount maximums, price limits, and short deadlines.
• Treat approvals as separate transactions and approve only the intended spender.
• Wait for a successful receipt before assuming state changed.
• Do not use unsupported fee-on-transfer or rebasing tokens.
• Do not send native ETH to the protocol's ERC-20 workflows.
• Revoke allowances that are no longer required.

Core protections

The pool implementation uses a reentrancy lock, checks-effects-interactions ordering, callback balance-delta verification, checked fee liabilities, bounded casts, and explicit authorization for privileged functions. Quote-fee accounting and required oracle writes live in core so alternate routers cannot bypass them.

These controls reduce specific implementation risks. They do not protect against malicious token contracts, economic manipulation, private-key compromise, wallet compromise, chain failure, bridge failure, RPC censorship, MEV, or loss caused by market movement.

Token behavior

Pool creation is permissionless and does not call token contracts. A pool can therefore be created for a malicious, nonstandard, worthless, or mislabeled token. Version one excludes fee-on-transfer and rebasing assets. ERC-20 optional return handling does not make every unusual token compatible.

Oracle risk

Canonical observations and truncated observations are endogenous. They derive from Abyss pool activity. A truncated stream caps movement per eligible block but can lag legitimate markets and can still be influenced over time. It is not a lending mark, USD adapter, or listing approval.

Liquidity risk

Concentrated liquidity can become inactive, leave a provider single-sided, and expose the position to impermanent loss and adverse selection. Permissionless removal means displayed liquidity can disappear. Optional NFT locking applies only to positions actually deposited into the locker.

Governance risk

Governance cannot pause or upgrade pools, but it can enable fee tiers, register oracle configurations, and change bounded protocol-fee denominators. The FeeVault owner can transfer treasury assets. Ownership and fee settings are mutable chain state and should be monitored.

Periphery and service risk

Routers, quoters, position managers, the UI, API, indexer, wallet providers, and RPC services can fail independently. Core positions remain represented onchain, but a failed interface can prevent convenient discovery or transaction construction. Indexed data can lag; live RPC establishes current mutable state.

Incident posture

If a quote, balance, position owner, pool address, or transaction state is inconsistent, stop signing. Confirm chain ID, inspect the transaction calldata and explorer state, use a separate RPC, and distinguish indexer lag from onchain state. Never share a private key, seed phrase, or wallet recovery material with support.