> For the complete documentation index, see [llms.txt](https://botlyz.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://botlyz.gitbook.io/docs/english/signature-et-transparence.md). # Signature and transparency Botlyz is a software editor, not a fund manager. You keep full control of your configuration, your keys, and your funds. This goes through a digital signature of each strategy configuration. ## What you sign When you deploy a strategy, you sign a **complete and readable document** that contains: 1. **The strategy**: its name, its logic (in plain English), the engine version 2. **All trading parameters**: pair, indicator periods, envelopes, entry/exit thresholds, conditions 3. **The risk parameters**: your leverage, allocation as a percentage of capital, stop-loss, take-profit 4. **Your bounds**: the risk limits you set yourself (maximum leverage, maximum exposure) 5. **The reoptimization rule**: how the strategy can update itself (automatically according to your rules, or pending your validation) 6. **The fees**: the protocol fee of 10 bps (0.10%), charged automatically by the Lighter platform via the "partner attribution" program, capped at 10 bps 7. **The risk warnings**: a precise list of the risks you acknowledge (partial or total loss, liquidation in case of leverage, etc.) 8. **The terms and conditions**: version and hash of the legal document you accepted All these elements are combined into a canonical JSON document (sorted keys, standardized format) and hashed in SHA-256. This hash becomes the **immutable fingerprint** of your configuration. > **Note on the fees.** The protocol fee of 10 bps is charged and paid out by the platform: it is not a Botlyz invoice or commission. Botlyz takes no commission on your gains. The Lighter platform's own fees (trading, funding) apply separately, independently of Botlyz. See [Fees](/docs/english/frais.md) for details. ## Why sign ### Transparency The EIP-712 signature is an Ethereum standard. It makes **every parameter display in plain text** in your wallet (MetaMask, Ledger, etc.), readable by you, before you accept. Unlike a blockchain transaction (which is often unreadable for the user), you see: * Your address * The strategy key * The engine hash * The platform (Lighter) * The fees in basis points * The fingerprint of your configuration * The terms and conditions hash * The timestamp Nothing is hidden. You can download the full document **before** signing, read it in the interface, share it, or archive it. ### Control By signing, you attest: **I am the one authorizing this configuration, with these precise parameters, now**. The signature is cryptographically tied to your wallet. It proves that you acted, and exactly when. ### Legal immutability The pair (document + signature) is archived in Botlyz's database and provided to you for download (document + hash + signature). If a dispute arises, you can prove: * Exactly which parameters you signed * When you signed them * That you are indeed the one who did it This is your proof, and it is equivalent to the one kept by Botlyz. ## How it works technically ### The EIP-712 signature EIP-712 is an Ethereum standard that creates a "typed message". Unlike a simple `personal_sign` that just displays raw text or a cryptic blob, EIP-712 structures the data: ``` Domain: Botlyz (v1, mainnet) Type: StrategyConfiguration You sign: - wallet: 0x1234... - strategyKey: SIGMA_V2_1 - engineVersionHash: sha256:abcd... - venue: lighter - feeBps: 10 - documentHash: 0x5678... (SHA-256 hash of your complete config) - cguHash: 0x9abc... (hash of the accepted terms and conditions) - issuedAt: 1719835200 (timestamp) ``` Your wallet displays these fields in readable language. You click "Sign". ### The canonical document The document you sign is a **canonical** (standardized) representation of your configuration. This means: * The JSON keys are always in the same order (alphabetical) * There are no unnecessary spaces * The format is identical on every generation Why? Because the Botlyz server regenerates the same document from your parameters and recomputes the hash. If the hash matches, then nothing has changed. It is an integrity check. ### Retrieval and verification After your signature: 1. Botlyz receives your typed message, your signature, and your document 2. It recovers your wallet address from the signature (thanks to cryptography) 3. It verifies that the recovered address matches your account (security: you cannot forge someone else's signature) 4. It recomputes the document hash and compares it to the signed hash (verification: no parameter has changed) 5. It archives everything: document + signature + hash + typed message 6. You receive a copy (downloadable in PDF and JSON) All of this takes a second, costs nothing in gas or fees, and stays off-chain. It is Web3 for the UX and the cryptography, not for the blockchain. ## Modification and re-signature Your configuration is never modified silently. ### Case 1: you change the parameters You go into the configurator, adjust the leverage, modify a period, change a limit. You click "Deploy". Result: a **new document** is generated. The parameters have changed, so the hash changes. You must **sign again**. The old signature stays archived (status `superseded`), the new one becomes `active`. The engine only deploys the configuration that matches an **active signature**. No deployment without an up-to-date signature. ### Case 2: Botlyz releases a new engine version The "SIGMA v2.1" engine is replaced by "SIGMA v3". It is a **major release**: the logic changes. Result: 1. You receive a **notification** that displays the diff between the two versions (what changed in the logic) 2. Your strategy keeps running on "SIGMA v2.1" (old signature still valid) 3. You can read the diff, then click "Migrate" 4. A new document is generated with `engineVersionHash: sha256:xyz` (new version) 5. You sign again 6. The engine switches to "SIGMA v3" once your new signature is in place No silent switchover. You control the timing. ### Case 3: parameter reoptimization The "adaptive reoptimization" mode is not a decision that Botlyz makes on your behalf: it is a **deterministic rule that you define and sign in advance** (objective, frequency, bounds, criterion). Once signed, this rule applies mechanically, without any discretionary judgment from Botlyz. The software merely executes your rule within the bounds you have set. In concrete terms, the parameter can evolve **according to the objective and deterministic criterion that you yourself configured and signed** (for example: keep the moving-average period that maximizes a given indicator over the rolling window), within the bounds you have set (for example: without ever exceeding `max_ma_period=200`). It is your mechanical criterion that decides, not a judgment by Botlyz. Two scenarios: * **Adaptive mode**: the rule you signed applies mechanically within the bounds you have set. You receive a notification *after* the criterion is applied ("Adaptive rule applied: MA 140 → 145"). No new signature is required, because it is not a new choice: it is the execution of the rule you had already defined and signed. **You can disable this mode or switch back to manual validation at any time.** * **Manual mode**: no evolution is applied without you. The result of the criterion is proposed in the interface; you examine it, accept it, or refuse it. If you accept, the document changes, so a new signature is required. **Never any silent change or any choice made by Botlyz on your behalf**, even with reoptimization. Botlyz exercises no management discretion: only the rule you signed applies. ## What you download After each signature, you can download a copy: ```json { "platform": "Botlyz", "doc_type": "strategy_configuration", "doc_version": "1.0", "strategy": { "key": "SIGMA_V2_1", "display_name": "σ SIGMA v2.1", "engine_version_hash": "sha256:5af4e12c0e2b7a1f9c3d4e5f6a7b8c9d", "logic_summary_fr": "Mean-reversion sur enveloppes de moyenne mobile avec filtre RSI..." }, "venue": { "key": "lighter", "fee_program": "partner_attribution", "fee_bps": 10, "fee_cap_bps": 10 }, "params": { "pair": "HYPE", "ma_period": 140, "envelopes": [[0.03, 1.0]], "rsi_filter": {"period": 80, "band": [42, 58]}, "timeframe": "5m" }, "risk": { "leverage": 2, "allocation_pct": 75, "sl_pct": 0.11 }, "bounds": { "max_leverage": 5, "max_exposure_usd": 2000 }, "reopt": {"mode": "none"}, "risk_acknowledgments": [ "total_or_partial_loss", "leverage_liquidation", "backtests_not_indicative", "automatic_execution_no_intervention", "software_not_advice_no_result_obligation", "venue_risks_smart_contracts_non_eu_regulated" ], "cgu": { "version": "2.0", "sha256": "0x7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b" }, "wallet": "0x1234567890123456789012345678901234567890" } ``` This JSON is your proof. It attests that: * These were your parameters * At that precise moment * That you approved The signature (65 bytes in hexadecimal) is the cryptographic guarantee that you alone can produce it. ## Who has access to the API key Important: **the signature does not directly grant access to anything**. Botlyz uses a separate API key to place orders on Lighter (the exchange). This key: * You provide it via the configurator, encrypted in transit (HTTPS) * Botlyz stores it encrypted in the database * It is used **only to place orders** according to your strategy * It has **no withdrawal rights** (the API keys are trade-only, no withdrawal of funds is possible) * It is isolated: a compromise of one key only concerns that account The EIP-712 signature attests the **configuration**, not the access. You keep control of your API keys and can revoke them at any time. See [Security and non-custodial model](/docs/english/securite-non-custodial.md). ## Legal horizon This approach meets the transparency requirements expected of a software editor: * **Decision left to the client** (no portfolio management): you configure and you sign * **Timestamped and provable consent**: EIP-712 and archiving * **Transparency of the rules**: every parameter is readable before signing * **Traceability**: who changed what, when, and why (document + log) Botlyz cannot execute your strategy without an active signature. It is a technical and legal lock. See also the [Legal notice](/docs/english/mentions-legales.md). ## Important warnings > **Trading carries a risk of total loss of capital.** Past performance is not indicative of future performance. Even with a signed strategy, you can lose money. > **No investment advice.** Botlyz is an automation tool. You make your own decisions. Read every parameter, understand the logic, and only deploy what you are comfortable with. > **Leverage = increased risk.** Leverage amplifies losses as well as gains and can lead to the liquidation of your position. Understand leverage before signing it. > **Decentralized infrastructure.** Lighter is a non-custodial protocol. Smart contract risks (bug, exploit) exist. Botlyz does not have control of the platform. > **API keys.** Keep them secure. They are trade-only (no withdrawal possible), but in the event of a leak, a third party could place orders on your account. Revoke them at the slightest suspicion. See also the [Risk warning](/docs/english/avertissement-risques.md). ## In summary * **You configure**: every parameter is visible and modifiable * **You sign**: a complete, readable document, cryptographically attached to you * **You control**: no change without a new signature * **You archive**: a copy (document + hash + signature) as proof * **Botlyz executes**: only what you signed, as long as it is signed This is technology in the service of trust: no blind trusted third party, but cryptographic proof and transparency. --- # 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://botlyz.gitbook.io/docs/english/signature-et-transparence.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.