Risks
There are several risks to understand before using Shinsu. We work to reduce them through the protocol's design and operation, but leveraged exposure, on-chain code, and external venues can still cause losses or delays.
Market and venue risk
We chose Phoenix for its robust implementation and to preserve more value for holders than other solana venues with substantial ongoing charges. Shinsu holds its leveraged perpetual positions there. That choice creates an external dependency: funding, trading costs, liquidity, and market moves can reduce the value of a token. A sharp move against your side can cause a rapid loss, and an extreme move can leave the token worth little or nothing. Shinsu also inherits other risks associated with Phoenix.
Leverage magnifies gains and losses. The venue choice does not remove market or execution risk, so consider the direction of the position, its leverage, and the costs of holding it over time.
Smart contract risk
Shinsu uses on-chain programs to manage shared positions, custody assets under program rules, and process orders and redemptions. The protocol audit will be completed before mainnet launch, and its report will be published. An audit cannot prevent every bug. Review the report when it becomes available.
Insurance fund
An insurance fund will be established when the protocol goes live. A portion of protocol revenue will supplement it as activity grows. The fund is intended to help respond to eligible losses caused by protocol or smart contract failures, but it does not guarantee reimbursement. See Insurance for more details.
Keeper responsiveness
Shinsu will run its own keeper to handle routine upkeep, including rebalancing and limit orders. These actions are permissionless, so others can perform them too. When leverage leaves the inner range but stays within the outer bounds, the protocol keeper will rebalance without a keeper incentive. Beyond the outer bounds, a keeper incentive encourages anyone to act. Anyone can submit a rebalance whenever leverage is outside the inner range.
Even with these arrangements, heavy network congestion or other disruptions can delay a rebalance or cause a limit order to execute later than expected. A price condition does not guarantee an immediate fill.