> For the complete documentation index, see [llms.txt](https://elysia.gitbook.io/elysia-perps/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elysia.gitbook.io/elysia-perps/risk-and-security/smart-contract-security.md). # Smart Contract Security On Elysia Perps, your collateral is held by an **on-chain smart contract**, not in a private wallet. Trading (order matching, margin, PnL) happens on a fast off-chain engine, but the money itself sits in an auditable contract you can verify. This page explains how that contract is protected and, just as important, what trust assumptions you are still taking on today, and where the protocol is headed. ## On-chain custody * You deposit by sending ERC-20 tokens to the contract; your Elysia Perps balance appears once the deposit is confirmed on-chain. * Your funds remain in the contract, governed by public code, for as long as you trade. * You can request a withdrawal back to your own wallet at any time. Each request is reviewed within 48 hours. Your tokens are never taken into a private wallet. They can only move through the contract's rules, which anyone can read. ## The contract's protections The custody contract is built on widely used, battle-tested contract standards, each guarding a specific risk: | Control | What it does | What it protects against | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | **Supported-token whitelist** | Only tokens explicitly whitelisted can be deposited as collateral | Junk or malicious tokens being credited as collateral | | **Constrained withdraw** | Only the authorized contract key can trigger a withdrawal transaction, **and it can only send funds to the account that owns them** | Arbitrary transfers; funds being sent anywhere but back to you | | **Emergency pause** | Deposits and withdrawals can be paused in an emergency | Continued fund movement during an active incident | | **Reentrancy guard** | Blocks reentrancy attacks on the withdrawal path | A classic drain exploit | | **Two-step ownership transfer** | Control can only be handed over in a deliberate, two-step process | A single fat-fingered or hijacked transfer of control | | **Upgradeable proxy (UUPS)** | The contract address stays fixed; only the implementation behind it can be replaced | Having to migrate funds to a new address to ship a fix | ### Why withdrawals are contract-triggered You do not call `withdraw` yourself. You submit a withdrawal *request*, and the authorized contract key executes the on-chain transaction. This lets the protocol settle your off-chain positions and balance before releasing funds. The key protection is that the withdraw function **can only return a user's own funds to that user**. The key cannot redirect them elsewhere. Each withdrawal request is reviewed before it is executed, within 48 hours. ### Reorg protection Deposits are only credited after a set number of block confirmations, so a short-lived chain reorganization cannot create a phantom balance. ## The trust assumptions, stated plainly Custody here is on-chain. Here is exactly what that covers today: * **The contract key is a trust point.** Because the contract is **upgradeable** and withdrawals are **contract-triggered**, whoever holds the authorized key can execute upgrades and withdrawals. The withdraw function restricts *destination* (funds go back to their owner) and the pause/whitelist are key-holder controls, but the security of that key matters. * **Matching is off-chain, and currently centralized.** Order matching and margin are computed by an off-chain engine (today a single service) and are not proven on-chain. Custody is on-chain; execution integrity is operational. None of this is unusual for a hybrid DEX: it is the standard trade-off of "custody of a DEX, speed of a CEX." The point is that you should know where the on-chain guarantees end and the operational ones begin. ## Where this is headed Elysia Perps is built as a perpetuals **module**, and its direction is to move the parts that are centralized today toward a decentralized model: * **A separate, decentralized matching layer.** The off-chain engine is intended to be decomposed into its own layer rather than run as a single service, reducing the reliance on one operator. A zero-knowledge proof layer is planned to bring matching and settlement integrity further on-chain over time. * **Multi-party governance of privileged actions.** Upgrades, the pause, the token whitelist, and market parameters are single-key controls today; the intended direction is for these to move to a multi-party governance model rather than a single key-holder. These are the roadmap, not the current state. This page describes what is true today so you can judge the trust assumptions as they are now. ## What you can do * **Verify the contract.** The custody contract is deployed and verifiable on-chain at `0x3C8643508c5568621CB6d21119e4076551522c84`. You can inspect its code and its holdings directly on a block explorer. * **Withdraw what you are not actively trading.** On-chain custody is strongest for funds sitting in the contract under your account, but the simplest risk reduction is not to keep more in Elysia Perps than you need. * **Watch for pause or upgrade announcements** during incidents. ## Where to go next * The risk of the collateral token you deposit: [Collateral Risk](/elysia-perps/risk-and-security/collateral-risk.md). * How deposits and withdrawals work step by step: **Getting Started →** [**Deposit**](/elysia-perps/getting-started/deposit.md) and [Withdraw](/elysia-perps/getting-started/withdraw.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://elysia.gitbook.io/elysia-perps/risk-and-security/smart-contract-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.