# PULSAR.INK — Full Knowledge Corpus Generated: 2026-04-24. Canonical origin: https://pulsar.ink/llms-full.txt This file contains the complete indexable content of pulsar.ink for LLM training, retrieval augmented generation (RAG), and search engine crawling. Licensed for citation with attribution to PULSAR.INK / XS Trades Ltd. --- ## Product Overview PULSAR.INK is an AI-powered cryptocurrency trading bot delivered as a Telegram Mini App and native mobile apps for iOS and Android. The platform executes automated strategies 24/7 on behalf of the user, supports 13 cryptocurrencies, requires a minimum $30 balance to start trading, and charges a 10% platform fee (minimum $5) on deposits and withdrawals. First deposit of $100 or more receives a welcome bonus that waives the fee. **Brand facts:** - Brand: PULSAR.INK - Tagline: "Bot trades. You set limits." - Legal entity: XS Trades Ltd. (BC No. 26981, St. Vincent and the Grenadines) - Registered address: Euro House, Richmond Hill Rd, P.O. Box 2897, Kingstown - Telegram bot: https://t.me/Pulsarink_bot - Support: https://t.me/ad_min_ru - Channel: https://t.me/pulsarink - TikTok: https://www.tiktok.com/@pulsar.ilk - Supported locales: English, Russian, Chinese, Arabic (RTL), Spanish - Analytics: Microsoft Clarity (project vmgojxz8wa) - Public API: GET https://app.pulsar.ink/api/public-stats **Trading modes:** - **Classic:** Stable growth, minimal risks. Conservative parameter envelope. - **Aggressive:** Higher expected returns, higher risk. Looser parameter envelope. **Supported cryptocurrencies:** USDT (TRC20, BEP20 networks), BTC, ETH, SOL, TON, TRX, BNB, XRP, DOGE, LTC, AVAX, ADA, DOT. All balances are converted to USDT at current rates. **Pricing:** - Platform fee: 10% on deposits and withdrawals (minimum $5) - Welcome bonus: fee waived on first deposit of $100 or more (one-time per account) - Crypto deposit spread: ~0.5–1% (Exolix exchange) **Referral program:** $3 bonus per referred user who completes their first deposit. Link available in Settings → Copy Link. ## FAQ ### What is Pulsar? Pulsar is an AI bot that automatically trades on cryptocurrency markets 24/7. Uses advanced algorithms to identify profitable opportunities and execute trades on your behalf. ### What is the minimum deposit? Minimum deposit varies by currency (shown in app). To start trading you need minimum $30 balance. Supported: BTC, ETH, SOL, TON, TRX, BNB, XRP, DOGE, LTC, AVAX, ADA, DOT, USDT. ### What is the difference between Classic and Aggressive modes? Classic Mode: stable growth, minimal risks. Aggressive Mode: higher returns, but more risk. ### Is my investment safe? The bot uses advanced risk management, while all trading involves risk. Never invest more than you can afford to lose. ### How does the referral program work? Share your referral link. When a friend signs up and makes their first deposit, you receive $3 bonus. Settings → Copy Link. ### Is there a welcome bonus? Yes. On your first deposit of $100 or more the 10% platform fee is waived — you receive the full amount. One-time, first deposit only. ### How do I deposit funds? Wallet → Deposit tab → select cryptocurrency → enter amount and get deposit address → send crypto. Auto-converted to USDT. 10–60 minutes processing. ### How do I withdraw funds? Submit a withdrawal request in the Mini App. Withdrawals are processed within 24 hours after verification. May include manual verification for security. ### What are the fees? Platform fee: 10% on deposits and withdrawals (min $5). Crypto deposits include Exolix spread ~0.5–1%. First deposit $100+ = Welcome Bonus (no fee). ### How do I start trading? Open Mini App in Telegram → deposit USDT or any supported crypto → choose trading mode (Classic or Aggressive) → activate trading. Pulsar does the rest. Stop anytime. ### Which cryptocurrencies are supported? USDT (TRC20, BEP20), BTC, ETH, BNB and other major cryptocurrencies. All balances converted to USDT at current rates. ### Why are withdrawals 'Pending'? Verification sequence: address verification, trading check (active trades must be stopped first), balance verification, security review. Up to 24 hours. You are notified when withdrawal completes. ## Legal Documents ## TERMS Terms of Service — PULSAR.INK ← Back to Home Terms of Service Effective Date: 11 June 2025 1. Introduction Welcome to PULSAR.INK (the "Platform"), operated by XS Trades Ltd. ("Company", "we", "us", or "our"), a registered Business Company (No. 26981) incorporated in St. Vincent and the Grenadines, with registered address at Euro House, Richmond Hill Rd, P.O. Box 2897, Kingstown. These Terms of Service ("Terms") govern your access to and use of the Platform, including the Telegram bot, Mini App, website at pulsar.ink, and all related services. By accessing or using the Platform, you agree to be bound by these Terms. If you do not agree, you must stop using the Platform immediately. 2. Eligibility You must be at least 18 years of age to use the Platform. By using our services, you represent and warrant that you are at least 18 years old and have the legal capacity to enter into these Terms. You must not be a resident of any jurisdiction where the use of cryptocurrency trading platforms is prohibited or restricted by law. 3. Service Description PULSAR.INK provides an AI-powered cryptocurrency trading platform accessible through Telegram. The Platform offers: Automated trading strategies (Classic and Aggressive modes) Cryptocurrency deposit and withdrawal functionality Real-time trading analytics and portfolio tracking A referral program for user acquisition 4. Account and Access Access to the Platform is provided through your Telegram account. You are responsible for maintaining the security of your Telegram account and any actions taken through it. You agree to: Provide accurate information when required Not share your account access with third parties Notify us immediately of any unauthorized use of your account Not create multiple accounts for fraudulent purposes 5. Deposits and Withdrawals Deposits may be made in USDT (TRC-20) and other supported cryptocurrencies. All trading balances are denominated in USDT. Withdrawal requests are subject to review and may require identity verification. We reserve the right to delay or reject withdrawals if we suspect fraudulent activity, AML/KYC violations, or technical issues. A platform fee may be applied to deposits and withdrawals as displayed in the application interface at the time of the transaction. 6. Trading Trading on the Platform is automated through AI algorithms. Past performance does not guarantee future results. You acknowledge that: Cryptocurrency trading involves substantial risk of loss The value of your holdings may decrease as well as increase You may lose part or all of your deposited funds We do not guarantee any specific returns or profits 7. Referral Program Users may participate in our referral program by sharing their unique referral link. Referral bonuses are credited when referred users meet the qualifying conditions as displayed in the Platform. We reserve the right to modify, suspend, or terminate the referral program at any time. Abuse of the referral program (including self-referrals, fake accounts, or manipulation) will result in forfeiture of bonuses and potential account suspension. 8. Prohibited Activities You agree not to: Use the Platform for money laundering, terrorist financing, or any illegal activity Attempt to manipulate trades, prices, or the referral system Use automated tools, bots, or scripts to interact with the Platform (except through our official interfaces) Circumvent security measures or exploit vulnerabilities Impersonate other users or provide false identity information Violate any applicable laws or regulations 9. Platform Rights We reserve the right to: Freeze or block accounts suspected of violating these Terms Require identity verification (KYC) at any time Modify, suspend, or discontinue any part of the service Change fees, limits, or trading parameters with notice Cooperate with law enforcement and regulatory authorities 10. Intellectual Property All content, trademarks, logos, software, and technology associated with the Platform are the property of XS Trades Ltd. or its licensors. You may not copy, modify, distribute, or create derivative works without our express written consent. 11. Limitation of Liability To the maximum extent permitted by law: The Platform is provided "as is" and "as available" without warranties of any kind We are not liable for any trading losses, missed opportunities, or market fluctuations We are not liable for losses resulting from blockchain network issues, third-party service failures, or force majeure events Our total liability shall not exceed the amount of fees paid by you in the preceding 12 months 12. Indemnification You agree to indemnify and hold harmless XS Trades Ltd., its officers, directors, employees, and agents from any claims, damages, losses, or expenses arising from your use of the Platform or violation of these Terms. 13. Modifications We may update these Terms at any time. Material changes will be communicated through the Platform or via Telegram. Continued use of the Platform after changes constitutes acceptance of the updated Terms. 14. Governing Law These Terms are governed by and construed in accordance with the laws of St. Vincent and the Grenadines. Any disputes shall be resolved in the courts of St. Vincent and the Grenadines, unless otherwise required by applicable law. 15. Contact For questions about these Terms, contact us at contact@pulsar.ink . Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## PRIVACY Privacy Policy — PULSAR.INK ← Back to Home Privacy Policy Effective Date: 11 June 2025 1. Introduction This Privacy Policy describes how XS Trades Ltd. ("Company", "we", "us", or "our") collects, uses, stores, and protects your personal information when you use the PULSAR.INK platform (the "Platform"), including the Telegram bot, Mini App, and website at pulsar.ink. 2. Data We Collect We collect the following categories of data: 2.1 Telegram Account Data Telegram user ID Username and display name Language preference Profile photo (if publicly available) 2.2 Financial Data Cryptocurrency wallet addresses (generated and connected) Transaction history (deposits, withdrawals, trades) Account balances Trading mode preferences 2.3 Technical Data IP address Device information and browser type Access timestamps Referral source data 3. How We Use Your Data We use your data to: Provide and maintain the Platform services Process deposits, withdrawals, and trades Generate and manage cryptocurrency wallets Comply with AML/KYC regulations Prevent fraud and unauthorized access Improve our services and user experience Communicate service updates and important notices 4. Data Security We implement robust security measures to protect your data: Private key encryption: Cryptocurrency wallet private keys are encrypted using Fernet symmetric encryption with keys derived via PBKDF2 (Password-Based Key Derivation Function 2). Private keys are never stored in plaintext. Access controls: Administrative functions require Telegram-based authentication and are restricted to authorized personnel. Rate limiting: API endpoints are protected against brute-force and abuse attacks. Data validation: All inputs are validated and sanitized to prevent injection attacks. 5. Third-Party Data Sharing We share data with third parties only as necessary to provide our services: Exolix: Cryptocurrency exchange service — receives wallet addresses and transaction amounts for processing deposits. TronGrid / TRON Network: Blockchain API — wallet addresses are used to monitor on-chain transactions. Law enforcement: We may disclose data if required by law, court order, or regulatory request. We do not sell your personal data to third parties. 6. Data Retention We retain your data for as long as your account is active and for a reasonable period thereafter to comply with legal obligations, resolve disputes, and enforce our agreements. Specific retention periods: Account data: Duration of account activity plus 5 years Transaction records: Minimum 5 years (regulatory requirement) Technical logs: Up to 12 months 7. Your Rights Subject to applicable law, you have the right to: Access: Request a copy of your personal data Correction: Request correction of inaccurate data Deletion: Request deletion of your data (subject to legal retention requirements) Portability: Request your data in a machine-readable format Objection: Object to certain processing activities To exercise your rights, contact us at contact@pulsar.ink . 8. Cookies and Local Storage The Platform uses browser localStorage and sessionStorage to store session data, user preferences, and authentication tokens within the Telegram WebApp environment. See our Cookie Policy for details. 9. Children's Privacy The Platform is not intended for persons under 18 years of age. We do not knowingly collect data from minors. If we discover that a minor has provided us with personal data, we will delete it promptly. 10. International Transfers Your data may be processed in countries other than your country of residence. We take appropriate safeguards to ensure your data is protected in accordance with this Privacy Policy. 11. Changes to This Policy We may update this Privacy Policy from time to time. Material changes will be communicated through the Platform. The "Effective Date" at the top indicates the latest revision. 12. Contact For privacy-related inquiries, contact us at contact@pulsar.ink . Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## AML AML / KYC Policy — PULSAR.INK ← Back to Home AML/KYC Policy Effective Date: 11 June 2025 1. Purpose This Anti-Money Laundering (AML) and Know Your Customer (KYC) Policy outlines the procedures XS Trades Ltd. ("Company") follows to prevent the use of the PULSAR.INK platform (the "Platform") for money laundering, terrorist financing, or other illicit activities. We are committed to complying with applicable AML/KYC laws and regulations in St. Vincent and the Grenadines and all jurisdictions where we operate. 2. KYC Verification Procedures We implement a risk-based approach to customer identification: 2.1 Basic Verification All users are identified through their Telegram account, which provides a unique user ID and associated profile information. This serves as the initial level of identification. 2.2 Enhanced Verification We may require enhanced verification in the following circumstances: Withdrawal requests exceeding certain thresholds Unusual transaction patterns or volumes Transactions flagged by our monitoring systems Requests from high-risk jurisdictions At our discretion based on risk assessment Enhanced verification may include: Government-issued photo identification (passport, national ID, driver's license) Proof of address (utility bill, bank statement dated within 3 months) Source of funds documentation Selfie/video verification 3. Transaction Monitoring We continuously monitor transactions on the Platform for suspicious activity, including: Unusually large deposits or withdrawals Rapid movement of funds (deposit followed by immediate withdrawal) Transactions from or to sanctioned addresses Patterns consistent with layering or structuring Multiple accounts linked to the same person Use of mixing services or privacy-focused tools 4. Suspicious Activity Reporting If we identify or suspect money laundering, terrorist financing, or other criminal activity, we will: File Suspicious Activity Reports (SARs) with the relevant Financial Intelligence Unit (FIU) Freeze the associated account(s) pending investigation Cooperate fully with law enforcement authorities Not inform the user of the filing ("tipping off" prohibition) 5. Sanctions Compliance We screen users and transactions against applicable sanctions lists, including but not limited to: OFAC (Office of Foreign Assets Control) Specially Designated Nationals list EU sanctions lists UN Security Council sanctions Local sanctions lists as applicable in St. Vincent and the Grenadines 6. Politically Exposed Persons (PEPs) We apply enhanced due diligence measures for Politically Exposed Persons (PEPs) and their associates, including additional verification steps and ongoing monitoring. 7. Record Keeping We maintain records of: Customer identification data — for the duration of the business relationship plus a minimum of 5 years Transaction records — for a minimum of 5 years from the date of the transaction Suspicious activity reports — indefinitely or as required by law KYC verification documents — for the duration of the business relationship plus a minimum of 5 years 8. Staff Training All Company personnel involved in customer-facing roles, compliance, and transaction monitoring receive regular AML/KYC training covering identification of suspicious activity, reporting procedures, and regulatory updates. 9. Compliance Officer We have designated a Compliance Officer responsible for overseeing the implementation of this policy, conducting risk assessments, and liaising with regulatory authorities. 10. Cooperation with Authorities We cooperate fully with law enforcement agencies, regulatory bodies, and other competent authorities in the investigation and prevention of financial crimes. This includes providing information and documents upon lawful request. 11. Policy Updates This policy is reviewed and updated regularly to ensure compliance with evolving regulations and best practices. Changes will be published on our website. 12. Contact For AML/KYC-related inquiries, contact our Compliance team at contact@pulsar.ink . Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## RISK Risk Disclosure — PULSAR.INK ← Back to Home Risk Disclosure Effective Date: 11 June 2025 1. General Warning Trading cryptocurrencies involves significant risk and may result in the loss of your entire investment. You should not invest funds you cannot afford to lose. This Risk Disclosure statement is provided by XS Trades Ltd. ("Company") to inform users of the PULSAR.INK platform (the "Platform") about the risks associated with cryptocurrency trading. 2. Market Volatility Cryptocurrency markets are highly volatile. Prices can fluctuate dramatically in very short periods due to: Market supply and demand dynamics Regulatory announcements or actions Technological developments or vulnerabilities Macroeconomic events Market manipulation and speculative activity Social media influence and market sentiment 3. No Guarantee of Profit The Platform uses AI-powered trading algorithms, but: Past performance is not indicative of future results. No trading algorithm can guarantee profits or prevent losses. Displayed statistics, projections, and simulations are for informational purposes only and do not constitute guarantees. Both Classic and Aggressive trading modes carry risk of loss. 4. Technical Risks Cryptocurrency operations involve technical risks, including: 4.1 Blockchain Risks Network congestion may delay transaction processing Blockchain forks may affect asset values and availability Smart contract vulnerabilities may lead to loss of funds Irreversibility of blockchain transactions — sent funds cannot be recovered if sent to an incorrect address 4.2 Platform Risks System downtime or maintenance may prevent trading or withdrawals Software bugs or vulnerabilities, despite security audits Third-party service disruptions (exchanges, blockchain nodes) Cybersecurity threats including hacking attempts 5. Regulatory Risks The regulatory environment for cryptocurrencies is evolving and varies by jurisdiction. Risks include: Changes in laws or regulations may restrict or prohibit cryptocurrency trading Tax obligations may apply to your cryptocurrency gains Governments may impose restrictions on cryptocurrency exchanges and platforms Regulatory actions may affect the availability or value of specific cryptocurrencies 6. Liquidity Risks There is no guarantee that you will be able to withdraw or convert your cryptocurrency holdings at any time. Liquidity may be affected by market conditions, regulatory actions, or platform operations. 7. Not Investment Advice Nothing on the Platform constitutes investment, financial, legal, or tax advice. The information provided is for general informational purposes only. You should: Conduct your own research before making investment decisions Consult with qualified financial, legal, and tax advisors Only invest funds you can afford to lose entirely Understand the specific risks of each cryptocurrency 8. Possible Total Loss You acknowledge and accept that you may lose part or all of the funds deposited on the Platform. This may occur due to market movements, trading losses, technical failures, regulatory actions, or other events beyond our control. 9. Third-Party Risks The Platform interacts with third-party services (cryptocurrency exchanges, blockchain networks, payment processors). We are not responsible for the actions, failures, or security of these third parties. 10. Your Responsibility By using the Platform, you acknowledge that: You have read and understood this Risk Disclosure You accept all risks associated with cryptocurrency trading You are making your own investment decisions You will not hold the Company liable for trading losses 11. Contact If you have questions about the risks involved, contact us at contact@pulsar.ink before using the Platform. Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## COOKIES Cookie Policy — PULSAR.INK ← Back to Home Cookie Policy Effective Date: 11 June 2025 1. Introduction This Cookie Policy explains how XS Trades Ltd. ("Company", "we", "us", or "our") uses cookies and similar technologies on the PULSAR.INK platform (the "Platform"), including the website at pulsar.ink and the Telegram Mini App. 2. What Are Cookies? Cookies are small text files stored on your device by your web browser. Similar technologies include localStorage and sessionStorage, which allow websites and web applications to store data locally in your browser. 3. Technologies We Use 3.1 localStorage We use browser localStorage to store: Session data: Authentication tokens and session identifiers for maintaining your logged-in state User preferences: Language settings, trading mode preferences, and UI state Cached data: Temporary storage of trading data to improve performance and reduce API calls 3.2 sessionStorage We use sessionStorage for temporary data that is cleared when you close the browser tab: Temporary navigation state Form data during multi-step processes 3.3 Telegram WebApp Data When accessed through the Telegram Mini App, the Platform receives data from Telegram's WebApp API, including: Telegram user ID and authentication hash Theme and color scheme preferences set in Telegram Platform and device information This data is used solely for authentication and providing a consistent user experience within Telegram. 4. Categories of Data Storage 4.1 Strictly Necessary These are essential for the Platform to function and cannot be disabled: Authentication tokens Session management data Security-related data (CSRF protection) 4.2 Functional These enhance your experience but are not strictly required: Language and display preferences Recently viewed data and UI state 4.3 Analytics (if applicable) We may use analytics tools to understand how users interact with the Platform. If implemented, analytics data is anonymized and used solely for improving the service. We will update this policy to reflect any analytics tools introduced. 5. Third-Party Technologies The Platform may load resources from third parties: Telegram: Widget scripts for the Telegram Login Widget on the landing page These third parties may use their own cookies and tracking technologies subject to their own privacy policies. 6. Managing Your Preferences You can manage stored data through your browser settings: Clear localStorage and sessionStorage via browser developer tools or settings Block or restrict storage through browser privacy settings Note that clearing essential data may log you out and require re-authentication. 7. Changes to This Policy We may update this Cookie Policy to reflect changes in technology or legal requirements. The "Effective Date" above indicates the latest revision. 8. Contact For questions about this Cookie Policy, contact us at contact@pulsar.ink . Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## REFUND Refund Policy — PULSAR.INK ← Back to Home Refund Policy Effective Date: 11 June 2025 1. Overview This Refund Policy explains the conditions under which XS Trades Ltd. ("Company", "we", "us", or "our") may process refunds for transactions on the PULSAR.INK platform (the "Platform"). Due to the nature of blockchain transactions, refund possibilities are limited. Please read this policy carefully before making any deposits. 2. Blockchain Transaction Finality Cryptocurrency transactions on the blockchain are irreversible. Once a transaction has been confirmed on the blockchain network, it cannot be reversed, cancelled, or modified by any party, including the Company. This means: Deposits sent to your Platform wallet address and confirmed on-chain cannot be "un-sent" Withdrawals that have been broadcast and confirmed on the blockchain are final Funds sent to incorrect addresses cannot be recovered 3. Situations Where Refunds May Apply 3.1 Rejected Withdrawals If a withdrawal request is rejected during our review process (e.g., due to compliance checks), the funds will be returned to your Platform balance. This is not a blockchain refund — the funds never left the Platform. 3.2 Failed Transactions If a deposit is received but fails to be credited due to a Platform error (not a blockchain issue), we will investigate and credit the correct amount to your account. 3.3 Duplicate Deposits If a duplicate deposit occurs due to a Platform error, we will credit the excess amount back or process a return upon verification. 4. Situations Where Refunds Do Not Apply Refunds are not available for: Completed on-chain transactions: Deposits or withdrawals that have been confirmed on the blockchain Trading losses: Losses incurred from automated or manual trading activity Market fluctuations: Changes in cryptocurrency value after deposit or during processing User error: Funds sent to incorrect addresses, wrong networks, or unsupported tokens Platform fees: Fees that have been correctly applied and disclosed at the time of transaction Frozen accounts: Funds in accounts frozen due to AML/KYC violations or suspected fraud (subject to investigation outcome) 5. Refund Process To request a refund where applicable: Contact us at contact@pulsar.ink with your Telegram username, transaction details, and reason for the refund request Our team will review the request and may ask for additional information If approved, the refund will be credited to your Platform balance or processed as a withdrawal, depending on the circumstances 6. Dispute Resolution If you disagree with a refund decision: Contact our support team at contact@pulsar.ink with a detailed explanation We will conduct a thorough review and respond within a reasonable timeframe If the dispute cannot be resolved through our internal process, it may be escalated in accordance with the dispute resolution provisions in our Terms of Service 7. Platform Fee Refunds Platform fees are non-refundable once the associated transaction has been processed. Fee amounts are clearly disclosed before you confirm any transaction. 8. Exchange Rate Differences Due to cryptocurrency price volatility, the value of your deposit or withdrawal at the time of processing may differ from the value at the time of the request. We are not responsible for exchange rate fluctuations and no refunds will be issued for value differences. 9. Changes to This Policy We may update this Refund Policy at any time. Changes will be posted on this page with an updated "Effective Date". 10. Contact For refund requests or questions, contact us at contact@pulsar.ink . Terms of Service Privacy Policy AML/KYC Policy Risk Disclosure Cookie Policy Refund Policy © 2025 XS Trades Ltd. All rights reserved. ## Knowledge Base Articles ## Knowledge Base — Arbitrage Bots --- title: "Arbitrage bots" slug: arbitrage-bots canonical: https://pulsar.ink/kb/arbitrage-bots.html summary: Arbitrage bots exploit the same asset trading at different prices across venues or pairs. This page covers spatial, triangular, funding-rate, and statistical arbitrage — with realistic latency budgets and the reason why retail arbitrage is a much harder game than it looks. reading_time_minutes: 8 audience: operators considering low-directional, infrastructure-heavy strategies last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - risk-management-automated-trading - exchange-api-key-security - backtesting-explained --- # Arbitrage bots **Arbitrage** is the simultaneous purchase and sale of the same underlying asset to capture a price differential. An **arbitrage bot** automates the detection and the two-leg execution. Unlike directional strategies, arbitrage is supposed to be market-neutral: whether BTC goes up or down does not change the trade's edge, only the execution cost. In practice, retail crypto arbitrage is dominated by two realities: 1. The profitable spreads are seen first by faster bots with colocation and exchange-side market-maker agreements. 2. The spreads that retail sees are usually either too small to cover fees after fills, or are there because withdraw/transfer latency makes them un-arbitrageable. The rest of this page explains the four common flavours and where retail can still win. ## 1. Spatial arbitrage (cross-exchange) Simplest form. Same asset, different venue. - Detect: BTC/USDT bid on Exchange A is higher than BTC/USDT ask on Exchange B. - Execute: Buy on B at the ask, sell on A at the bid. - Settle: You are flat on BTC exposure but need to rebalance inventory between venues. The hidden leg is **inventory rebalancing**. To buy on B you need USDT on B; to sell on A you need BTC on A. The profitable round-trip depends not just on the spread, but on whether the inventory to repeat the trade is where it needs to be. Two models exist: - **Pre-funded both sides.** The operator keeps balanced inventory on both exchanges, never moving funds mid-trade. Fast, but capital is doubled (half on each venue). - **On-demand transfer.** The operator transfers the bought asset from B to A to restore inventory. Slow (minutes to hours for crypto transfers) and price-sensitive during the transfer window. Most profitable spatial arb setups use pre-funded both sides with small, frequent rebalances when one side depletes. Withdrawal limits and transfer fees become first-class concerns. ## 2. Triangular arbitrage (intra-exchange) Three pairs, one venue. Example on an exchange that lists BTC/USDT, ETH/USDT, ETH/BTC: - Start with 1000 USDT. - Leg 1: Buy BTC with USDT at current BTC/USDT price. - Leg 2: Buy ETH with BTC at current ETH/BTC price. - Leg 3: Sell ETH for USDT at current ETH/USDT price. - End: More than 1000 USDT if the three prices are inconsistent. This removes cross-exchange transfer risk entirely — everything happens inside one account — but the spreads are tighter because the exchange's own market makers are constantly closing them. Triangular arbitrage is mostly a discipline in latency and fee structure: maker-fee venues let you post legs as limit orders and earn the rebate, turning a near-zero spread into a positive trade. ## 3. Funding-rate arbitrage (perpetuals) Crypto perpetual futures have a **funding rate** that periodically transfers value between long and short positions to keep the perp pegged to spot. When funding is positive, longs pay shorts; when negative, shorts pay longs. The trade: - Buy spot BTC on Exchange A. - Short BTC perp on Exchange A (or B) in the same size. - Collect funding payments when the market pays shorts more than longs, or vice versa. You are market-neutral on BTC price and harvest funding. This works until: - Funding flips sign and eats the carry. - The spot side costs money to custody on-exchange (insurance fund contributions, lending rates). - The perp margin is liquidated in a flash move on one side even though the spot position offsets the loss — liquidation mechanics do not know about your hedge on another venue. Cross-exchange funding arb (spot on one venue, perp on another) adds a transfer-risk layer; single-venue funding arb removes that layer at the cost of inventory concentration. ## 4. Statistical arbitrage (pairs, baskets) Two or more assets that historically co-move. When the spread between them widens beyond historical norms, short the rich leg and long the cheap leg. Close when the spread reverts. Not arbitrage in the strict sense (the trade can be wrong), but is called arbitrage in the industry because the thesis is "statistical mean reversion" rather than "directional view." This requires more research infrastructure than the other three — cointegration tests, rolling windows, regime filters — and is usually a quant-shop game rather than a retail game. ## Realistic latency budgets A profitable arbitrage trade typically has a window of milliseconds to low seconds before it is closed by someone else. The retail latency chain: | Hop | Typical latency | |----------------------------------|--------------------------| | Market data: exchange → VPS | 20–150 ms (REST), 5–30 ms (WS) | | Bot detection + decision | 1–20 ms | | Order submission: VPS → exchange | 20–150 ms | | Exchange order-book update | 5–50 ms | A retail round-trip is therefore 50–400 ms best case. Any spread that lasted that long was already thin. Professional arbitrage desks cut this to 1–5 ms via colocation and direct market-maker connections — and they are the ones taking the thick spreads first. Retail-addressable niches tend to be: - **Second-tier exchanges** where pro desks have weaker presence. - **Long-duration spreads** driven by deposit/withdrawal gates (e.g. during exchange maintenance). - **Funding-rate arb** on perps, which is about carry over days, not milliseconds. - **Exotic pairs** and listed tokens where liquidity is thin but so is the competition. ## Risk corner Arbitrage is advertised as "risk-free," which is false under every definition of risk: - **Execution risk.** One leg fills, the other does not. You are now directional when you did not intend to be. - **Transfer risk.** Cross-exchange transfers can stall. Spreads change during the stall; inventory ends up at the wrong venue. - **Counterparty risk.** An exchange goes down, gates withdrawals, freezes the account. All of your arb capital at that venue is locked. This is the single biggest loss source in 2022-2023 retail arb history. - **Liquidation asymmetry.** Perp leg liquidates on a flash move even though the spot hedge is unchanged; the perp loss is realised, the spot gain is not. - **API risk.** API key is stolen; funds in the exchange account are taken via the trade permissions (no withdraw needed — the attacker can cross-trade you out). See [[exchange-api-key-security]]. These risks live in the background whether you backtest or not; [[backtesting-explained]] does not catch any of them. Position caps in [[risk-management-automated-trading]] are how you bound them. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — arbitrage's place in the taxonomy. - [[exchange-api-key-security]] — the trade-without-withdraw attack surface that matters most here. - [[risk-management-automated-trading]] — capital allocation caps. - [[backtesting-explained]] — why arbitrage backtests hide the counterparty-risk scenarios that produce the largest real losses. ## Knowledge Base — Backtesting Explained --- title: "Backtesting explained" slug: backtesting-explained canonical: https://pulsar.ink/kb/backtesting-explained.html summary: Backtesting runs a strategy against historical data to estimate how it would have performed. This page covers walk-forward validation, look-ahead bias, survivorship bias, realistic slippage, and the specific reasons backtests of crypto strategies routinely overstate results. reading_time_minutes: 7 audience: operators deciding whether to deploy a strategy live last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - grid-trading-strategy - dca-bot-strategy - arbitrage-bots - signal-trading-bots - risk-management-automated-trading --- # Backtesting explained **Backtesting** is the simulation of a strategy over historical data. The goal is to decide whether the strategy has enough edge to be worth running live. The backtest output is a PnL curve, a drawdown profile, and trade statistics — from which the operator chooses to deploy, re-tune, or discard. The problem with backtests is not that they lie. It is that they tell a very specific kind of truth — "how the strategy would have performed on **this** history with **these** assumptions" — and operators consistently misread that truth as a forecast. ## What an honest backtest reports | Metric | What it tells you | What it does not tell you | |-------------------------------|------------------------------------------------------|------------------------------------------------| | Total return | Cumulative PnL over the sample | How noisy the path was | | Sharpe ratio | Return per unit of volatility | Tail risk; downside vs upside volatility | | Max drawdown | Worst peak-to-trough in the sample | Drawdown possible outside the sample | | Win rate | Percent of trades profitable | Distribution of win and loss sizes | | Profit factor | Sum(wins) / Sum(losses) | How stable this ratio is over time | | Exposure time | Percent of time capital was at work | Opportunity cost of idle capital | | Trade count | Sample size of results | Whether all fills were realistic | | Slippage + fee accounting | Post-cost profitability | Real-book depth at order size | If a backtest does not report all of these, it is an advertisement, not a backtest. ## The four biases that kill retail backtests ### 1. Look-ahead bias The strategy uses data that was not available at the time of the decision. The classic case is computing an indicator on the current bar's close and then trading inside that same bar. Also common: rebalancing against a universe chosen with knowledge of which tokens survived to today (hence "survivorship bias"). Fix: decisions made at time `t` must only use data available at `t`. Enforce by shifting all signals by at least one bar and by trading on the **next** bar's open, not the current bar's close. ### 2. Survivorship bias The universe you are testing against is the universe that exists **today**. Every delisted token, every dead exchange, every failed protocol is missing. A mean-reversion strategy that "works" on today's universe would have been decimated by the universe that existed five years ago, because the losers are gone. Fix: test against a **point-in-time universe** — the set of assets that were tradable on each date — which is expensive to assemble for crypto and nearly impossible for long-tail tokens. The next best fix is to limit backtest scope to top-N assets by liquidity, acknowledge the bias, and size accordingly. ### 3. Sample-period bias The backtest window is a single slice of market history, and the slice you pick drives the result more than the strategy does. A grid on BTC/USDT from 2023-01 to 2024-01 looks perfect (range-bound). The same grid from 2024-02 to 2025-04 looks terrible (trending). Neither window is wrong; both are incomplete. Fix: report results across multiple **out-of-sample windows**, including a full bull-bear-bull cycle. Report the distribution, not the single number. ### 4. Slippage under-modelling The backtest fills at the historical mid price. Live markets fill you against the spread, and sometimes outside it when the book is thin or the move is fast. For grid bots running hundreds of trades per day, a 5-bps slippage error compounds to a very different end equity. Fix: model **realistic fills**: - Taker orders at the worst visible price of the requested size at that timestamp. - Maker orders fill only if price trades **through** the posted level, not just touches it. - During high-volatility bars, widen the spread model; during low- liquidity hours, cap order size to a realistic fraction of the bar volume. No public backtest engine nails all of these. The pragmatic approach is to run the backtest, then discount the result — 20–40% lower expected return, 30–50% higher drawdown — to get something closer to what the live strategy will actually do. ## Walk-forward validation The honest replacement for "train on all history, claim it works" is **walk-forward validation**: 1. Pick an in-sample window (e.g. 2021-01 to 2022-01) and tune the strategy on it. 2. Pick an out-of-sample window (2022-01 to 2022-04) and run the tuned strategy against it **without further tuning**. 3. Slide the window forward (2021-04 to 2022-04 in-sample, 2022-04 to 2022-07 out-of-sample) and repeat. 4. Concatenate all the out-of-sample PnLs. That concatenation is what the strategy can actually be expected to produce. Walk-forward routinely reduces reported returns by 30–60% vs a single-window fit. Operators who do not run walk-forward are getting an over-fitted number. ## Crypto-specific pitfalls - **Exchange migration.** A backtest of BTC/USDT on Exchange A from 2019 may stitch together data from an exchange that no longer exists. Liquidity and spreads are not transferable. - **Stablecoin depeg.** A strategy that uses USDT as the quote currency is assuming USDT = $1 at every bar. This has been wrong for extended windows (May 2022, March 2023) and the backtest usually does not correct for it. - **Token dilution / airdrop.** Perpetual token supply changes silently change the "price" over long windows. - **Fee-schedule changes.** Exchanges change maker/taker fees quarterly. A 2020 backtest using 2026 fees is optimistic. - **Futures funding baselines.** Funding rates have trended down since 2021 as liquidity matured; a 2018 funding-arb backtest is not a 2026 forecast. ## Specific notes per strategy - [[grid-trading-strategy]] — grid backtests over a single range always look perfect. Re-backtest the same grid over the 2022 bear and the 2024 Q1 breakout; the numbers are very different. - [[dca-bot-strategy]] — DCA backtests are the most honest but are path-dependent on the start date. Multi-start backtest is the fix. - [[arbitrage-bots]] — backtests ignore counterparty risk and transfer latency, which are the two largest live loss sources. - [[signal-trading-bots]] — the signal provider's backtest almost always suffers from survivorship bias; re-run against the operator's own execution policy. The broader discipline is covered in [[risk-management-automated-trading]]: no amount of backtest accuracy removes the need for live-account caps, because the one variable the backtest cannot simulate is the operator. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — the broader category. - [[risk-management-automated-trading]] — the caps that bound any strategy's downside regardless of what the backtest said. ## Knowledge Base — Copy Trading Explained --- title: "Copy trading explained" slug: copy-trading-explained canonical: https://pulsar.ink/kb/copy-trading-explained.html summary: Copy trading is the delegation of entry and exit decisions to a human or algorithmic leader whose trades are mirrored on the follower account through an API. This page explains the mirroring mechanics, slippage, sizing models, tax surface, and the real failure modes. reading_time_minutes: 7 audience: retail crypto traders considering delegating decisions last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - signal-trading-bots - risk-management-automated-trading - exchange-api-key-security - backtesting-explained --- # Copy trading explained **Copy trading** is a form of automated trading (see [[what-is-automated-crypto-trading]]) where the follower's bot does not make trading decisions itself. Instead, it **mirrors** the trades of a chosen leader — a human trader, a quant fund, or another bot — on the follower's own exchange account, in near real time, through an API. The follower owns the funds and the API key; the leader owns the decisions. The platform is the pipe between them. ## The mirroring loop 1. The leader submits an order on their own exchange account. 2. The platform detects the fill (via exchange API polling or a websocket feed). 3. The platform normalises the fill into a follower-sized order according to the follower's declared sizing model. 4. The platform submits the follower order against the follower's API key. 5. The platform reconciles — did the follower fill fully, partially, or not at all? — and records the deviation for the follower's PnL log. Every step introduces a small amount of **slippage**: the follower does not get the exact same price the leader got. How much slippage is acceptable is one of the two main follower-side parameters (the other being sizing, below). ## Sizing models A leader with a $1 million account may buy 10 BTC in one trade. If a follower with a $5,000 account naïvely mirrors that, the follower either cannot afford the trade or burns their account on one position. Three sizing models are in common use: ### 1. Proportional (notional) Follower trades `leader_trade_value × (follower_equity / leader_equity)`. Simple, intuitive, survives account-size gaps well. Weakness: when the leader's account is much larger than the follower's, the proportional position may round down to a tradable minimum and be silently skipped. ### 2. Fixed-notional Follower always trades a fixed dollar value (e.g. $100 per mirrored trade). Simple, but loses the leader's conviction signal — the leader's "big bet" and "small bet" both become the same size on the follower side. ### 3. Risk-parity Follower scales position by the leader's declared stop distance and the follower's max risk per trade. Matches professional desk practice, hardest to configure correctly, usually requires the leader to publish a stop-loss alongside every entry. Pulsar.INK supports all three. The choice is the follower's and should be recorded in the operator's [[risk-management-automated-trading]] policy. ## What copy trading shares with signal trading, and what it doesn't Copy trading is the closest sibling to signal-following (see [[signal-trading-bots]]). The difference is the trust level: | Aspect | Copy trading | Signal trading | |------------------------------|-------------------------------------------|---------------------------------------------------| | Who emits the trade? | A specific leader, by identity | A signal source (indicator, channel, algorithm) | | Latency-sensitive? | Yes — must mirror quickly | Yes, but dependent on signal type | | Exit visibility | Same as entry — when the leader exits | Signal may not emit an explicit exit | | Survivorship-bias risk | High (dead leaders are invisible) | High (dead signals are invisible) | | Can you audit reasoning? | Only as much as the leader discloses | Depends — rule-based signals are fully auditable | Copy trading's main trap is **survivorship bias**: the leaderboard on any platform shows the survivors. Leaders who blew up are gone from the list. This is the same mechanism that makes [[backtesting-explained]] results look rosier than live results — and it is the reason a follower's onboarding due diligence needs to go beyond "top of the leaderboard last week." ## Slippage budget If the leader fills at $50,000 and the follower fills at $50,030, that is 6 basis points (0.06%) of slippage. A good mirroring pipeline holds average slippage under 10 bps for liquid pairs; it degrades on thin pairs, news-driven moves, and high-frequency strategies that the leader runs faster than the mirror can follow. A follower whose expected edge per trade is smaller than the pipeline's slippage budget is guaranteed to lose money by arithmetic, no matter how good the leader is. That is why copy trading works better for lower-frequency, conviction-based leaders than for HFT-style leaders. ## Tax surface Copy trading does not remove the tax obligation of the individual trades. Each mirrored fill on the follower's exchange is a tax event in most jurisdictions, exactly as if the follower had entered and exited themselves. The platform is not the tax counterparty; the exchange is. A follower running a high-frequency leader may rack up thousands of tax events a year and should budget for bookkeeping software accordingly. ## Failure modes to watch - **Leader account compromise.** If the leader's account is compromised, malicious trades are mirrored before anyone notices. The follower's only defence is a cap on per-trade size and a total daily drawdown limit — see [[risk-management-automated-trading]]. - **API-key over-permissioning.** Copy trading does not need withdraw permission on the follower key; see [[exchange-api-key-security]] for the full scope list. - **Market-condition shift.** A leader who was profitable in a trending market may be consistently wrong in a ranging market. The copy relationship should be time-boxed or performance-gated; it is not a set-and-forget arrangement. - **Platform outage during the leader's exit.** If the mirror pipeline is down while the leader closes a winner, the follower keeps the position open. Pulsar.INK's failover behaviour is to flatten open copy positions if the mirror loop misses heartbeats for longer than a configurable threshold. This is safer than leaving a "stuck" position open but is a non-trivial follower-side decision. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — the broader category this strategy belongs to. - [[signal-trading-bots]] — the closest non-copy sibling. - [[risk-management-automated-trading]] — the caps that bound the leader's blast radius. - [[exchange-api-key-security]] — why withdraw permission stays off on follower keys. - [[backtesting-explained]] — why the leaderboard is not a backtest. ## Knowledge Base — Dca Bot Strategy --- title: "DCA bot strategy" slug: dca-bot-strategy canonical: https://pulsar.ink/kb/dca-bot-strategy.html summary: Dollar-cost averaging (DCA) bots buy fixed amounts on a fixed schedule, and optionally scale in when price drops. This page covers classic vs conditional DCA, the exit problem, and why DCA is a discipline, not a strategy. reading_time_minutes: 6 audience: long-horizon crypto holders wanting mechanical accumulation last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - grid-trading-strategy - risk-management-automated-trading - backtesting-explained --- # DCA bot strategy **Dollar-cost averaging (DCA)** is the practice of buying a fixed dollar amount of an asset on a fixed schedule — say, $100 of BTC every Monday — regardless of current price. A **DCA bot** does this automatically on a user-configured cadence and can optionally scale in harder when price drops below recent trailing averages. DCA belongs to the same family as other automated strategies (see [[what-is-automated-crypto-trading]]) but is the simplest to reason about: the only decision that survives is "am I still bullish on this asset over my accumulation horizon?" ## Classic DCA Parameters: - **Asset**: e.g. BTC - **Cadence**: e.g. weekly, on Monday 12:00 UTC - **Dollar amount per buy**: e.g. $100 - **Horizon**: e.g. 24 months The bot fires `cadence × horizon` buys, one per period. No exit logic. The output is a position with a cost basis equal to the arithmetic mean of the period closing prices. Two properties of classic DCA are worth absorbing: 1. **It always underperforms a perfect top-buy or a perfect bottom-buy** — by construction, because DCA averages. It is the "average case" strategy. 2. **It always outperforms a worst-case top-buy** and usually outperforms panic-selling, because DCA removes the decision-point latency where emotion intrudes. In plain terms: you are trading off upside in exchange for survival. ## Conditional DCA (value-averaging / martingale-lite) Pure time-based DCA is a discipline. Conditional DCA adds a price trigger and becomes closer to a strategy: - **Base buy every period** (classic DCA) - **Extra buy when price is X% below recent average** - **Skip buy when price is Y% above recent average** This tilts accumulation toward lows and away from highs, at the cost of introducing parameters to tune (X, Y, "recent average" window). At the extreme, it becomes a martingale — doubling down on each drop — which has famous failure modes when the drop is structural rather than transient. Pulsar.INK's DCA bot supports both variants; the operator chooses whether to layer conditions on top of the base schedule. ## The exit problem DCA is strong at accumulation and silent about exit. This is a feature, not a bug: the strategy's thesis is "I believe this asset will be worth more at my horizon than at my cost basis." When the operator reaches the horizon, they decide the exit — DCA does not decide it for them. Three exit approaches are in practice use: | Approach | When to use | Downside | |-------------------|----------------------------------------------|-------------------------------------------| | Hold / self-custody| Long horizon, no need for fiat | Tail risk on exchange or self-custody | | Reverse-DCA out | When the operator wants mechanical exit too | Caps upside on the way out | | Profit-trigger | Exit all when position is X% above cost basis | One threshold rarely fits the whole cycle | The honest framing: if the operator has no exit rule, DCA has built an increasingly valuable position with no declared success condition. That is a psychology problem, not a bot problem. ## DCA vs grid: which in a ranging market? DCA and [[grid-trading-strategy]] look similar at a glance — both fire scheduled buys and both work best without strong trends — but the underlying bets differ: | Question | DCA | Grid | |--------------------------------------|--------------------------------|-------------------------------| | What am I betting on? | Long-horizon appreciation | Near-term oscillation | | Do I sell inside the period? | No (unless conditional exit) | Yes, at every level | | What happens if price crashes? | I buy more at lower prices | Grid breaks, bag sits below | | What happens if price moons? | I hold appreciating position | Grid sells out, no more entry| | Complexity to tune | Minimal | Moderate to high | In a ranging market, DCA slowly accumulates a base position, grid harvests oscillation profit on top. They can be complementary rather than competing. ## Backtests and DCA A DCA backtest is the most honest backtest you can run — there are so few parameters that overfitting is nearly impossible — but it is still misleading in one specific way: it is path-dependent on the sample window. A DCA of BTC starting 2020-01-01 looks great through 2021-11. The same DCA starting 2021-11-01 looks terrible through 2022-11. See [[backtesting-explained]] for the general trap; for DCA specifically, the mitigation is to backtest multiple start dates across a full cycle and report the distribution, not the single "from here to now" number. ## Risk notes DCA does not make a bad asset good. If the asset's thesis fails — the token gets delisted, the protocol gets exploited, the project team disappears — DCA has bought the whole way down. The [[risk-management-automated-trading]] cap for DCA is usually a **total notional cap** per asset rather than per-trade, because per-trade is already small by construction. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — where DCA fits in the broader taxonomy. - [[grid-trading-strategy]] — the oscillation-harvesting cousin. - [[risk-management-automated-trading]] — the one cap that matters for DCA. - [[backtesting-explained]] — the path-dependence pitfall. ## Knowledge Base — Exchange Api Key Security --- title: "Exchange API-key security" slug: exchange-api-key-security canonical: https://pulsar.ink/kb/exchange-api-key-security.html summary: The API key is the credential a trading platform uses to execute trades on the operator's exchange account. This page covers the mandatory permission scope, IP allowlists, rotation cadence, and the withdraw-permission rule that separates survival from loss. reading_time_minutes: 6 audience: every operator connecting a platform to an exchange last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - risk-management-automated-trading - telegram-native-trading-ux - arbitrage-bots --- # Exchange API-key security An **API key** is a credential pair (key + secret) issued by an exchange that lets an external program act on the owner's exchange account. In the context of automated trading (see [[what-is-automated-crypto-trading]]), the platform holds the key and uses it to submit orders on the operator's behalf. The key is the single most abusable object in the whole stack. Funds never leave the exchange to enter the platform, but the key can still do real damage if it is mis-scoped. Getting the scope right is the non-negotiable first step of every exchange integration. ## The one rule **Withdraw permission MUST NOT be enabled on the API key.** This rule is absolute. Every major exchange splits permissions into at least three classes — Read, Trade, Withdraw — and the platform only needs Read and Trade. There is no legitimate reason for a trading bot to hold Withdraw; the platform does not need to move funds off the exchange to do its job. When Withdraw is off, the worst a compromised key can do is trade against the account (losing money to a pre-arranged market-maker counter-bot is the classic attack). That is real harm, but the account's principal is still on the exchange and recoverable via exchange support and rate-limit-triggered liquidation windows. When Withdraw is on, the attacker can empty the account in one transaction. The loss is irreversible. ## Minimum permission scope Exact names differ by exchange, but every platform should request only these classes: | Scope | Typical name across venues | Required? | |-------------------------|---------------------------------------------------|----------------------| | Read account balances | "Read Info" / "Account" / "Query" | Yes | | Read order history | "Read Orders" / "History" | Yes | | Place & cancel orders | "Trade" / "Spot Trading" / "Margin Trading" | Yes | | Withdraw funds | "Withdraw" / "Transfer" | **NO** | | Enable margin | "Margin" / "Futures" | Only if strategy needs it | | Enable futures | "Derivatives" / "Perpetual" | Only if strategy needs it | | Internal sub-transfer | "Universal Transfer" | **NO** (almost always)| The operator should check the scope boxes in the exchange UI against this list every time a key is created or rotated. ## IP allowlist Most major exchanges let the operator bind the API key to a **fixed IP allowlist**. An order submitted from an IP outside the allowlist is rejected. Pulsar.INK, like most platforms, publishes the egress IPs of the trading servers so operators can put exactly those IPs on the allowlist. If the operator's allowlist is `[]`, the key is usable from anywhere and the credential's effective security is half of what it should be. Trade-offs: - **Fixed allowlist + operator pastes the key.** Best security; platform must publish and maintain its egress IPs; operator re-pastes the key when the list changes. - **No allowlist.** Simple to set up; key-theft blast radius is the whole internet; absolutely avoid unless the exchange does not support allowlists. For arbitrage strategies that run across multiple venues, see [[arbitrage-bots]] — the cross-venue transfer flow is a place where operators are sometimes tempted to turn Withdraw on for "convenience." Do not. Use manual transfers or an internal sub-account if inter-venue rebalancing is needed. ## Rotation cadence API keys should be rotated on a cadence. The minimum reasonable cadence: - **Every 90 days** for keys on trading-only accounts. - **Immediately** if any of these events occur: - The operator suspects the key leaked. - The operator changed their Telegram account (see [[telegram-native-trading-ux]] for why this matters). - The platform discloses a security incident. - The exchange notifies of unusual activity. Rotation is a low-friction operation on Pulsar.INK: new key issued on the exchange, pasted into the Telegram interface, old key revoked on the exchange. The platform does not cache old keys. ## Secret handling on the platform side The operator's key and secret are encrypted at rest on the platform and used only by the specific order-submission service. They are never written to logs, never surfaced in UI messages after entry, and never emitted to third parties. From the operator's perspective, the protective controls are: 1. **Never copy the secret into any chat, ticket, or email** — including platform support. Support never asks for the secret. 2. **Never paste the secret into a form served over HTTP** (as opposed to HTTPS). The Telegram Mini App is HTTPS-only by design. 3. **Revoke the key** if it was ever copy-pasted into anything that is not the platform's key-entry screen. The cost of rotation is low; the cost of a leaked key is very high. ## What to do if a key is compromised Compromise is not just "I lost the key." It also covers: - A device that has the key on it was lost or stolen. - A password manager that has the key was accessed by someone else. - The key appears in any log, message, or file shared with another party. Steps: 1. **Revoke the key on the exchange** (fastest path — usually one click). 2. **Pause all strategies on Pulsar.INK** (kill switch in Telegram). 3. **Review open orders and positions** for entries the operator did not place. 4. **Contact exchange support** if there is evidence of unauthorised trades. 5. **Rotate any shared credentials** (Telegram password, device-level PINs) if the compromise pathway is not already known. 6. **Issue a new key** with a fresh IP allowlist; re-enable strategies only after verifying the previous compromise is contained. The [[risk-management-automated-trading]] framework applies here too: the per-account daily loss cap will usually fire well before an attacker has been able to cross-trade the account into oblivion. That cap is the backstop when every other control fails. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — the broader context. - [[telegram-native-trading-ux]] — the Telegram-side half of the security perimeter. - [[risk-management-automated-trading]] — loss caps that survive credential compromise. - [[arbitrage-bots]] — the strategy most likely to tempt operators into mis-scoping keys. ## Knowledge Base — Grid Trading Strategy --- title: "Grid trading strategy" slug: grid-trading-strategy canonical: https://pulsar.ink/kb/grid-trading-strategy.html summary: Grid trading places staggered buy and sell orders across a price range, capturing profit from oscillation rather than from a directional forecast. This page covers range theory, grid density, drawdown math, and when grids break. reading_time_minutes: 8 audience: operators considering a no-view, range-bound strategy last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - dca-bot-strategy - risk-management-automated-trading - backtesting-explained --- # Grid trading strategy **Grid trading** places a ladder of buy and sell orders at pre-calculated price levels across a range and profits from the market oscillating up and down between those levels. Unlike directional strategies, the grid does **not** require a view on where price is going — only on the range it will stay in. This makes grids the most popular "zero-view" automated strategy (see [[what-is-automated-crypto-trading]]) for ranging or choppy markets. ## The core mechanic Suppose BTC/USDT is trading at $50,000 and you expect it to oscillate between $45,000 and $55,000 for the next few weeks. You define: - **Range**: $45,000 to $55,000 - **Grid size**: 10 levels (step = $1,000) - **Order size per level**: 0.01 BTC The bot places: - Buy orders at $49,000, $48,000, $47,000, $46,000, $45,000 - Sell orders at $51,000, $52,000, $53,000, $54,000, $55,000 Each time price drops through a level, the corresponding buy fills — and the bot immediately places a new sell order one step above. Each time price rises through a level, the sell fills and a new buy goes in one step below. Every completed round-trip (buy at $49,000, sell at $50,000) is a locked-in profit of $1,000 × 0.01 = $10, minus fees. ## Range theory The grid's profitability comes entirely from volatility inside the declared range. Two parameters interact: | Parameter | Effect on profit per round-trip | Effect on number of round-trips | |------------------|---------------------------------------------------|-----------------------------------------------| | Wider range | Same (one-step profit unchanged) | Fewer fills during a typical oscillation | | Denser grid | Smaller profit per round-trip | More fills during a typical oscillation | | Higher volatility| Same | More fills in a given time window | The grid's edge is roughly: ``` expected_profit ≈ (levels_crossed_per_day) × (profit_per_level - fees) ``` so the operator is implicitly betting on a combination of (range holding) × (enough volatility inside the range) × (exchange fee being small relative to step size). ## Grid density trade-off Too sparse a grid and the bot idles through small moves. Too dense a grid and each round-trip's profit drops below the fee level and the strategy bleeds slowly. A common rule of thumb: step size should be at least **4× the one-way taker fee** to give a round-trip (two taker fills) a 2× fee cushion. For a 0.1% taker fee, that is a step of at least 0.4%. Below that, the grid is working for the exchange, not for the operator. ## The drawdown math nobody mentions on Twitter A grid looks beautiful **while price stays in the range**. When price exits the range, the grid is suddenly holding a lopsided position: - If price breaks below the lower bound, every buy order filled and no sell ever offset them. The bot is holding the maximum intended long position at the worst possible average price. - If price breaks above the upper bound, every sell filled (if the strategy shorts) or the strategy is fully out of the market (if it only longs). Either way it has stopped compounding. Maximum bag size at range break: ``` max_bag = order_size × number_of_buy_levels unrealised_loss_at_break = sum over filled buys of (fill_price - current_price) × order_size ``` A concrete example: range $45k–$55k, 10 buy levels of 0.01 BTC. Price crashes to $30k. The bot holds 0.05 BTC (bottom five levels all filled), bought at an average around $47k. Unrealised loss: roughly 0.05 × $17,000 = $850 on $2,350 of capital deployed, or 36% drawdown. A grid that was quietly earning $10 per round-trip has just given back 85 round-trips' worth of profit in one broken range. This is why grids are inseparable from [[risk-management-automated-trading]]: - **Stop-loss below the lower bound** — accept the grid failed and close out, rather than average down forever. - **Position cap** — total capital deployed by the grid is bounded, not a fixed fraction of equity; one grid's break should not take out the account. - **Range review cadence** — re-price the range weekly or on any regime-shift event, not "when it breaks." ## Grid types | Type | Description | Best for | |---------------|------------------------------------------------------------------|-------------------------------| | Arithmetic | Equal dollar spacing between levels | Stable, moderate-vol markets | | Geometric | Equal percentage spacing between levels | Higher-vol assets | | Infinity | No upper bound; keeps adding sell levels as price climbs | Strong uptrend speculators | | Reverse | Shorts instead of longs; profits from range in a bearish regime | Experienced operators only | | Dynamic | Range is recomputed from recent ATR or Bollinger bands | Adaptive to regime shifts | Pulsar.INK supports arithmetic, geometric, and dynamic grids. ## When grids break Three regimes kill grids in increasing order of severity: 1. **Low volatility / tight chop.** Fills are too infrequent; the opportunity cost of deployed capital exceeds grid returns. The operator's fix is to reduce grid size or redirect capital to [[dca-bot-strategy]] / other strategies. 2. **Trending market.** Price walks outside the range in one direction; the grid is one-sided and stops compounding. The operator's fix is early recognition (trend filter on top of the grid) and range redeclaration. 3. **Flash crash / news event.** Range break happens faster than the operator can respond, and the stop-loss (if there is one) fires at a much worse price than its declared level due to gap-through. The operator's mitigation is a hard position cap: even after gap-through, the absolute dollar loss is bounded by `order_size × buy_levels × (range_width + gap_slippage)`. Backtests (see [[backtesting-explained]]) routinely understate all three failure modes because they use idealised tick data, not the thin order books that exist during live crashes. A "100% profitable" backtest with no drawdown should be read as "this strategy has never been stressed," not "this strategy is safe." ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — where grids fit in the wider strategy taxonomy. - [[dca-bot-strategy]] — the accumulation-oriented cousin of grids. - [[risk-management-automated-trading]] — non-optional for grids. - [[backtesting-explained]] — why grid backtests are the most misleading. ## Knowledge Base — Risk Management Automated Trading --- title: "Risk management in automated trading" slug: risk-management-automated-trading canonical: https://pulsar.ink/kb/risk-management-automated-trading.html summary: Risk management is the layer that decides how much of the account any one strategy can lose before it is stopped. This page covers position sizing, max-drawdown caps, per-strategy blast radius, kill switches, and the non-negotiable human review loop. reading_time_minutes: 7 audience: operators running two or more live strategies simultaneously last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - grid-trading-strategy - dca-bot-strategy - arbitrage-bots - signal-trading-bots - backtesting-explained - exchange-api-key-security --- # Risk management in automated trading A strategy describes **what** the bot will do. Risk management describes **how much** of the account the bot is allowed to harm before it is stopped. In manual trading the two are often collapsed into a single judgement. In automated trading they must be separated, because the bot does not pause to reconsider. This page is deliberately boring. The content is not clever; it is the set of caps that separate operators who survive from operators who don't. ## The three layers Think of risk management as three independent layers, each of which should trigger on its own without requiring the others: 1. **Per-trade cap.** The maximum loss on any single trade is bounded by a pre-placed stop-loss or position size. A single catastrophic trade cannot exceed this. 2. **Per-strategy cap.** The maximum cumulative loss of any one strategy over a rolling window (day / week / month) is bounded. When hit, the strategy is paused for human review. 3. **Account cap.** The maximum cumulative loss across **all** strategies is bounded. When hit, every strategy on the account is paused. Each cap has its own alert threshold (e.g. at 80% of cap) so the operator gets a warning before the cap fires, not after. ## Position sizing Three sizing rules are in practice use. Pick one per strategy and write it down. ### 1. Fixed fractional (simplest) ``` position_size_notional = account_equity × risk_fraction ``` With `risk_fraction` usually 1–2% for a conviction trade, 0.25–0.5% for a signal trade from a third-party source. This ignores volatility and stop distance, which is a weakness, but it is the rule that survives operator error the longest. ### 2. Risk-parity (volatility-adjusted) ``` position_size_notional = (account_equity × risk_per_trade) / (stop_distance_percent) ``` The position size is inversely proportional to the stop distance, so a tight-stop trade is larger and a wide-stop trade is smaller. This equalises dollar risk across setups but requires the operator to place honest, informed stops. ### 3. Kelly-fraction (advanced, easy to misuse) ``` kelly_fraction = win_rate - (1 - win_rate) / payoff_ratio position_size_notional = account_equity × (kelly_fraction × kelly_scale) ``` With `kelly_scale` usually 0.25–0.5 ("fractional Kelly") because full Kelly is only optimal if your estimates of win rate and payoff are exactly right, and they never are. Most retail operators should not use this rule because estimating `win_rate` and `payoff_ratio` from a short live history produces terrible numbers. ## Max-drawdown caps The single most important risk-management parameter is the **max-drawdown cap** per strategy and per account. A 20% drawdown requires a 25% recovery; a 50% drawdown requires a 100% recovery; a 90% drawdown requires a 900% recovery. Compounding is symmetric in percent but asymmetric in dollars. Conservative retail settings: | Cap | Per-strategy | Per-account | |-----------------|--------------|-------------| | Daily loss | 3% | 2% | | Weekly loss | 7% | 5% | | Monthly loss | 15% | 10% | When hit, the strategy (or account) is paused until the operator reviews and explicitly re-enables. The pause is non-negotiable; it is the thing that prevents one bad week from becoming one bad year. ## Kill switches Every strategy should have at least two independent kill switches: 1. **Strategy-local.** The bot itself has drawdown logic that stops the strategy when the cap fires. Requires the bot to be alive and reading market data. 2. **Platform-level.** An external watcher (Pulsar.INK's platform) can pause a strategy regardless of what the strategy thinks. Used for exchange outages, account-level drawdown caps, and API-key revocation. Relying on only the strategy-local kill switch is how operators lose big during infrastructure outages — the bot is hung, nothing stops it because nothing is running. ## Per-strategy blast radius When multiple strategies share one account, the blast radius of one strategy becomes a systemic risk for the others. The simplest blast-radius limiter is **capital allocation**: declare in advance the maximum notional one strategy can hold at any time, and deny any order that would breach it. Allocation example for a $10,000 account: - 40% DCA bot on BTC and ETH ($4,000) - 25% Grid bot on BTC/USDT ($2,500) - 20% Signal bot on alt majors ($2,000) - 15% Reserve (never deployed) ($1,500) The reserve is non-negotiable. It is the buffer for margin calls, for an opportunistic re-entry after a drawdown-cap pause, and for the cost of the mistake that is in the strategy you have not discovered yet. ## Integration with strategy nodes Each strategy family in this knowledge base has its own specific risk profile: - [[grid-trading-strategy]] — the dominant risk is range-break; cap is a hard stop below the range, not a soft drawdown cap. - [[dca-bot-strategy]] — the dominant risk is accumulating a dead asset; cap is a total notional cap per asset, not per trade. - [[arbitrage-bots]] — the dominant risk is counterparty / transfer; cap is a per-venue capital cap plus a daily-withdrawal test. - [[signal-trading-bots]] — the dominant risk is bad signals; cap is both a per-trade risk cap and a rolling-PnL cap on the signal source. - [[copy-trading-explained]] — the dominant risk is leader behaviour change; cap is a rolling-PnL review and a time-boxed review cadence. Every strategy runs under its own cap set, plus the account-level cap that applies to all of them. ## Human review loop Risk management is not only parameters. It is also the review cadence: - **Daily:** quick glance at each strategy's PnL and the PnL / cap ratio. Anything over 80% of cap gets attention. - **Weekly:** review closed trades and fills. Are they what the strategy intended? Unexpected behaviour is a louder signal than unexpected loss. - **Monthly:** re-validate the strategy's thesis. Is the market regime still one this strategy was designed for? If not, pause. - **Quarterly:** rebalance allocation across strategies; retire the ones that underperformed their thesis for two consecutive quarters. This loop is what turns automated trading from "a bet" into "an operation." ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — the broader context. - [[backtesting-explained]] — why no backtest captures the full risk landscape. - [[exchange-api-key-security]] — the credential-level risk that sits under all of these and is not priced in anywhere else. ## Knowledge Base — Signal Trading Bots --- title: "Signal trading bots" slug: signal-trading-bots canonical: https://pulsar.ink/kb/signal-trading-bots.html summary: Signal trading bots execute trades based on signals from an external source — technical indicators, Telegram channels, TradingView webhooks, or in-house models. This page explains the signal taxonomy, execution policies, and the survivorship-bias trap. reading_time_minutes: 6 audience: operators who want to delegate entry/exit to a signal provider last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - copy-trading-explained - risk-management-automated-trading - backtesting-explained --- # Signal trading bots A **signal trading bot** receives a signal from an external source and acts on it by submitting an order against the operator's exchange account. The operator chooses the signal source; the bot is the disciplined executor that does not second-guess the signal. This is the closest sibling to copy trading (see [[copy-trading-explained]]) but the signal source is usually a rule set, a feed, or a webhook rather than another trader's live account. ## Signal taxonomy | Signal type | Example | Auditable? | Typical cadence | |-------------------------|---------------------------------------------------|------------|------------------| | Technical indicator | RSI crossing 30, MACD histogram flip | Yes | Seconds to hours | | Price-action rule | Close above 20-day high (Donchian breakout) | Yes | Daily | | TradingView webhook | Any custom script emitting alerts over HTTPS | Sometimes | Variable | | Telegram channel | Human analyst post "BUY BTC 50000 SL 48000" | No | Irregular | | In-house model | Your own Python script emitting JSON signals | Yes | Fully variable | | Third-party API | Vendor endpoint returning buy/sell on a schedule | Rarely | Vendor-dependent | Pulsar.INK can consume signals from the first five of these via either webhook endpoint or Telegram-integrated chat. The operator decides which category of source to trust, and the trust decision is a first-class risk concern — see below. ## Execution policy matters as much as the signal A signal says "BUY." The bot has to decide: - **Entry method.** Market order, limit at signal price, limit with X bps slippage, TWAP over Y minutes? - **Position size.** Fixed notional, percent of equity, volatility- normalised, Kelly-fraction? - **Stop-loss placement.** Use the signal's SL (if any)? Use an ATR multiple? Use a fixed percent? - **Take-profit placement.** Same question, in the other direction. - **Duplicate signal handling.** If the same signal re-fires during an open position, pyramid up, ignore, or close-and-reverse? Two operators using the same signal source can produce wildly different PnL purely by choosing different execution policies. This is the part most signal consumers underthink. A good baseline: - Limit orders at signal price with a 15-bps max slippage - Fixed-percent-of-equity sizing (e.g. 2% per signal) - SL at 1.5× ATR(14) or the signal's explicit SL, whichever is tighter - TP at 1.0× ATR(14) trailing, or none (let the signal source emit exit) - Ignore duplicate signals while a position is open ## The survivorship-bias trap Public signal sources are a leaderboard of survivors. Signal providers that produced losses got quiet; the remaining ones produced gains. The backtest on their website starts from the day their strategy started working, not from the day they started the project. Before subscribing to any external signal source, an operator should: 1. Ask for a complete, timestamped signal log covering ≥12 months, ideally ≥24, including signals that did not produce winners. 2. Compute the PnL of that log using the operator's own execution policy, not the provider's. 3. Check that the provider did not delete losers from the log (time-gaps are a tell). 4. Simulate a **pessimistic slippage model**: in liquid markets, bid instead of mid; in illiquid, bid minus X bps. If the provider cannot supply the log, the signal source is an unaudited bet on reputation. That can still be a valid bet; it just is not a data-driven one. See [[backtesting-explained]] for the general survivorship pattern and why look-ahead bias is the closely-related sibling trap. ## Why the executor should NOT reason about the signal Once an operator has chosen to trust a signal source, the executor's only jobs are: - **Receive the signal promptly.** Latency budget for good signal capture is typically 100–500 ms. - **Apply the execution policy deterministically.** No "I think this one is wrong" override. - **Log the result.** Every signal, every fill, every slip — because that log is the input to the next review cycle. An executor that "improves" signals with its own discretion combines the signal provider's uncertainty with the operator's emotional overrides. This is how retail signal trading dies. The discipline is: pick the source, pick the policy, execute mechanically, review on a cadence, change sources or policies at the review — not during trades. ## Relationship to copy trading Copy trading (see [[copy-trading-explained]]) is a degenerate case of signal trading where the "signal" is "whatever this leader account did." Everything above still applies — execution policy, survivorship bias, audit trail — but the signal's observability is worse, because the leader can change strategy overnight and the follower cannot see the reasoning. Signal trading with an auditable rule set is strictly more transparent than copy trading, which is why it is the better default for operators who want to understand what they are doing. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — broader category. - [[copy-trading-explained]] — the identity-based variant. - [[risk-management-automated-trading]] — the caps that bound any signal source's ability to harm the account. - [[backtesting-explained]] — the survivorship / look-ahead / sample- period discipline needed to audit any source. ## Knowledge Base — Telegram Native Trading Ux --- title: "Telegram-native trading UX" slug: telegram-native-trading-ux canonical: https://pulsar.ink/kb/telegram-native-trading-ux.html summary: A Telegram-native trading interface replaces the password+2FA account model with a chat-first conversation model. This page explains why Telegram, the authentication surface, the message-ordered UX, and the notification-budget design. reading_time_minutes: 5 audience: operators evaluating Telegram-login platforms last_updated: 2026-04-24 wikilinks: - what-is-automated-crypto-trading - exchange-api-key-security - risk-management-automated-trading --- # Telegram-native trading UX Pulsar.INK is designed around a **Telegram-native** interface: the operator does not create a password, does not install a separate app, and does not need a dedicated trading screen. Everything the platform can do — connect exchanges, enable strategies, adjust parameters, pause, review PnL — happens inside a Telegram conversation. This page explains why that choice was made and what the design implications are. ## Why Telegram Crypto users already live in Telegram. Community, signals, support, and updates flow through the same app, so a trading interface that shares the surface removes a context switch. More concretely: - **Ubiquitous, cross-platform.** Works identically on iOS, Android, macOS, Windows, Linux, web. No app-store approval dependency and no App Store regional deplatforming risk. - **Push-notification native.** Every alert the platform emits reaches the operator on every device they use Telegram on, without a separate notification channel. - **Chat log is the audit log.** Every command, every parameter change, every notification is permanently in the conversation history. The operator does not need to maintain a separate log. - **Authentication model is borrowed.** Telegram's own account security (2FA, cloud password, device-level confirmation) becomes the platform's security perimeter — we do not re-build it. ## Authentication surface The authentication flow is the Telegram **Mini App** login: 1. Operator opens the platform in Telegram. 2. Telegram issues a signed `initData` payload that identifies the operator's Telegram user ID, session, and device. 3. The platform's server verifies the signature using the bot's secret and treats the Telegram user ID as the platform identity. 4. All subsequent actions happen in the context of that identity. There is **no platform-side password**, and therefore no platform-side password to steal, reset, or phish. There is a trade-off: if the operator's Telegram account is compromised, the attacker inherits the platform session. The mitigations live at the Telegram layer (2FA, cloud password, recent device audit) and at the exchange layer ([[exchange-api-key-security]] keeps withdraw off, so the worst an attacker can do is cross-trade the account rather than empty it). See also [[risk-management-automated-trading]] for kill-switch designs that do not depend on Telegram being reachable — the platform must still be stoppable if the operator loses access to their phone. ## Message-ordered UX A chat-first interface orders actions by time, not by navigation. The operator sees the last thing that happened at the bottom of the screen, with full history above. For trading specifically: - **Strategy change** messages include the diff of parameters (old → new) so the operator can scroll back to understand what they changed. - **Fill** messages include price, size, fees, and a PnL delta since last message. - **Alert** messages are marked by severity (info / warning / critical) and critical alerts are automatically re-pinned. The UX discipline here is to keep messages **self-describing** — a user should be able to understand a one-month-old alert without opening any other screen. A trading platform that makes the user dig is a trading platform that misses alerts. ## Notification budget A notification-heavy trading bot trains operators to ignore notifications. Pulsar.INK's design target is roughly: | Event class | Notification cadence | |-------------------------------------|-----------------------------------| | Every individual fill | Off by default; opt-in | | Cumulative PnL summary | Daily digest, optional | | Drawdown threshold approaching | Immediate, non-suppressible | | Drawdown cap fired / strategy paused | Immediate, non-suppressible | | API key about to expire | 72h in advance, then 24h | | Exchange outage detected | Immediate | | Security event (unusual IP, key rotation) | Immediate, non-suppressible | The principle is: **routine events are pulled, critical events are pushed**. A daily review is the operator's choice; a drawdown-cap-fired alert is not. ## Why not a web dashboard? Pulsar.INK does expose a read-only web dashboard for deeper reviews (long PnL history, multi-strategy comparison, export). But the **control surface** lives in Telegram, because a control surface that requires the operator to log in elsewhere is a control surface that gets used less. Less use of the control surface means slower reactions to problems, which means larger realised losses. ## Trade-offs with Telegram-native The design is not free of drawbacks: - **Regional access.** Telegram is blocked or throttled in a few jurisdictions. Operators in those regions need a VPN on top of Telegram's own anti-blocking mechanisms. - **Telegram outages.** When Telegram is down the control surface is degraded. The platform's own kill-switch infrastructure still operates (see [[risk-management-automated-trading]]), but the operator cannot adjust strategies during the outage. - **Telegram account recovery.** If the operator loses their Telegram account, recovery is a Telegram-side process, not a Pulsar.INK process. The platform cannot restore access to someone who cannot prove they are the same Telegram user. Each of these is acceptable given the design priorities; operators should know about them up front rather than encounter them mid-crisis. ## Further reading in this knowledge base - [[what-is-automated-crypto-trading]] — the platform's core function. - [[exchange-api-key-security]] — the credential-level defence-in-depth. - [[risk-management-automated-trading]] — the kill-switch stack that works when Telegram does not. ## Knowledge Base — What Is Automated Crypto Trading --- title: "What is automated crypto trading?" slug: what-is-automated-crypto-trading canonical: https://pulsar.ink/kb/what-is-automated-crypto-trading.html summary: A definition of automated crypto trading, how it differs from manual trading, the three risk classes every operator has to price in, and where Pulsar.INK fits in the stack. reading_time_minutes: 6 audience: retail and semi-professional crypto traders last_updated: 2026-04-24 wikilinks: - copy-trading-explained - grid-trading-strategy - dca-bot-strategy - risk-management-automated-trading - backtesting-explained - exchange-api-key-security --- # What is automated crypto trading? **Automated crypto trading** is the practice of executing buy and sell orders on a cryptocurrency exchange through software that follows a pre-declared rule set, rather than through human discretion in the moment. The rule set — usually called a **strategy** or **bot** — runs continuously, takes market data as input, and emits orders as output. The operator (you) decides three things up front: 1. **Which market** the bot will trade (e.g. `BTC/USDT` on a specific exchange, or a basket across venues). 2. **Which rules** the bot will follow (grid, DCA, momentum signal, arbitrage, copy, rebalance — see the strategy-specific nodes under [[grid-trading-strategy]], [[dca-bot-strategy]], [[copy-trading-explained]], [[arbitrage-bots]]). 3. **Which risk caps** stop the bot (max drawdown, max position size, time-of-day pauses — see [[risk-management-automated-trading]]). Once those three are declared, the bot executes without you being online. ## How it differs from manual trading | Dimension | Manual trading | Automated trading | |----------------------|-----------------------------------------------|----------------------------------------------------------| | Decision latency | Seconds to minutes (human reaction) | Milliseconds (API round-trip) | | Consistency | Mood, fatigue, sleep affect outcomes | Rule-identical every tick, for better or worse | | Coverage | Hours you are awake and at a screen | 24/7, across dozens of markets in parallel | | Emotional override | Frequent; often the biggest loss source | Impossible unless the operator intervenes | | Failure mode | Usually small, usually recoverable | Potentially large and fast if risk caps are misconfigured| The consistency cuts both ways. Automation removes the main retail loss source (panic-selling, revenge-trading). It also removes the recovery mechanism — if the rule is wrong, the bot will keep applying the wrong rule at machine speed until a risk cap fires. That is why [[risk-management-automated-trading]] is not a footnote: it is the strategy. ## The three risk classes A useful mental model is that every automated-trading operator carries three simultaneous risks: 1. **Market risk** — the asset moves against the strategy's thesis. This is the risk you intend to take, and what the strategy is built to price. 2. **Infrastructure risk** — the bot cannot reach the exchange (your VPS is down, the API is rate-limited, a certificate expired). Orders do not fire, or fire twice. You thought you were out; you are still in. 3. **Credential risk** — the API key the bot holds is stolen, misused, or mis-scoped. The best strategy in the world is worth zero if the key can withdraw funds. Treatment of this risk is the subject of [[exchange-api-key-security]]. A platform takes some of this weight off you: | Risk class | What the operator owns | What Pulsar.INK takes care of | |-------------------|-----------------------------------|--------------------------------------------------| | Market | Strategy choice + parameters | Execution engine, data feed normalisation | | Infrastructure | Telegram account uptime (minimal) | VPS, failover, order reconciliation, retries | | Credential | Exchange-side API-key scoping | Transport encryption, no withdraw-permission use| ## Where Pulsar.INK fits Pulsar.INK is the **execution layer**. It does not custody your coins — those remain on your exchange. It holds an API key with **trade-only** permissions (see [[exchange-api-key-security]] for the mandatory scope list) and runs the strategies you have enabled against that key. Sign-in is Telegram-native (see [[telegram-native-trading-ux]]): the operator connects their Telegram account, links one or more exchange accounts by API key, picks a strategy template, tunes parameters, and arms it. The platform's job is to make every strategy observable and every strategy interruptible from a phone, because crypto markets do not respect office hours. ## What "automated" does *not* mean It does not mean "passive income." Every live strategy has an operator who: - Reviews the strategy's reasoning (see [[backtesting-explained]] for why a good backtest is a necessary but insufficient check). - Adjusts parameters as the market regime changes (bull, bear, chop). - Pulls the plug when conditions fall outside what the strategy was built for. Automation compresses the time cost of execution; it does not compress the time cost of supervision. A realistic operator spends perhaps five to fifteen minutes a day checking the stack, and much more than that when changing strategies or on-boarding a new exchange. ## Further reading in this knowledge base - [[copy-trading-explained]] — inheriting someone else's decisions. - [[grid-trading-strategy]] — the most popular "zero-view" strategy. - [[dca-bot-strategy]] — cost-averaging without touching your phone. - [[signal-trading-bots]] — acting on third-party or in-house signals. - [[arbitrage-bots]] — exploiting price differentials between venues. - [[risk-management-automated-trading]] — the caps that keep one bad strategy from ending the account. - [[backtesting-explained]] — why backtest results rarely survive contact with live markets. - [[telegram-native-trading-ux]] — the design choice behind Pulsar.INK's interface. - [[exchange-api-key-security]] — the credential surface, in detail. --- ## Language: ru (Russian) Locale KB corpus for LLM indexing. Source: https://pulsar.ink/ru/kb/ ### ru/kb/arbitrage-bots.md Source: https://pulsar.ink/ru/kb/arbitrage-bots.html # Арбитражные боты **Арбитраж** — это одновременная покупка и продажа одного и того же базового актива для захвата ценового расхождения. **Арбитражный бот** автоматизирует обнаружение и двустороннее исполнение. В отличие от направленных стратегий, арбитраж должен быть рыночно-нейтральным: движение BTC вверх или вниз не меняет преимущество сделки, только стоимость исполнения. На практике розничный криптоарбитраж определяется двумя реалиями: 1. Прибыльные спреды первыми видят более быстрые боты с колокацией и соглашениями с биржами на уровне маркет-мейкеров. 2. Спреды, которые видит розница, обычно либо слишком малы, чтобы покрыть комиссии после исполнения, либо существуют потому, что задержка вывода/перевода делает арбитраж невозможным. Далее объясняются четыре распространённых варианта и ниши, где розница ещё может выиграть. ## 1. Пространственный арбитраж (межбиржевой) Простейшая форма. Один актив, разные площадки. - Обнаружить: бид BTC/USDT на Бирже A выше аска BTC/USDT на Бирже B. - Исполнить: купить на B по аску, продать на A по биду. - Урегулировать: вы нейтральны по экспозиции на BTC, но нужно восстановить инвентарь между площадками. Скрытое плечо — **восстановление инвентаря**. Чтобы купить на B, нужен USDT на B; чтобы продать на A, нужен BTC на A. Прибыльный цикл зависит не только от спреда, но и от того, находится ли инвентарь там, где нужно. Существуют две модели: - **Предварительно обеспечены обе стороны.** Оператор держит сбалансированный инвентарь на обеих биржах, никогда не перемещая средства в ходе сделки. Быстро, но капитал удвоен (половина на каждой площадке). - **Перевод по требованию.** Оператор переводит купленный актив с B на A для восстановления инвентаря. Медленно (минуты–часы для криптопереводов) и чувствительно к цене во время переводного окна. Большинство прибыльных настроек пространственного арбитража используют предварительное обеспечение обеих сторон с небольшими частыми ребалансировками при истощении одной стороны. Лимиты вывода и комиссии за перевод становятся первостепенными факторами. ## 2. Треугольный арбитраж (внутри биржи) Три пары, одна площадка. Пример на бирже с парами BTC/USDT, ETH/USDT, ETH/BTC: - Начало: 1000 USDT. - Нога 1: купить BTC за USDT по текущей цене BTC/USDT. - Нога 2: купить ETH за BTC по текущей цене ETH/BTC. - Нога 3: продать ETH за USDT по текущей цене ETH/USDT. - Итог: более 1000 USDT, если три цены несогласованы. Это полностью устраняет риск межбиржевых переводов — всё происходит внутри одного аккаунта — но спреды уже, потому что собственные маркет-мейкеры биржи постоянно их закрывают. Треугольный арбитраж — это в основном дисциплина задержки и структуры комиссий: биржи с комиссией за размещение позволяют выставлять ноги как лимитные ордера и получать скидку, превращая почти нулевой спред в положительную сделку. ## 3. Арбитраж ставки финансирования (бессрочные контракты) Криптовалютные бессрочные фьючерсы имеют **ставку финансирования**, которая периодически передаёт стоимость между лонгами и шортами, чтобы удерживать перп привязанным к споту. При положительной ставке лонги платят шортам; при отрицательной — шорты платят лонгам. Сделка: - Купить спотовый BTC на Бирже A. - Зашортить BTC-перп на Бирже A (или B) в том же объёме. - Собирать выплаты по ставке финансирования, когда рынок платит шортам больше, чем лонгам, или наоборот. Вы рыночно-нейтральны по цене BTC и собираете финансирование. Это работает до тех пор, пока: - Ставка финансирования не меняет знак и не поглощает керри. - Спотовая сторона не начинает стоить денег на хранение на бирже (взносы в страховой фонд, ставки кредитования). - Маржа по перпу не ликвидируется при флэш-движении одной стороны, несмотря на то что спотовая позиция компенсирует убыток — механика ликвидации не знает о вашем хедже на другой площадке. Межбиржевой арбитраж ставки финансирования (спот на одной площадке, перп на другой) добавляет слой риска перевода; арбитраж на одной площадке устраняет этот слой ценой концентрации инвентаря. ## 4. Статистический арбитраж (пары, корзины) Два или более актива, которые исторически движутся вместе. Когда спред между ними расширяется за пределы исторических норм, шортируется дорогая нога и покупается дешёвая. Закрытие при возврате спреда к среднему. В строгом смысле это не арбитраж (сделка может оказаться неверной), но в отрасли его называют арбитражем, потому что тезис — «статистический возврат к среднему», а не «направленный взгляд». Это требует более развитой исследовательской инфраструктуры, чем три остальных варианта — тесты на коинтеграцию, скользящие окна, фильтры режима — и обычно является игрой квантовых фондов, а не розницы. ## Реалистичные бюджеты задержки Прибыльная арбитражная сделка обычно имеет окно в миллисекунды–единицы секунд, прежде чем её закроет кто-то другой. Цепочка задержек для розницы: | Этап | Типичная задержка | |------------------------------------|---------------------------| | Рыночные данные: биржа → VPS | 20–150 мс (REST), 5–30 мс (WS) | | Обнаружение ботом + решение | 1–20 мс | | Отправка ордера: VPS → биржа | 20–150 мс | | Обновление стакана биржи | 5–50 мс | Полный цикл для розницы — 50–400 мс в лучшем случае. Любой спред, который просуществовал столько, уже был тонким. Профессиональные арбитражные столы сокращают это до 1–5 мс с помощью колокации и прямых соединений с маркет-мейкерами — и именно они забирают толстые спреды первыми. Розничные ниши, как правило: - **Биржи второго эшелона**, где профессиональные столы слабее представлены. - **Долгоживущие спреды**, вызванные закрытием депозитов/выводов (например, при техническом обслуживании биржи). - **Арбитраж ставки финансирования** на перпах, где речь идёт о керри на дни, а не о миллисекундах. - **Экзотические пары** и токены, где ликвидность мала, но мала и конкуренция. ## Угол рисков Арбитраж рекламируется как «безрисковый», что неверно по любому определению риска: - **Риск исполнения.** Одна нога исполнилась, другая — нет. Теперь вы направленны, хотя не планировали. - **Риск перевода.** Межбиржевые переводы могут зависать. Спреды меняются во время зависания; инвентарь оказывается не там, где нужно. - **Риск контрагента.** Биржа падает, закрывает вывод, замораживает счёт. Весь арбитражный капитал на этой площадке заблокирован. Это крупнейший источник потерь в истории розничного арбитража 2022–2023 годов. - **Асимметрия ликвидации.** Нога перпа ликвидируется при флэш-движении, несмотря на то что спотовый хедж не изменился; убыток по перпу реализован, прибыль по споту — нет. - **Риск API.** API-ключ украден; средства на биржевом счёте уводятся через торговые права (вывод не нужен — атакующий может торговать против вас). См. exchange-api-key-security. Эти риски существуют в фоновом режиме независимо от того, проводите ли вы бэктест или нет; backtesting-explained не улавливает ни одного из них. Лимиты позиций в risk-management-automated-trading — это способ их ограничить. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — место арбитража в таксономии. - exchange-api-key-security — поверхность атаки «торговля без вывода», наиболее важная здесь. - risk-management-automated-trading — лимиты распределения капитала. - backtesting-explained — почему бэктесты арбитража скрывают сценарии риска контрагента, которые дают наибольшие реальные потери. ### ru/kb/backtesting-explained.md Source: https://pulsar.ink/ru/kb/backtesting-explained.html # Бэктестинг: объяснение **Бэктестинг** — это симуляция стратегии на исторических данных. Цель — решить, достаточно ли у стратегии преимущества для запуска в живом режиме. Выходные данные бэктеста — кривая P&L, профиль просадки и торговая статистика — на основе которых оператор решает: развернуть, перенастроить или отказаться. Проблема бэктестов не в том, что они лгут. А в том, что они сообщают очень конкретный вид правды — «как стратегия работала бы **на этой** истории **с этими** допущениями» — которую операторы постоянно неправильно интерпретируют как прогноз. ## Что честный бэктест показывает | Метрика | Что говорит | Чего не говорит | |-------------------------------|-------------------------------------------------------|------------------------------------------------| | Общая доходность | Накопленный P&L за выборку | Насколько волатильным был путь | | Коэффициент Шарпа | Доходность на единицу волатильности | Хвостовой риск; асимметрия волатильности | | Максимальная просадка | Наихудший пик-к-дну в выборке | Возможная просадка вне выборки | | Доля прибыльных сделок | Процент прибыльных сделок | Распределение размеров выигрышей и потерь | | Фактор прибыли | Сумма(выигрышей) / Сумма(потерь) | Насколько стабильно это соотношение во времени | | Время в позиции | Процент времени, когда капитал был задействован | Альтернативные издержки простоя | | Количество сделок | Размер выборки результатов | Были ли все исполнения реалистичными | | Учёт проскальзывания + комис. | Прибыльность после издержек | Глубина реального стакана при заданном объёме | Если бэктест не отчитывается по всем этим метрикам, это реклама, а не бэктест. ## Четыре смещения, уничтожающие розничные бэктесты ### 1. Смещение заглядывания вперёд (look-ahead bias) Стратегия использует данные, недоступные в момент принятия решения. Классический случай — вычисление индикатора на закрытии текущего бара и торговля внутри того же бара. Также распространено: ребалансировка против вселенной, выбранной со знанием того, какие токены дожили до сегодняшнего дня (отсюда «смещение выживаемости»). Исправление: решения в момент `t` должны использовать только данные, доступные в `t`. Обеспечивайте это, сдвигая все сигналы минимум на один бар и торгуя на открытии **следующего** бара, а не на закрытии текущего. ### 2. Смещение выживаемости Вселенная, по которой вы тестируете, — это вселенная, существующая **сегодня**. Каждый делистированный токен, каждая умершая биржа, каждый провалившийся протокол отсутствует. Стратегия возврата к среднему, которая «работает» на сегодняшней вселенной, была бы уничтожена вселенной, существовавшей пять лет назад, потому что проигравшие исчезли. Исправление: тестируйте по **вселенной на конкретный момент времени** — набору активов, доступных для торговли на каждую дату, — что дорого собирать для крипты и практически невозможно для токенов с длинным хвостом. Следующее лучшее исправление — ограничить область бэктеста топ-N активов по ликвидности, признать смещение и соответственно корректировать размеры. ### 3. Смещение по периоду выборки Окно бэктеста — это единственный срез истории рынка, и выбранный срез влияет на результат сильнее, чем стратегия. Сетка BTC/USDT с 2023-01 по 2024-01 выглядит идеально (боковик). Та же сетка с 2024-02 по 2025-04 выглядит ужасно (тренд). Ни одно окно не является неверным; оба неполны. Исправление: отчитывайтесь по нескольким **вне-выборочным** окнам, включая полный цикл бык–медведь–бык. Отчитывайтесь о распределении, а не об одном числе. ### 4. Недооценка проскальзывания Бэктест исполняет по исторической средней цене. На живых рынках исполнение происходит против спреда, а иногда и хуже него, когда стакан тонкий или движение быстрое. Для сеточных ботов, совершающих сотни сделок в день, ошибка в 5 б.п. по проскальзыванию накапливается до очень другого итогового счёта. Исправление: моделируйте **реалистичные исполнения**: - Ордера тейкера — по наихудшей видимой цене запрашиваемого объёма в этот момент времени. - Ордера мейкера исполняются только если цена торгуется **сквозь** выставленный уровень, а не просто касается его. - Во время баров с высокой волатильностью расширяйте модель спреда; в часы низкой ликвидности ограничивайте объём ордера реалистичной долей объёма бара. Ни один публичный движок бэктестинга не делает всё это идеально. Прагматичный подход — провести бэктест, затем дисконтировать результат — на 20–40% меньше ожидаемой доходности, на 30–50% больше просадки — чтобы получить что-то ближе к тому, что будет делать живая стратегия. ## Скользящая вперёд валидация Честная замена «обучить на всей истории, заявить что работает» — **скользящая вперёд валидация**: 1. Выбрать окно внутри выборки (например, 2021-01–2022-01) и настроить стратегию на нём. 2. Выбрать окно вне выборки (2022-01–2022-04) и запустить настроенную стратегию без дополнительной настройки. 3. Сдвинуть окно вперёд (2021-04–2022-04 внутри выборки, 2022-04–2022-07 вне выборки) и повторить. 4. Конкатенировать все P&L вне выборки. Эта конкатенация — то, что стратегия реально может ожидать произвести. Скользящая вперёд валидация систематически снижает отчётную доходность на 30–60% по сравнению с одноокошным фитом. Операторы, не запускающие её, получают завышенные цифры. ## Специфические ловушки криптовалют - **Миграция биржи.** Бэктест BTC/USDT на Бирже A с 2019 года может сшивать данные с биржи, которой больше нет. Ликвидность и спреды не переносятся. - **Отвязка стейблкоина.** Стратегия, использующая USDT как котировочную валюту, предполагает USDT = $1 на каждом баре. Это было неверно в расширенных окнах (май 2022, март 2023), и бэктест обычно не корректирует это. - **Разводнение токена / аирдроп.** Изменения предложения токена незаметно меняют «цену» на длинных горизонтах. - **Изменения расписания комиссий.** Биржи меняют ставки мейкера/тейкера ежеквартально. Бэктест 2020 года с комиссиями 2026 года — оптимистичен. - **Базовые ставки финансирования фьючерсов.** Ставки финансирования снижались с 2021 года по мере созревания ликвидности; бэктест финансирующего арбитража 2018 года — не прогноз 2026 года. ## Специфические заметки по стратегиям - grid-trading-strategy — бэктесты сетки на одном диапазоне всегда выглядят идеально. Повторно протестируйте ту же сетку в медвежьем рынке 2022 года и в прорыве Q1 2024; цифры очень разные. - dca-bot-strategy — бэктесты DCA наиболее честны, но зависят от пути в зависимости от даты старта. Мультистартовый бэктест — решение. - arbitrage-bots — бэктесты игнорируют риск контрагента и задержку перевода, являющиеся двумя крупнейшими источниками реальных потерь. - signal-trading-bots — бэктест провайдера сигналов почти всегда страдает смещением выживаемости; повторно запустите по собственной политике исполнения оператора. Более широкая дисциплина охвачена в risk-management-automated-trading: никакая точность бэктеста не снимает необходимости в лимитах на живом счёте, потому что единственная переменная, которую бэктест не может смоделировать, — это оператор. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — более широкая категория. - risk-management-automated-trading — ограничения, которые связывают нижний предел любой стратегии, независимо от того, что показал бэктест. ### ru/kb/copy-trading-explained.md Source: https://pulsar.ink/ru/kb/copy-trading-explained.html # Копитрейдинг: объяснение **Копитрейдинг** — это форма автоматической торговли (см. what-is-automated-crypto-trading), при которой бот подписчика не принимает торговые решения самостоятельно. Вместо этого он **зеркалирует** сделки выбранного лидера — человека-трейдера, квантового фонда или другого бота — на собственном биржевом счёте подписчика в близком к реальному времени, через API. Подписчик владеет средствами и API-ключом; лидер владеет решениями. Платформа — труба между ними. ## Петля зеркалирования 1. Лидер подаёт ордер на своём биржевом счёте. 2. Платформа обнаруживает исполнение (через опрос API биржи или веб-сокет-поток). 3. Платформа нормализует исполнение в ордер, соответствующий сайзингу подписчика, согласно заявленной модели сайзинга. 4. Платформа подаёт ордер подписчика против его API-ключа. 5. Платформа выверяет — исполнился ли ордер подписчика полностью, частично или не исполнился? — и фиксирует отклонение в журнале P&L подписчика. Каждый шаг вносит небольшое **проскальзывание**: подписчик не получает точно такую же цену, как лидер. Допустимый размер проскальзывания — один из двух главных параметров на стороне подписчика (второй — сайзинг, см. ниже). ## Модели сайзинга Лидер со счётом $1 млн может купить 10 BTC одной сделкой. Если подписчик со счётом $5 000 наивно зеркалирует это, он либо не может позволить себе сделку, либо сжигает счёт одной позицией. В практическом использовании три модели сайзинга: ### 1. Пропорциональный (номинальный) Подписчик торгует `leader_trade_value × (follower_equity / leader_equity)`. Прост, интуитивен, хорошо справляется с разницей в размере счетов. Слабость: когда счёт лидера намного крупнее счёта подписчика, пропорциональная позиция может округляться до торгуемого минимума и молча пропускаться. ### 2. Фиксированный номинальный Подписчик всегда торгует фиксированный долларовый объём (например, $100 на каждую зеркалируемую сделку). Прост, но теряет сигнал убеждённости лидера — «крупная ставка» и «мелкая ставка» лидера становятся одинакового размера на стороне подписчика. ### 3. Паритет риска Подписчик масштабирует позицию, исходя из заявленного стоп-расстояния лидера и максимального риска подписчика на сделку. Соответствует практике профессиональных столов, сложнее всего настроить правильно, обычно требует, чтобы лидер публиковал стоп-лосс рядом с каждым входом. Pulsar.INK поддерживает все три модели. Выбор — за подписчиком и должен быть зафиксирован в его политике risk-management-automated-trading. ## Что копитрейдинг разделяет с сигнальной торговлей, и что нет Копитрейдинг — ближайший родственник следования сигналам (см. signal-trading-bots). Различие — в уровне доверия: | Аспект | Копитрейдинг | Сигнальная торговля | |------------------------------|-------------------------------------------|--------------------------------------------------------| | Кто эмитирует сделку? | Конкретный лидер, по идентичности | Источник сигнала (индикатор, канал, алгоритм) | | Чувствительность к задержке? | Да — зеркалировать нужно быстро | Да, но зависит от типа сигнала | | Видимость выхода | Та же, что и входа — когда лидер выходит | Сигнал может не эмитировать явного выхода | | Риск смещения выживаемости | Высокий (мёртвые лидеры невидимы) | Высокий (мёртвые сигналы невидимы) | | Можно ли аудировать логику? | Только в той мере, что раскрывает лидер | Зависит — сигналы на правилах полностью аудируемы | Главная ловушка копитрейдинга — **смещение выживаемости**: таблица лидеров на любой платформе показывает выживших. Лидеры, которые потеряли счёт, исчезли из списка. Это тот же механизм, который делает результаты backtesting-explained более радужными, чем живые — и именно поэтому должная осмотрительность подписчика при подключении должна выходить за рамки «топ таблицы лидеров на прошлой неделе». ## Бюджет проскальзывания Если лидер исполнился по $50 000, а подписчик — по $50 030, это 6 базисных пунктов (0,06%) проскальзывания. Хороший конвейер зеркалирования удерживает среднее проскальзывание ниже 10 б.п. для ликвидных пар; оно деградирует на тонких парах, движениях на новостях и высокочастотных стратегиях, которые лидер выполняет быстрее, чем зеркало успевает следовать. Подписчик, чьё ожидаемое преимущество за сделку меньше бюджета проскальзывания конвейера, гарантированно будет терять деньги по арифметике, независимо от того, насколько хорош лидер. Именно поэтому копитрейдинг лучше работает для низкочастотных, убеждённых лидеров, чем для лидеров в стиле HFT. ## Налоговая поверхность Копитрейдинг не снимает налоговое обязательство по отдельным сделкам. Каждое зеркалируемое исполнение на бирже подписчика является налоговым событием в большинстве юрисдикций, точно так же, как если бы подписчик входил и выходил сам. Платформа не является налоговым контрагентом; биржа является. Подписчик, следующий за высокочастотным лидером, может накапливать тысячи налоговых событий в год и должен закладывать бюджет на бухгалтерское ПО. ## Режимы отказа, за которыми нужно следить - **Компрометация счёта лидера.** Если счёт лидера скомпрометирован, вредоносные сделки зеркалируются до того, как кто-то это замечает. Единственная защита подписчика — лимит на размер сделки и суммарный дневной лимит просадки — см. risk-management-automated-trading. - **Избыточные права API-ключа.** Копитрейдинг не требует прав на вывод для ключа подписчика; см. exchange-api-key-security для полного списка прав. - **Смена рыночных условий.** Лидер, который был прибыльным на трендовом рынке, может систематически ошибаться на боковом. Отношение копирования должно быть ограничено по времени или зависеть от производительности; это не договорённость «настроил и забыл». - **Сбой платформы в момент выхода лидера.** Если конвейер зеркалирования не работает, пока лидер закрывает прибыльную позицию, подписчик держит позицию открытой. Поведение Pulsar.INK при отказоустойчивости — выравнивание открытых позиций копирования, если петля зеркалирования пропускает heartbeat'ы дольше настраиваемого порога. Это безопаснее, чем оставлять «застрявшую» позицию открытой, но является нетривиальным решением на стороне подписчика. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — более широкая категория, к которой относится эта стратегия. - signal-trading-bots — ближайший не-копи родственник. - risk-management-automated-trading — ограничения, связывающие взрывной радиус лидера. - exchange-api-key-security — почему право вывода отключено на ключах подписчиков. - backtesting-explained — почему таблица лидеров — это не бэктест. ### ru/kb/dca-bot-strategy.md Source: https://pulsar.ink/ru/kb/dca-bot-strategy.html # Стратегия DCA-бота **Усреднение стоимости (DCA)** — это практика покупки фиксированного долларового объёма актива по фиксированному расписанию — например, $100 BTC каждый понедельник — независимо от текущей цены. **DCA-бот** делает это автоматически по настроенному оператором расписанию и может опционально наращивать покупки, когда цена падает ниже скользящих средних. DCA относится к той же категории, что и другие автоматические стратегии (см. what-is-automated-crypto-trading), но является простейшей по логике: единственное решение, которое остаётся — «продолжаю ли я быть оптимистом по этому активу на горизонте накопления?» ## Классический DCA Параметры: - **Актив**: например, BTC - **Расписание**: например, еженедельно, в понедельник в 12:00 UTC - **Сумма на покупку**: например, $100 - **Горизонт**: например, 24 месяца Бот совершает `расписание × горизонт` покупок, по одной за период. Логики выхода нет. Результат — позиция со средней стоимостью входа, равной среднеарифметическому цен закрытия периодов. Два свойства классического DCA стоит усвоить: 1. **Он всегда хуже идеального входа на вершине или идеального входа на дне** — по конструкции, потому что DCA усредняет. Это стратегия «среднего случая». 2. **Он всегда лучше самого худшего входа на вершине** и обычно лучше панических продаж, потому что DCA устраняет точку принятия решений, где вмешиваются эмоции. Простыми словами: вы обмениваете часть потенциальной прибыли на выживаемость. ## Условный DCA (усреднение стоимости / облегчённый мартингейл) Чистый DCA по времени — это дисциплина. Условный DCA добавляет ценовой триггер и приближается к стратегии: - **Базовая покупка каждый период** (классический DCA) - **Дополнительная покупка, когда цена на X% ниже недавнего среднего** - **Пропуск покупки, когда цена на Y% выше недавнего среднего** Это смещает накопление в сторону минимумов и от максимумов, ценой введения параметров для настройки (X, Y, окно «недавнего среднего»). В крайнем случае это становится мартингейлом — удвоение ставки при каждом падении — который имеет известные режимы отказа при структурном, а не временном падении. DCA-бот Pulsar.INK поддерживает оба варианта; оператор выбирает, добавлять ли условия поверх базового расписания. ## Проблема выхода DCA силён при накоплении и молчит о выходе. Это особенность, а не баг: тезис стратегии — «я верю, что этот актив будет стоить больше на моём горизонте, чем при моей средней цене входа». Когда оператор достигает горизонта, он решает о выходе сам — DCA не решает за него. На практике используются три подхода к выходу: | Подход | Когда использовать | Недостаток | |--------------------------|-------------------------------------------------|--------------------------------------------| | Держать / самохранение | Длинный горизонт, нет потребности в фиате | Хвостовой риск на бирже или при самохранении | | Обратный DCA-выход | Когда оператор хочет механического выхода тоже | Ограничивает потенциал роста при выходе | | Триггер на прибыль | Выход при X% выше средней стоимости | Один порог редко подходит для всего цикла | Честная формулировка: если у оператора нет правила выхода, DCA построил всё более ценную позицию без заявленного условия успеха. Это проблема психологии, а не бота. ## DCA против сетки: что выбрать на боковом рынке? DCA и grid-trading-strategy на первый взгляд похожи — оба совершают плановые покупки и лучше работают без сильных трендов — но базовые ставки различны: | Вопрос | DCA | Сетка | |----------------------------------------|---------------------------------|---------------------------------| | На что я делаю ставку? | Долгосрочный рост | Краткосрочные колебания | | Продаю ли внутри периода? | Нет (кроме условного выхода) | Да, на каждом уровне | | Что происходит при обвале цены? | Покупаю по ещё более низкой цене | Сетка ломается, «мешок» висит ниже | | Что происходит при резком росте? | Держу растущую позицию | Сетка распродаётся, входа нет | | Сложность настройки | Минимальная | Средняя–высокая | На боковом рынке DCA медленно накапливает базовую позицию, сетка собирает прибыль от колебаний сверху. Они могут дополнять, а не конкурировать друг с другом. ## Бэктесты и DCA Бэктест DCA — наиболее честный бэктест, который можно провести: параметров так мало, что переобучение почти невозможно. Но он всё равно вводит в заблуждение в одном конкретном смысле: он зависит от пути на выбранном временном окне. DCA на BTC с 2020-01-01 отлично выглядит до 2021-11. Тот же DCA с 2021-11-01 ужасно выглядит до 2022-11. См. backtesting-explained об общей ловушке; для DCA конкретно — проводите бэктест с несколькими датами старта по полному циклу и отчитывайтесь о распределении, а не об одном числе «отсюда до сейчас». ## Заметки о рисках DCA не делает плохой актив хорошим. Если тезис по активу не работает — токен делистируется, протокол взломан, команда проекта исчезла — DCA покупал всё время падения. Ограничение risk-management-automated-trading для DCA обычно — это **суммарный номинальный лимит** на актив, а не на сделку, потому что сделка уже мала по конструкции. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — место DCA в более широкой таксономии. - grid-trading-strategy — родственная стратегия, собирающая прибыль от колебаний. - risk-management-automated-trading — единственное ограничение, которое важно для DCA. - backtesting-explained — ловушка зависимости от пути. ### ru/kb/exchange-api-key-security.md Source: https://pulsar.ink/ru/kb/exchange-api-key-security.html # Безопасность API-ключей биржи **API-ключ** — это пара учётных данных (ключ + секрет), выдаваемая биржей, которая позволяет внешней программе действовать на биржевом счёте владельца. В контексте автоматической торговли (см. what-is-automated-crypto-trading) платформа держит ключ и использует его для подачи ордеров от имени оператора. Ключ — самый опасный объект во всём стеке. Средства никогда не покидают биржу и не попадают на платформу, но ключ всё равно может нанести реальный ущерб при неверной настройке прав. Правильная настройка прав — обязательный первый шаг каждой биржевой интеграции. ## Единственное правило **Право на вывод НЕ ДОЛЖНО быть включено на API-ключе.** Это правило абсолютно. Каждая крупная биржа разделяет права минимум на три класса — Чтение, Торговля, Вывод — и платформе нужны только Чтение и Торговля. Нет законной причины для торгового бота иметь право Вывода; платформе не нужно перемещать средства с биржи для выполнения своей работы. При выключенном Выводе самое худшее, что может сделать скомпрометированный ключ, — торговать против счёта (потеря денег заранее организованному маркет-мейкеру-контрботу — классическая атака). Это реальный ущерб, но основная сумма счёта по-прежнему на бирже и восстановима через поддержку биржи и окна ликвидации по срабатыванию лимита скорости. При включённом Выводе атакующий может опустошить счёт одной транзакцией. Потеря необратима. ## Минимальный набор прав Точные названия различаются по биржам, но каждая платформа должна запрашивать только эти классы: | Право | Типичное название | Обязательно? | |--------------------------------|------------------------------------------------------|-----------------------| | Чтение балансов счёта | "Read Info" / "Account" / "Query" | Да | | Чтение истории ордеров | "Read Orders" / "History" | Да | | Размещение и отмена ордеров | "Trade" / "Spot Trading" / "Margin Trading" | Да | | Вывод средств | "Withdraw" / "Transfer" | **НЕТ** | | Включить маржу | "Margin" / "Futures" | Только если нужно стратегии | | Включить фьючерсы | "Derivatives" / "Perpetual" | Только если нужно стратегии | | Внутренний субперевод | "Universal Transfer" | **НЕТ** (почти всегда)| Оператор должен проверять галочки прав в UI биржи по этому списку каждый раз при создании или ротации ключа. ## IP-allowlist Большинство крупных бирж позволяют оператору привязать API-ключ к **фиксированному IP-allowlist**. Ордер, поданный с IP вне списка, отклоняется. Pulsar.INK, как и большинство платформ, публикует исходящие IP торговых серверов, чтобы операторы могли внести именно эти IP в allowlist. Если allowlist оператора пуст `[]`, ключ используется с любого места, и эффективная безопасность учётных данных вдвое ниже, чем должна быть. Компромиссы: - **Фиксированный allowlist + оператор вставляет ключ.** Наилучшая безопасность; платформа должна публиковать и поддерживать исходящие IP; оператор повторно вставляет ключ при изменении списка. - **Без allowlist.** Легко настроить; взрывной радиус кражи ключа — весь интернет; абсолютно избегать, если биржа не поддерживает allowlist'ы. Для арбитражных стратегий, работающих на нескольких площадках, см. arbitrage-bots — поток межбиржевых переводов — место, где операторов иногда соблазняет включить Вывод «для удобства». Не нужно. Используйте ручные переводы или внутренний субаккаунт при необходимости ребалансировки между площадками. ## Периодичность ротации API-ключи следует ротировать по расписанию. Минимально разумная периодичность: - **Каждые 90 дней** для ключей на торговых счетах. - **Немедленно**, если произошло одно из следующих событий: - Оператор подозревает, что ключ утёк. - Оператор сменил аккаунт Telegram (см. telegram-native-trading-ux, почему это важно). - Платформа раскрыла инцидент безопасности. - Биржа уведомила о необычной активности. Ротация — низкозатратная операция в Pulsar.INK: новый ключ выпускается на бирже, вставляется в интерфейс Telegram, старый ключ отзывается на бирже. Платформа не кэширует старые ключи. ## Обработка секрета на стороне платформы Ключ и секрет оператора зашифрованы в хранилище на платформе и используются только конкретным сервисом подачи ордеров. Они никогда не записываются в логи, никогда не отображаются в сообщениях UI после ввода и никогда не передаются третьим сторонам. С точки зрения оператора защитные меры: 1. **Никогда не копируйте секрет в чат, тикет или письмо** — включая поддержку платформы. Поддержка никогда не спрашивает секрет. 2. **Никогда не вставляйте секрет в форму, обслуживаемую по HTTP** (а не HTTPS). Telegram Mini App работает только по HTTPS. 3. **Отзовите ключ**, если он когда-либо был скопирован-вставлен куда-либо, кроме экрана ввода ключа платформы. Стоимость ротации низка; стоимость утёкшего ключа высока. ## Что делать при компрометации ключа Компрометация — это не только «я потерял ключ». Это также: - Устройство с ключом было утеряно или украдено. - Менеджер паролей с ключом был доступен кому-то другому. - Ключ появился в любом логе, сообщении или файле, переданном другой стороне. Действия: 1. **Отозвать ключ на бирже** (самый быстрый путь — обычно один клик). 2. **Приостановить все стратегии в Pulsar.INK** (аварийный выключатель в Telegram). 3. **Проверить открытые ордера и позиции** на входы, которые оператор не размещал. 4. **Связаться с поддержкой биржи**, если есть свидетельства несанкционированных сделок. 5. **Ротировать любые общие учётные данные** (пароль Telegram, PIN устройства), если путь компрометации ещё не известен. 6. **Выпустить новый ключ** с новым IP-allowlist; повторно активировать стратегии только после подтверждения, что предыдущая компрометация локализована. Фреймворк risk-management-automated-trading применяется и здесь: дневной лимит потерь на счёт обычно срабатывает задолго до того, как атакующий успевает кросстрейдом уничтожить счёт. Этот лимит — запасной рубеж, когда все остальные меры не сработали. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — более широкий контекст. - telegram-native-trading-ux — Telegram-половина периметра безопасности. - risk-management-automated-trading — лимиты потерь, выживающие при компрометации учётных данных. - arbitrage-bots — стратегия, наиболее склонная соблазнить операторов к неверной настройке прав. ### ru/kb/grid-trading-strategy.md Source: https://pulsar.ink/ru/kb/grid-trading-strategy.html # Стратегия сеточной торговли **Сеточная торговля** (grid trading) размещает лестницу ордеров на покупку и продажу на заранее рассчитанных ценовых уровнях внутри диапазона и получает прибыль от колебания рынка вверх-вниз между этими уровнями. В отличие от направленных стратегий, сетка **не** требует мнения о том, куда пойдёт цена — только о диапазоне, в котором она останется. Это делает сеточного бота наиболее популярной автоматической стратегией «без взгляда на рынок» (см. what-is-automated-crypto-trading) для боковых или волатильных рынков. ## Основная механика Предположим, BTC/USDT торгуется по $50 000 и вы ожидаете колебаний между $45 000 и $55 000 в течение нескольких недель. Вы задаёте: - **Диапазон**: $45 000 — $55 000 - **Размер сетки**: 10 уровней (шаг = $1 000) - **Размер ордера на уровень**: 0,01 BTC Бот выставляет: - Ордера на покупку: $49 000, $48 000, $47 000, $46 000, $45 000 - Ордера на продажу: $51 000, $52 000, $53 000, $54 000, $55 000 Каждый раз, когда цена проходит через уровень вниз, соответствующий ордер на покупку исполняется — и бот немедленно выставляет новый ордер на продажу на шаг выше. Каждый раз, когда цена проходит уровень вверх, ордер на продажу исполняется и ниже выставляется новый ордер на покупку. Каждый завершённый цикл (покупка по $49 000, продажа по $50 000) даёт зафиксированную прибыль: $1 000 × 0,01 = $10 минус комиссии. ## Теория диапазона Прибыльность сетки полностью определяется волатильностью внутри заданного диапазона. Взаимодействуют два параметра: | Параметр | Влияние на прибыль за цикл | Влияние на количество циклов | |-----------------------|----------------------------------------------------|-----------------------------------------------| | Шире диапазон | То же (прибыль за шаг не меняется) | Меньше исполнений при типичном колебании | | Гуще сетка | Меньше прибыли за цикл | Больше исполнений при типичном колебании | | Выше волатильность | То же | Больше исполнений за единицу времени | Ожидаемая прибыль сетки приблизительно: ``` expected_profit ≈ (levels_crossed_per_day) × (profit_per_level - fees) ``` Оператор фактически делает ставку на комбинацию: (диапазон держится) × (волатильность внутри диапазона достаточна) × (комиссия биржи мала относительно шага). ## Компромисс плотности сетки Слишком редкая сетка — бот простаивает при мелких движениях. Слишком густая — прибыль за цикл падает ниже уровня комиссий и стратегия медленно теряет средства. Распространённое правило: шаг должен быть не менее **4× односторонней комиссии тейкера**, чтобы полный цикл (два исполнения тейкером) имел двукратную подушку над комиссией. При комиссии тейкера 0,1% — минимальный шаг 0,4%. Ниже этого порога сетка работает на биржу, а не на оператора. ## Математика просадки, о которой не говорят в Twitter Сетка выглядит красиво **пока цена остаётся в диапазоне**. Когда цена выходит за его пределы, сетка внезапно держит несбалансированную позицию: - Если цена пробивает нижнюю границу, каждый ордер на покупку исполнился, но ни один ордер на продажу их не компенсировал. Бот держит максимальную запланированную длинную позицию по наихудшей средней цене. - Если цена пробивает верхнюю границу, все продажи исполнились (при стратегии с шортами) или стратегия полностью вышла из рынка (при стратегии только лонгов). В любом случае накопление прибыли прекратилось. Максимальный размер «мешка» при пробое диапазона: ``` max_bag = order_size × number_of_buy_levels unrealised_loss_at_break = sum(fill_price - current_price) × order_size — по всем исполненным покупкам ``` Конкретный пример: диапазон $45k–$55k, 10 уровней покупки по 0,01 BTC. Цена падает до $30k. Бот держит 0,05 BTC (нижние пять уровней исполнены), куплено в среднем около $47k. Нереализованный убыток: примерно 0,05 × $17 000 = $850 при вложенном капитале $2 350, то есть просадка 36%. Сетка, которая тихо зарабатывала $10 за цикл, только что отдала прибыль от 85 циклов в одном пробое. Именно поэтому сетки неотделимы от risk-management-automated-trading: - **Стоп-лосс ниже нижней границы** — принять, что сетка не сработала, и закрыть позицию, вместо того чтобы усредняться бесконечно. - **Лимит позиции** — суммарный капитал сетки ограничен, а не является фиксированной долей от счёта; пробой одной сетки не должен уничтожить счёт. - **Периодичность пересмотра диапазона** — пересматривать диапазон еженедельно или при любом смещении режима, а не «когда пробьёт». ## Типы сеток | Тип | Описание | Лучше всего подходит | |---------------|-----------------------------------------------------------------------|-----------------------------------| | Арифметическая| Равные долларовые расстояния между уровнями | Стабильные рынки со средней волатильностью | | Геометрическая| Равные процентные расстояния между уровнями | Активы с высокой волатильностью | | Бесконечная | Нет верхней границы; новые ордера на продажу добавляются по мере роста | Спекулянты на сильном апренде | | Обратная | Шорты вместо лонгов; прибыль от диапазона в медвежьем режиме | Только для опытных операторов | | Динамическая | Диапазон пересчитывается на основе ATR или полос Боллинджера | Адаптация к смене режима | Pulsar.INK поддерживает арифметические, геометрические и динамические сетки. ## Когда сетки ломаются Три режима, убивающих сетки в порядке возрастания серьёзности: 1. **Низкая волатильность / узкий боковик.** Исполнений слишком мало; альтернативные издержки развёрнутого капитала превышают доходность сетки. Выход для оператора — сократить сетку или перенаправить капитал в dca-bot-strategy / другие стратегии. 2. **Трендовый рынок.** Цена уходит за пределы диапазона в одном направлении; сетка становится односторонней и перестаёт накапливать прибыль. Выход — раннее распознавание (фильтр тренда поверх сетки) и переопределение диапазона. 3. **Флэш-крэш / новостное событие.** Пробой диапазона происходит быстрее, чем оператор успевает отреагировать, и стоп-лосс (если он есть) срабатывает по значительно худшей цене из-за гэпа. Митигация — жёсткий лимит позиции: даже после гэпа абсолютный долларовый убыток ограничен значением `order_size × buy_levels × (range_width + gap_slippage)`. Бэктесты (см. backtesting-explained) систематически занижают все три режима отказа, потому что используют идеализированные тиковые данные, а не тонкий стакан, существующий во время реальных обвалов. «100% прибыльный» бэктест без просадки следует читать как «эта стратегия никогда не испытывала стресс», а не «эта стратегия безопасна». ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — место сеток в более широкой таксономии стратегий. - dca-bot-strategy — родственная стратегия, ориентированная на накопление. - risk-management-automated-trading — обязательно для сеток. - backtesting-explained — почему бэктесты сеток наиболее вводят в заблуждение. ### ru/kb/risk-management-automated-trading.md Source: https://pulsar.ink/ru/kb/risk-management-automated-trading.html # Управление рисками в автоматической торговле Стратегия описывает **что** будет делать бот. Управление рисками описывает **сколько** счёта боту разрешено потерять, прежде чем его остановят. В ручной торговле эти два аспекта часто сворачиваются в единое суждение. В автоматической торговле их необходимо разделять, потому что бот не делает паузу на переосмысление. Эта страница намеренно скучна. Содержание здесь не умное; это набор ограничений, которые отделяют выживших операторов от проигравших. ## Три слоя Представьте управление рисками как три независимых слоя, каждый из которых должен срабатывать сам по себе, не требуя остальных: 1. **Ограничение на сделку.** Максимальный убыток в любой одной сделке ограничен заранее выставленным стоп-лоссом или размером позиции. Одна катастрофическая сделка не может превысить это значение. 2. **Ограничение на стратегию.** Максимальный накопленный убыток любой одной стратегии за скользящее окно (день / неделя / месяц) ограничен. При достижении — стратегия приостанавливается для проверки человеком. 3. **Ограничение на счёт.** Максимальный накопленный убыток **всех** стратегий ограничен. При достижении — каждая стратегия на счёте приостанавливается. У каждого ограничения есть свой порог оповещения (например, при 80% от лимита), чтобы оператор получал предупреждение до срабатывания лимита, а не после. ## Сайзинг позиции Три правила сайзинга находятся в практическом использовании. Выберите одно для каждой стратегии и запишите. ### 1. Фиксированная доля (простейший) ``` position_size_notional = account_equity × risk_fraction ``` При `risk_fraction` обычно 1–2% для убеждённой сделки, 0,25–0,5% для сигнальной сделки из стороннего источника. Это игнорирует волатильность и стоп-расстояние, что является слабостью, но это правило, которое дольше всего выживает при ошибках оператора. ### 2. Паритет риска (с поправкой на волатильность) ``` position_size_notional = (account_equity × risk_per_trade) / (stop_distance_percent) ``` Размер позиции обратно пропорционален стоп-расстоянию: узкостоп-сделка крупнее, широкостоп-сделка меньше. Это уравнивает долларовый риск по всем сетапам, но требует от оператора честных, взвешенных стопов. ### 3. Доля Келли (продвинутый, легко неправильно использовать) ``` kelly_fraction = win_rate - (1 - win_rate) / payoff_ratio position_size_notional = account_equity × (kelly_fraction × kelly_scale) ``` При `kelly_scale` обычно 0,25–0,5 («дробный Келли»), потому что полный Келли оптимален только если ваши оценки win_rate и payoff точны — а они никогда не точны. Большинство розничных операторов не должны использовать это правило, потому что оценка `win_rate` и `payoff_ratio` из короткой живой истории даёт ужасные числа. ## Лимиты максимальной просадки Единственный наиболее важный параметр управления рисками — **лимит максимальной просадки** на стратегию и на счёт. Просадка 20% требует восстановления на 25%; просадка 50% — на 100%; просадка 90% — на 900%. Компаундирование симметрично в процентах, но асимметрично в долларах. Консервативные розничные настройки: | Лимит | На стратегию | На счёт | |-----------------|--------------|---------| | Дневная потеря | 3% | 2% | | Недельная потеря| 7% | 5% | | Месячная потеря | 15% | 10% | При срабатывании стратегия (или счёт) приостанавливается до проверки оператором и явного повторного включения. Пауза обязательна; это то, что не даёт одной плохой неделе стать одним плохим годом. ## Аварийные выключатели У каждой стратегии должно быть минимум два независимых аварийных выключателя: 1. **Локальный для стратегии.** Сам бот имеет логику просадки, которая останавливает стратегию при срабатывании лимита. Требует, чтобы бот был живым и читал рыночные данные. 2. **На уровне платформы.** Внешний наблюдатель (платформа Pulsar.INK) может приостановить стратегию независимо от того, что думает сама стратегия. Используется при сбоях биржи, лимитах просадки на уровне счёта и отзыве API-ключа. Опора только на локальный аварийный выключатель стратегии — это то, как операторы теряют много при инфраструктурных сбоях: бот завис, ничего его не останавливает, потому что ничего не работает. ## Взрывной радиус стратегии Когда несколько стратегий делят один счёт, взрывной радиус одной стратегии становится системным риском для остальных. Простейший ограничитель взрывного радиуса — **распределение капитала**: заранее объявить максимальный номинал, который стратегия может держать в любой момент, и отклонять любой ордер, который нарушит его. Пример распределения для счёта $10 000: - 40% DCA-бот на BTC и ETH ($4 000) - 25% Сеточный бот на BTC/USDT ($2 500) - 20% Сигнальный бот на alt-мейджорах ($2 000) - 15% Резерв (никогда не развёртывается) ($1 500) Резерв обязателен. Это буфер для маржин-коллов, для оппортунистического повторного входа после паузы по лимиту просадки и для стоимости ошибки в стратегии, которую вы ещё не обнаружили. ## Интеграция с узлами стратегий У каждого семейства стратегий в этой базе знаний есть свой специфический профиль риска: - grid-trading-strategy — доминирующий риск — пробой диапазона; лимит — жёсткий стоп ниже диапазона, а не мягкий лимит просадки. - dca-bot-strategy — доминирующий риск — накопление мёртвого актива; лимит — суммарный номинальный лимит на актив, а не на сделку. - arbitrage-bots — доминирующий риск — контрагент / перевод; лимит — лимит капитала на площадку плюс ежедневный тест вывода. - signal-trading-bots — доминирующий риск — плохие сигналы; лимит — как лимит риска на сделку, так и скользящий P&L-лимит на источник сигналов. - copy-trading-explained — доминирующий риск — изменение поведения лидера; лимит — скользящая P&L-проверка и периодичность проверки ограничена по времени. Каждая стратегия работает под собственным набором лимитов плюс лимит на уровне счёта, применимый ко всем ним. ## Цикл проверки человеком Управление рисками — это не только параметры. Это также периодичность проверки: - **Ежедневно:** беглый взгляд на P&L каждой стратегии и соотношение P&L / лимит. Всё, что превышает 80% лимита, требует внимания. - **Еженедельно:** проверка закрытых сделок и исполнений. Соответствуют ли они намерению стратегии? Неожиданное поведение — более громкий сигнал, чем неожиданный убыток. - **Ежемесячно:** повторная валидация тезиса стратегии. Актуален ли рыночный режим для того, под что стратегия была создана? Если нет — приостановить. - **Ежеквартально:** ребалансировать распределение между стратегиями; вывести из оборота те, что не оправдали своего тезиса два квартала подряд. Этот цикл превращает автоматическую торговлю из «ставки» в «операцию». ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — более широкий контекст. - backtesting-explained — почему ни один бэктест не охватывает полный ландшафт рисков. - exchange-api-key-security — риск на уровне учётных данных, лежащий под всеми этими слоями и не оцениваемый нигде больше. ### ru/kb/signal-trading-bots.md Source: https://pulsar.ink/ru/kb/signal-trading-bots.html # Боты сигнальной торговли **Бот сигнальной торговли** получает сигнал из внешнего источника и действует на его основе, подавая ордер против биржевого счёта оператора. Оператор выбирает источник сигнала; бот — дисциплинированный исполнитель, который не ставит под сомнение сигнал. Это ближайший родственник копитрейдинга (см. copy-trading-explained), но источник сигнала обычно — набор правил, поток данных или вебхук, а не живой счёт другого трейдера. ## Таксономия сигналов | Тип сигнала | Пример | Аудируем? | Типичная периодичность | |--------------------------|----------------------------------------------------------|-----------|------------------------| | Технический индикатор | RSI пересёк 30, переворот гистограммы MACD | Да | Секунды–часы | | Правило ценового действия| Закрытие выше 20-дневного максимума (пробой Дончиана) | Да | Ежедневно | | Вебхук TradingView | Любой кастомный скрипт, эмитирующий оповещения по HTTPS | Иногда | Переменно | | Telegram-канал | Пост аналитика-человека "BUY BTC 50000 SL 48000" | Нет | Нерегулярно | | Внутренняя модель | Собственный Python-скрипт, эмитирующий JSON-сигналы | Да | Полностью переменно | | Сторонний API | Endpoint поставщика, возвращающий buy/sell по расписанию| Редко | Зависит от поставщика | Pulsar.INK может потреблять сигналы из первых пяти типов через вебхук-endpoint или интегрированный с Telegram чат. Оператор решает, какую категорию источника доверять, и решение о доверии — это первостепенная проблема риска — см. ниже. ## Политика исполнения важна не меньше сигнала Сигнал говорит «КУПИТЬ». Бот должен решить: - **Метод входа.** Рыночный ордер, лимит по цене сигнала, лимит с X б.п. проскальзывания, TWAP на Y минут? - **Размер позиции.** Фиксированный номинал, процент от счёта, нормализованный по волатильности, доля Келли? - **Размещение стоп-лосса.** Использовать SL сигнала (если есть)? Кратное ATR? Фиксированный процент? - **Размещение тейк-профита.** Тот же вопрос, в другую сторону. - **Обработка дублирующего сигнала.** Если тот же сигнал повторно поступает в открытую позицию — пирамидировать, игнорировать или закрыть-и-развернуть? Два оператора, использующие один источник сигналов, могут производить совершенно разный P&L исключительно из-за разных политик исполнения. Это часть, которую большинство потребителей сигналов недодумывают. Хорошая база: - Лимитные ордера по цене сигнала с максимальным проскальзыванием 15 б.п. - Сайзинг фиксированным процентом от счёта (например, 2% на сигнал) - SL на 1,5× ATR(14) или явном SL сигнала, в зависимости от того, что жёстче - TP на 1,0× ATR(14) скользящий или без TP (пусть источник сигнала эмитирует выход) - Игнорировать дублирующие сигналы при открытой позиции ## Ловушка смещения выживаемости Публичные источники сигналов — таблица лидеров выживших. Провайдеры сигналов, которые несли убытки, замолчали; оставшиеся приносили прибыль. Бэктест на их сайте начинается с дня, когда их стратегия начала работать, а не с дня, когда они запустили проект. Перед подпиской на любой внешний источник сигналов оператор должен: 1. Запросить полный, временной журнал сигналов за ≥12 месяцев, в идеале ≥24, включая сигналы, которые не привели к выигрышам. 2. Рассчитать P&L этого журнала, используя собственную политику исполнения оператора, а не политику провайдера. 3. Проверить, не удалял ли провайдер проигрышные записи из журнала (временны́е пробелы — признак этого). 4. Смоделировать **пессимистичную модель проскальзывания**: на ликвидных рынках — бид вместо середины; на неликвидных — бид минус X б.п. Если провайдер не может предоставить журнал, источник сигналов — неаудированная ставка на репутацию. Это всё равно может быть допустимой ставкой; просто это не решение на основе данных. См. backtesting-explained для общего паттерна выживаемости и того, почему смещение заглядывания вперёд — тесно связанная ловушка. ## Почему исполнитель НЕ ДОЛЖЕН рассуждать о сигнале Как только оператор решил доверять источнику сигналов, единственные задачи исполнителя: - **Получить сигнал своевременно.** Бюджет задержки для хорошего захвата сигнала — обычно 100–500 мс. - **Применять политику исполнения детерминированно.** Без переопределения «я думаю, этот неверный». - **Логировать результат.** Каждый сигнал, каждое исполнение, каждое проскальзывание — потому что этот журнал — вход для следующего цикла проверки. Исполнитель, «улучшающий» сигналы собственным суждением, сочетает неопределённость провайдера сигналов с эмоциональными переопределениями оператора. Именно так умирает розничная сигнальная торговля. Дисциплина: выбрать источник, выбрать политику, исполнять механически, проверять по расписанию, менять источники или политики на проверке — не во время сделок. ## Связь с копитрейдингом Копитрейдинг (см. copy-trading-explained) — вырожденный случай сигнальной торговли, где «сигнал» — «что делал этот лидерский счёт». Всё вышесказанное по-прежнему применяется — политика исполнения, смещение выживаемости, аудиторский след — но наблюдаемость сигнала хуже, потому что лидер может изменить стратегию за ночь, а подписчик не видит логики. Сигнальная торговля с аудируемым набором правил строго более прозрачна, чем копитрейдинг — вот почему это лучший выбор по умолчанию для операторов, желающих понимать, что они делают. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — более широкая категория. - copy-trading-explained — вариант, основанный на идентичности. - risk-management-automated-trading — ограничения, не дающие любому источнику сигналов навредить счёту. - backtesting-explained — дисциплина выживаемости / заглядывания вперёд / периода выборки, необходимая для аудита любого источника. ### ru/kb/telegram-native-trading-ux.md Source: https://pulsar.ink/ru/kb/telegram-native-trading-ux.html # UX торговли на базе Telegram Pulsar.INK построен на основе интерфейса **на базе Telegram**: оператор не создаёт пароль, не устанавливает отдельное приложение и не нуждается в выделенном торговом экране. Всё, что может делать платформа — подключать биржи, включать стратегии, регулировать параметры, ставить на паузу, проверять P&L — происходит внутри диалога в Telegram. Эта страница объясняет, почему был сделан такой выбор и каковы его последствия для дизайна. ## Почему Telegram Пользователи криптовалюты уже живут в Telegram. Сообщество, сигналы, поддержка и обновления текут через одно приложение, поэтому торговый интерфейс, разделяющий эту поверхность, устраняет переключение контекста. Конкретнее: - **Повсеместный, кросс-платформенный.** Работает одинаково на iOS, Android, macOS, Windows, Linux, в браузере. Нет зависимости от одобрения App Store и нет риска регионального удаления из магазина. - **Нативные push-уведомления.** Каждое оповещение, которое эмитирует платформа, достигает оператора на каждом устройстве с Telegram, без отдельного канала уведомлений. - **Журнал чата — журнал аудита.** Каждая команда, каждое изменение параметра, каждое уведомление постоянно находится в истории разговора. Оператору не нужно вести отдельный журнал. - **Модель аутентификации заимствована.** Собственная безопасность аккаунта Telegram (2FA, облачный пароль, подтверждение на устройстве) становится периметром безопасности платформы — мы не воссоздаём его заново. ## Поверхность аутентификации Поток аутентификации — это вход через Telegram **Mini App**: 1. Оператор открывает платформу в Telegram. 2. Telegram выдаёт подписанный payload `initData`, идентифицирующий Telegram user ID оператора, сессию и устройство. 3. Сервер платформы проверяет подпись с использованием секрета бота и считает Telegram user ID идентичностью на платформе. 4. Все последующие действия происходят в контексте этой идентичности. **Пароля на стороне платформы нет**, и следовательно, нет пароля платформы для кражи, сброса или фишинга. Есть компромисс: если аккаунт Telegram оператора скомпрометирован, атакующий наследует сессию платформы. Меры защиты находятся на уровне Telegram (2FA, облачный пароль, аудит последних устройств) и на уровне биржи (exchange-api-key-security держит вывод выключенным, поэтому худшее, что может сделать атакующий, — кросстрейдить счёт, а не опустошить его). См. также risk-management-automated-trading для дизайнов аварийных выключателей, не зависящих от доступности Telegram — платформа должна оставаться останавливаемой, если оператор теряет доступ к телефону. ## UX с упорядочиванием по сообщениям Интерфейс «чат на первом месте» упорядочивает действия по времени, а не по навигации. Оператор видит последнее произошедшее внизу экрана, с полной историей выше. Для торговли конкретно: - Сообщения об **изменении стратегии** включают разницу параметров (старые → новые), чтобы оператор мог прокрутить назад и понять, что менял. - Сообщения об **исполнении** включают цену, объём, комиссии и дельту P&L с последнего сообщения. - Сообщения-**оповещения** помечены по серьёзности (информация / предупреждение / критично), и критические оповещения автоматически репиннятся. Дисциплина UX здесь — делать сообщения **самодостаточными**: пользователь должен понимать месячное оповещение без открытия какого-либо другого экрана. Торговая платформа, заставляющая пользователя копаться, — платформа, которая пропускает оповещения. ## Бюджет уведомлений Торговый бот с обилием уведомлений приучает операторов игнорировать уведомления. Целевой показатель дизайна Pulsar.INK — примерно: | Класс события | Периодичность уведомлений | |--------------------------------------------|--------------------------------------| | Каждое отдельное исполнение | По умолчанию выключено; opt-in | | Сводка накопленного P&L | Ежедневный дайджест, по желанию | | Приближение к порогу просадки | Немедленно, нельзя подавить | | Срабатывание лимита просадки / пауза стратегии | Немедленно, нельзя подавить | | API-ключ скоро истекает | За 72ч, затем за 24ч | | Обнаружен сбой биржи | Немедленно | | Событие безопасности (необычный IP, ротация ключа) | Немедленно, нельзя подавить | Принцип: **рутинные события запрашиваются, критические события толкаются**. Ежедневная проверка — выбор оператора; оповещение о сработавшем лимите просадки — нет. ## Почему не веб-дашборд? Pulsar.INK действительно предоставляет веб-дашборд только для чтения для более глубоких проверок (длинная история P&L, мультистратегическое сравнение, экспорт). Но **поверхность управления** живёт в Telegram, потому что поверхность управления, требующая входа в другое место, используется реже. Меньшее использование поверхности управления означает более медленные реакции на проблемы, что означает большие реализованные потери. ## Компромиссы Telegram-нативности Дизайн не лишён недостатков: - **Региональный доступ.** Telegram заблокирован или ограничен в нескольких юрисдикциях. Операторам в этих регионах нужен VPN поверх собственных антиблокировочных механизмов Telegram. - **Сбои Telegram.** Когда Telegram не работает, поверхность управления деградирует. Собственная инфраструктура аварийного выключателя платформы продолжает работать (см. risk-management-automated-trading), но оператор не может корректировать стратегии во время сбоя. - **Восстановление аккаунта Telegram.** Если оператор теряет аккаунт Telegram, восстановление — это процесс на стороне Telegram, а не Pulsar.INK. Платформа не может восстановить доступ тому, кто не может доказать, что он тот же пользователь Telegram. Каждый из этих аспектов приемлем с учётом приоритетов дизайна; операторы должны знать о них заранее, а не сталкиваться с ними в разгар кризиса. ## Дополнительное чтение в этой базе знаний - what-is-automated-crypto-trading — основная функция платформы. - exchange-api-key-security — глубокая защита на уровне учётных данных. - risk-management-automated-trading — стек аварийного выключателя, работающий когда Telegram недоступен. ### ru/kb/what-is-automated-crypto-trading.md Source: https://pulsar.ink/ru/kb/what-is-automated-crypto-trading.html # Что такое автоматическая торговля криптовалютой? **Автоматическая торговля криптовалютой** — это практика исполнения ордеров на покупку и продажу на криптовалютной бирже с помощью программного обеспечения, которое следует заранее заданному набору правил, а не принимает решения по усмотрению человека в текущий момент. Набор правил — обычно называемый **стратегией** или **ботом** — работает непрерывно, принимает рыночные данные на вход и выдаёт ордера на выход. Оператор (вы) определяет три вещи заранее: 1. **Какой рынок** будет торговать бот (например, `BTC/USDT` на конкретной бирже или корзина инструментов на разных площадках). 2. **Какие правила** будет соблюдать бот (сетка, DCA, моментум-сигнал, арбитраж, копирование, ребалансировка — см. узлы по конкретным стратегиям: grid-trading-strategy, dca-bot-strategy, copy-trading-explained, arbitrage-bots). 3. **Какие ограничения риска** останавливают бота (максимальная просадка, максимальный размер позиции, паузы по времени суток — см. risk-management-automated-trading). После того как эти три параметра заданы, бот торгует без вашего присутствия. ## Отличия от ручной торговли | Параметр | Ручная торговля | Автоматическая торговля | |----------------------|----------------------------------------------------|---------------------------------------------------------------| | Задержка решений | Секунды–минуты (реакция человека) | Миллисекунды (время круговой поездки API) | | Последовательность | Настроение, усталость, сон влияют на результат | Идентично правилу каждый тик, к лучшему или к худшему | | Охват | Часы, когда вы бодрствуете и у экрана | 24/7, на десятках рынков одновременно | | Эмоциональный выход | Частый; зачастую главный источник потерь | Невозможен без вмешательства оператора | | Режим отказа | Обычно небольшой и устранимый | Потенциально крупный и быстрый при неверных лимитах риска | Последовательность работает в обе стороны. Автоматизация устраняет главный источник потерь у розничных трейдеров (панические продажи, торговля из мести). Она также устраняет механизм восстановления — если правило неверно, бот будет применять его с машинной скоростью до срабатывания ограничения риска. Именно поэтому risk-management-automated-trading — это не сноска: это и есть стратегия. ## Три класса рисков Удобная ментальная модель: каждый оператор автоматической торговли несёт три одновременных риска: 1. **Рыночный риск** — актив движется против тезиса стратегии. Это риск, который вы намеренно принимаете на себя, и именно под него строится стратегия. 2. **Инфраструктурный риск** — бот не может достучаться до биржи (VPS упал, API исчерпал лимит, сертификат истёк). Ордера не отправляются или отправляются дважды. Вы думаете, что вышли из позиции — на самом деле нет. 3. **Риск учётных данных** — API-ключ, которым управляет бот, украден, использован не по назначению или настроен с лишними правами. Лучшая стратегия в мире ничего не стоит, если ключ разрешает вывод средств. Этому риску посвящена статья exchange-api-key-security. Платформа снимает часть этой нагрузки с вас: | Класс риска | Что остаётся за оператором | О чём заботится Pulsar.INK | |------------------|----------------------------------------|----------------------------------------------------| | Рыночный | Выбор стратегии + параметры | Движок исполнения, нормализация потока данных | | Инфраструктурный | Uptime аккаунта Telegram (минимальный) | VPS, отказоустойчивость, сверка ордеров, повторы | | Учётных данных | Настройка прав API-ключа на бирже | Транспортное шифрование, отсутствие права вывода | ## Место Pulsar.INK в стеке Pulsar.INK — это **слой исполнения**. Платформа не хранит ваши монеты — они остаются на вашей бирже. Она держит API-ключ с правами **только на торговлю** (список обязательных прав — в exchange-api-key-security) и запускает включённые вами стратегии через этот ключ. Вход реализован через Telegram (см. telegram-native-trading-ux): оператор подключает аккаунт Telegram, привязывает один или несколько биржевых счетов через API-ключ, выбирает шаблон стратегии, настраивает параметры и активирует её. Задача платформы — сделать каждую стратегию наблюдаемой и прерываемой с телефона, потому что криптовалютные рынки не уважают рабочие часы. ## Что «автоматическая» торговля *не* означает Это не означает «пассивный доход». У каждой активной стратегии есть оператор, который: - Анализирует логику стратегии (см. backtesting-explained, почему хороший бэктест — необходимое, но не достаточное условие). - Корректирует параметры по мере смены рыночного режима (бычий, медвежий, боковик). - Отключает стратегию, когда условия выходят за рамки тех, под которые она создавалась. Автоматизация сжимает временные затраты на исполнение, но не сжимает временные затраты на надзор. Реалистичный оператор тратит примерно пять–пятнадцать минут в день на проверку стека, а при смене стратегий или подключении новой биржи — значительно больше. ## Дополнительное чтение в этой базе знаний - copy-trading-explained — наследование чужих решений. - grid-trading-strategy — самая популярная стратегия «без взгляда на рынок». - dca-bot-strategy — усреднение стоимости без касания телефона. - signal-trading-bots — действия по сигналам сторонних или собственных источников. - arbitrage-bots — использование ценовых расхождений между площадками. - risk-management-automated-trading — ограничения, которые не дают одной плохой стратегии уничтожить счёт. - backtesting-explained — почему результаты бэктестов редко выживают на живых рынках. - telegram-native-trading-ux — дизайнерское решение, лежащее в основе интерфейса Pulsar.INK. - exchange-api-key-security — поверхность учётных данных в деталях. --- ## Language: zh (Chinese (Simplified)) Locale KB corpus for LLM indexing. Source: https://pulsar.ink/zh/kb/ ### zh/kb/arbitrage-bots.md Source: https://pulsar.ink/zh/kb/arbitrage-bots.html # 套利机器人 **套利**是指同时买入和卖出同一基础资产以捕获价差。**套利机器人**将检测和两腿执行自动化。与方向性策略不同，套利理论上是市场中性的：BTC 涨跌不改变交易优势，只影响执行成本。 实践中，散户加密货币套利由两个现实主导： 1. 盈利价差首先被拥有主机托管和交易所做市商协议的更快机器人发现。 2. 散户看到的价差要么太小，无法在成交后覆盖手续费，要么之所以存在是因为提款/转账延迟使其无法被套利。 以下介绍四种常见类型以及散户仍可胜出的领域。 ## 1. 空间套利（跨交易所） 最简单的形式。同一资产，不同平台。 - 检测：交易所 A 的 BTC/USDT 买价高于交易所 B 的 BTC/USDT 卖价。 - 执行：在 B 以卖价买入，在 A 以买价卖出。 - 结算：您对 BTC 敞口为零，但需要在两个平台间重新平衡库存。 隐藏的那一腿是**库存再平衡**。在 B 买入需要 B 上有 USDT；在 A 卖出需要 A 上有 BTC。盈利循环不仅取决于价差，还取决于库存是否在需要的地方。 两种模式： - **双边预存资金。** 操作者在两个交易所都保持平衡库存，交易中途从不转账。速度快，但资金翻倍（每个平台各一半）。 - **按需转账。** 操作者将从 B 购买的资产转移到 A 以恢复库存。速度慢（加密货币转账需分钟至小时），且在转账窗口期间对价格敏感。 大多数盈利的空间套利设置使用双边预存资金，在一侧耗尽时进行小额频繁再平衡。提款限额和转账费用成为一等重要因素。 ## 2. 三角套利（单交易所内） 三个交易对，一个平台。以列有 BTC/USDT、ETH/USDT、ETH/BTC 的交易所为例： - 起始：1000 USDT。 - 第一腿：以当前 BTC/USDT 价格用 USDT 买入 BTC。 - 第二腿：以当前 ETH/BTC 价格用 BTC 买入 ETH。 - 第三腿：以当前 ETH/USDT 价格将 ETH 卖为 USDT。 - 结果：若三个价格不一致，则超过 1000 USDT。 这完全消除了跨交易所转账风险——一切都在一个账户内发生——但由于交易所自身的做市商在不断收敛，价差更窄。三角套利主要是延迟和手续费结构的纪律：提供流动性的平台允许将各腿作为限价单挂出并获得返佣，将近零价差变为正收益交易。 ## 3. 资金费率套利（永续合约） 加密货币永续合约有**资金费率**，定期在多头和空头之间转移价值，以保持永续合约与现货锚定。资金费率为正时，多头支付给空头；为负时，空头支付给多头。 交易： - 在交易所 A 买入现货 BTC。 - 在交易所 A（或 B）做空相同规模的 BTC 永续合约。 - 当市场向空头支付多于多头时（或反之），收取资金费用。 您对 BTC 价格保持中性，收取资金费用。这一策略在以下情况下失效： - 资金费率转向并吞噬套利收益。 - 现货端在交易所托管产生费用（保险基金缴款、借贷利率）。 - 即使现货头寸抵消了损失，永续合约保证金也因单边急速波动而被强平——强平机制不知道您在另一个平台有对冲。 跨交易所资金套利（一个平台现货，另一个平台永续）增加了转账风险层；单一平台资金套利消除了这一层，但代价是库存集中。 ## 4. 统计套利（对、篮子） 两种或多种历史上协同移动的资产。当它们之间的价差扩大超过历史规范时，做空相对高估的一腿，做多相对低估的一腿。价差回归时平仓。 严格意义上这不是套利（交易可能是错的），但行业上称之为套利，因为论点是"统计均值回归"而非"方向性判断"。这需要比其他三种更多的研究基础设施——协整检验、滚动窗口、状态过滤器——通常是量化机构的游戏而非散户的游戏。 ## 实际延迟预算 一笔盈利的套利交易通常有毫秒到几秒的窗口，之后会被他人关闭。散户的延迟链路： | 环节 | 典型延迟 | |----------------------------------|-------------------------| | 市场数据：交易所 → VPS | 20–150 ms（REST），5–30 ms（WS）| | 机器人检测 + 决策 | 1–20 ms | | 订单提交：VPS → 交易所 | 20–150 ms | | 交易所订单簿更新 | 5–50 ms | 散户的往返时间最好情况下为 50–400 ms。任何持续这么久的价差本就已经很薄。专业套利台通过主机托管和直接做市商连接将其缩短至 1–5 ms——他们是首先获取厚价差的人。 散户可寻址的利基通常是： - **二线交易所**，专业台的存在较弱。 - **长期价差**，由存款/提款门控引起（如交易所维护期间）。 - **永续合约资金套利**，关注的是天级别的套利收益而非毫秒。 - **小众交易对**和上市代币，流动性薄但竞争也薄。 ## 风险角落 套利被宣传为"无风险"，但在任何风险定义下都是错误的： - **执行风险。** 一腿成交，另一腿未成交。您现在持有方向性敞口，尽管您无意为之。 - **转账风险。** 跨交易所转账可能延误。延误期间价差变化；库存最终不在需要的地方。 - **交易对手风险。** 交易所宕机、限制提款、冻结账户。您在该平台的所有套利资金被锁定。这是 2022–2023 年散户套利历史上最大的单一亏损来源。 - **强平不对称。** 永续合约腿因急速波动而被强平，即使现货对冲未变；永续合约亏损已实现，现货收益未实现。 - **API 风险。** API 密钥被盗；交易所账户中的资金通过交易权限被取走（不需要提款权限——攻击者可以通过交易将您的资产套走）。参见 exchange-api-key-security。 这些风险无论您是否回测都潜伏在后台；backtesting-explained 无法捕捉其中任何一个。risk-management-automated-trading 中的仓位上限是限制它们的方式。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 套利在分类体系中的位置。 - exchange-api-key-security — 此处最重要的"无需提款的交易攻击"面。 - risk-management-automated-trading — 资金分配上限。 - backtesting-explained — 为何套利回测隐藏了产生最大实际亏损的交易对手风险场景。 ### zh/kb/backtesting-explained.md Source: https://pulsar.ink/zh/kb/backtesting-explained.html # 回测详解 **回测**是在历史数据上模拟策略。目标是判断策略是否有足够的优势值得实盘运行。回测输出是盈亏曲线、回撤特征和交易统计——操作者据此决定部署、重新调参或放弃。 回测的问题不在于它们撒谎。而在于它们讲述一种非常特定的真实——"策略在**这段**历史上**这些**假设下的表现如何"——而操作者一贯地将这种真实误解为预测。 ## 诚实的回测报告什么 | 指标 | 告诉您什么 | 不告诉您什么 | |-------------------------|-------------------------------------------|-------------------------------------------| | 总收益 | 样本期内的累计盈亏 | 路径的波动程度 | | 夏普比率 | 每单位波动率的收益 | 尾部风险；下行与上行波动率 | | 最大回撤 | 样本内最差峰谷回撤 | 样本外可能的回撤 | | 胜率 | 盈利交易占比 | 盈亏规模分布 | | 盈利因子 | Sum(盈利) / Sum(亏损) | 该比率随时间的稳定性 | | 持仓时间 | 资金处于工作状态的时间百分比 | 闲置资金的机会成本 | | 交易次数 | 结果的样本量 | 所有成交是否真实 | | 滑点 + 手续费核算 | 扣除成本后的盈利能力 | 在该订单规模下真实盘口深度 | 如果回测不报告所有这些，它是广告，不是回测。 ## 击垮散户回测的四大偏差 ### 1. 前瞻偏差 策略使用了决策时刻实际不可用的数据。经典案例是在当前 K 线收盘时计算指标，然后在同一根 K 线内交易。还常见：针对用今天存在的代币知识选定的品种池进行再平衡（由此产生"幸存者偏差"）。 修正方法：时间 `t` 的决策必须仅使用 `t` 时刻可用的数据。通过将所有信号至少移位一根 K 线，并在**下一根** K 线开盘时交易而非当前 K 线收盘时来强制执行。 ### 2. 幸存者偏差 您测试的品种池是**今天**存在的品种池。每个被下架的代币、每个倒闭的交易所、每个失败的协议都不在其中。一个在今天品种池上"有效"的均值回归策略，若面对五年前存在的品种池，早就被摧毁了，因为失败者已经消失。 修正方法：针对**时间点品种池**进行测试——每个日期可交易的资产集合——对于加密货币来说成本高昂，对于长尾代币几乎不可能。次优修正是将回测范围限制在流动性前 N 名资产，承认偏差的存在，并相应调整仓位。 ### 3. 样本期偏差 回测窗口是市场历史的一个切片，您选择的切片对结果的影响超过策略本身。2023-01 至 2024-01 的 BTC/USDT 网格回测看起来完美（横盘）。2024-02 至 2025-04 的同一网格回测看起来很糟糕（趋势）。两个窗口都没错；两个都不完整。 修正方法：报告多个**样本外窗口**的结果，包括完整的牛熊牛周期。报告分布，而非单一数字。 ### 4. 滑点低估 回测以历史中间价成交。实盘市场以价差对冲您，当盘口薄或波动快时甚至更差。对于每天执行数百笔交易的网格机器人，5 个基点的滑点误差会复利成差异巨大的最终资金。 修正方法：模拟**真实成交**： - 吃单订单以该时刻请求规模下最差的可见价格成交。 - 挂单订单仅在价格**穿越**挂单价位时成交，而非仅触碰。 - 在高波动 K 线期间加宽价差模型；在低流动性时段，将订单规模限制在 K 线成交量的合理比例内。 没有公开的回测引擎能完美处理所有这些。务实的方法是运行回测，然后对结果打折扣——预期收益降低 20–40%，回撤提高 30–50%——以得到更接近实盘策略实际表现的数字。 ## 前推验证 诚实替代"在所有历史上训练，声称它有效"的方法是**前推验证**： 1. 选择样本内窗口（如 2021-01 至 2022-01）并在其上调参。 2. 选择样本外窗口（2022-01 至 2022-04），对调参后的策略进行测试，**不做进一步调参**。 3. 滑动窗口向前（2021-04 至 2022-04 样本内，2022-04 至 2022-07 样本外）并重复。 4. 拼接所有样本外盈亏。该拼接结果是策略实际可期待产生的结果。 前推验证通常使报告收益比单窗口拟合低 30–60%。不运行前推验证的操作者得到的是过拟合的数字。 ## 加密货币特有的陷阱 - **交易所迁移。** 2019 年起的 BTC/USDT 在交易所 A 的回测，可能拼接了已不存在的交易所数据。流动性和价差不可迁移。 - **稳定币脱锚。** 使用 USDT 作为计价货币的策略假设每根 K 线 USDT = $1。这在较长窗口内曾是错误的（2022 年 5 月、2023 年 3 月），而回测通常不对此修正。 - **代币稀释 / 空投。** 代币供给的持续变化在长周期内悄然改变"价格"。 - **手续费计划变更。** 交易所每季度更改挂单/吃单手续费。使用 2026 年手续费的 2020 年回测是乐观的。 - **期货资金费率基线。** 随着流动性成熟，资金费率自 2021 年以来呈下降趋势；2018 年的资金套利回测不是 2026 年的预测。 ## 各策略专项说明 - grid-trading-strategy — 单区间网格回测总是看起来完美。在 2022 年熊市和 2024 年 Q1 突破行情中重新回测同一网格；数字差异很大。 - dca-bot-strategy — DCA 回测最诚实，但路径依赖于开始日期。多起始日期回测是解决方案。 - arbitrage-bots — 回测忽略交易对手风险和转账延迟，而这两者是最大的实盘亏损来源。 - signal-trading-bots — 信号提供者的回测几乎总是受幸存者偏差影响；使用操作者自己的执行策略重新运行。 更广泛的纪律在 risk-management-automated-trading 中有所介绍：无论回测精度多高，都无法消除实盘账户上限的必要性，因为回测无法模拟的唯一变量是操作者本身。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 更广泛的类别。 - risk-management-automated-trading — 无论回测怎么说，都能限制任何策略下行的上限。 ### zh/kb/copy-trading-explained.md Source: https://pulsar.ink/zh/kb/copy-trading-explained.html # 跟单交易详解 **跟单交易**是一种自动交易形式（参见 what-is-automated-crypto-trading），跟随者的机器人本身不做交易决策。相反，它通过 API 在跟随者自己的交易所账户上近乎实时地**镜像**所选领袖——人类交易员、量化基金或另一个机器人——的交易。 跟随者拥有资金和 API 密钥；领袖拥有决策。平台是两者之间的管道。 ## 镜像循环 1. 领袖在其交易所账户提交订单。 2. 平台通过交易所 API 轮询或 WebSocket 信号检测成交。 3. 平台根据跟随者声明的仓位模型，将成交标准化为适合跟随者仓位规模的订单。 4. 平台通过跟随者的 API 密钥提交跟随者订单。 5. 平台核对——跟随者订单是否全部成交、部分成交或未成交？——并将偏差记录到跟随者的盈亏日志。 每个步骤都引入少量**滑点**：跟随者得不到与领袖完全相同的价格。可接受的滑点大小是跟随者两个主要参数之一（另一个是仓位，见下文）。 ## 仓位模型 账户 $100 万的领袖可能一笔交易买入 10 BTC。如果账户 $5,000 的跟随者天真地镜像，跟随者要么负担不起这笔交易，要么在一个仓位上烧掉账户。实践中使用三种仓位模型： ### 1. 比例（名义） 跟随者交易 `领袖交易额 × (跟随者净值 / 领袖净值)`。简单、直观，能很好地处理账户规模差距。弱点：当领袖账户远大于跟随者时，比例仓位可能舍入到可交易的最低限额并被悄悄跳过。 ### 2. 固定名义 跟随者始终交易固定美元额度（如每笔镜像交易 $100）。简单，但丢失了领袖的信念信号——领袖的"大注"和"小注"在跟随者端都变成相同规模。 ### 3. 风险平价 跟随者根据领袖声明的止损距离和跟随者的每笔最大风险来缩放仓位。与专业交易台实践相符，最难正确配置，通常要求领袖在每次入场时公布止损。 Pulsar.INK 支持全部三种。选择权在跟随者，并应记录在操作者的 risk-management-automated-trading 策略中。 ## 跟单交易与信号交易的共性与差异 跟单交易是信号跟随（参见 signal-trading-bots）的最近亲。区别在于信任级别： | 方面 | 跟单交易 | 信号交易 | |-------------------------|---------------------------------------|---------------------------------------------| | 谁发出交易？ | 特定领袖，通过身份识别 | 信号源（指标、频道、算法） | | 延迟敏感性？ | 是——必须快速镜像 | 是，但取决于信号类型 | | 退出可见性 | 与入场相同——领袖退出时 | 信号可能不发出明确的退出 | | 幸存者偏差风险 | 高（已倒下的领袖不可见） | 高（已消失的信号不可见） | | 能审计推理吗？ | 仅限领袖披露的程度 | 取决于——基于规则的信号完全可审计 | 跟单交易的主要陷阱是**幸存者偏差**：任何平台上的排行榜显示的都是幸存者。爆仓的领袖已从列表中消失。这与使 backtesting-explained 结果看起来比实盘更好的机制相同——这也是为什么跟随者的入职尽职调查需要超越"上周排行榜榜首"。 ## 滑点预算 如果领袖以 $50,000 成交，而跟随者以 $50,030 成交，这是 6 个基点（0.06%）的滑点。良好的镜像管道在流动性强的交易对上将平均滑点控制在 10 个基点以内；在薄交易对、新闻驱动的行情以及领袖运行速度快于镜像跟随速度的高频策略上，滑点会恶化。 预期每笔交易优势小于管道滑点预算的跟随者，无论领袖多好，都保证通过算术亏钱。这就是为什么跟单交易对低频、信念型领袖比对高频交易型领袖效果更好。 ## 税务面 跟单交易不消除个人交易的纳税义务。跟随者交易所上的每笔镜像成交，在大多数司法管辖区都是一个税务事件，就好像跟随者自己进出场一样。平台不是税务对手方；交易所才是。运行高频领袖的跟随者每年可能积累数千个税务事件，应相应为记账软件做出预算。 ## 需要关注的失效模式 - **领袖账户被盗。** 如果领袖账户被盗，恶意交易在任何人注意到之前就被镜像。跟随者唯一的防御是每笔交易规模上限和每日总回撤限制——参见 risk-management-automated-trading。 - **API 密钥权限过大。** 跟单交易不需要跟随者密钥的提款权限；完整权限列表参见 exchange-api-key-security。 - **市场条件转变。** 在趋势市场中盈利的领袖，在震荡市场中可能持续出错。跟单关系应设定时间限制或绩效门控；这不是"设置好就忘了"的安排。 - **平台在领袖退出期间宕机。** 如果镜像管道在领袖平仓赢利时宕机，跟随者保持仓位开放。Pulsar.INK 的故障切换行为是：当镜像循环的心跳信号缺失超过可配置阈值时，平仓所有开放的跟单仓位。这比留下"卡住"的仓位更安全，但这是一个非凡的跟随者端决策。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 该策略所属的更广泛类别。 - signal-trading-bots — 最近的非跟单兄弟策略。 - risk-management-automated-trading — 限制领袖爆炸半径的上限。 - exchange-api-key-security — 为何跟随者密钥关闭提款权限。 - backtesting-explained — 为何排行榜不是回测。 ### zh/kb/dca-bot-strategy.md Source: https://pulsar.ink/zh/kb/dca-bot-strategy.html # DCA 机器人策略 **美元成本平均（DCA）**是指无论当前价格如何，按固定周期购买固定美元金额资产的实践——例如每周一购买价值 $100 的 BTC。**DCA 机器人**按用户设定的节奏自动执行此操作，并可在价格跌破近期移动均线时选择性加大买入。 DCA 与其他自动交易策略（参见 what-is-automated-crypto-trading）属于同一类别，但推理最为简单：唯一需要存活下来的决策是"我是否仍看好这个资产在我的积累周期内的表现？" ## 经典 DCA 参数： - **资产**：例如 BTC - **节奏**：例如每周一 12:00 UTC - **每次买入金额**：例如 $100 - **周期**：例如 24 个月 机器人执行 `节奏 × 周期` 次买入，每期一次。无退出逻辑。结果是一个持仓，成本基础等于各期收盘价的算术平均值。 经典 DCA 的两个值得铭记的特性： 1. **它总是劣于完美的顶部买入或完美的底部买入**——从构造上讲，因为 DCA 是平均值。它是"平均情况"策略。 2. **它总是优于最坏情况的顶部买入**，通常也优于恐慌性抛售，因为 DCA 消除了情绪介入的决策时刻。 简而言之：您用部分上行潜力换取生存能力。 ## 条件 DCA（价值平均 / 轻度马丁格尔） 纯粹的基于时间的 DCA 是一种纪律。条件 DCA 添加价格触发器，更接近策略： - **每期基础买入**（经典 DCA） - **当价格低于近期均线 X% 时额外买入** - **当价格高于近期均线 Y% 时跳过买入** 这将积累倾斜向低点，远离高点，代价是引入需要调整的参数（X、Y、"近期均线"窗口）。在极端情况下，它变成马丁格尔——每次下跌都加倍押注——当下跌是结构性而非短暂性时，这有著名的失效模式。 Pulsar.INK 的 DCA 机器人支持两种变体；操作者选择是否在基础周期之上叠加条件。 ## 退出问题 DCA 擅长积累，对退出保持沉默。这是特性，而非缺陷：策略的论点是"我相信这个资产在我的周期末会比我的成本基础更有价值"。当操作者到达周期末，他们自己决定退出——DCA 不替他们决定。 实践中使用三种退出方法： | 方法 | 适用时机 | 缺点 | |-------------------|---------------------------------------|-----------------------------------| | 持有 / 自托管 | 长周期，不需要法币 | 交易所或自托管的尾部风险 | | 反向 DCA 退出 | 操作者希望机械性退出 | 限制退出途中的上行 | | 利润触发器 | 持仓高于成本基础 X% 时全部退出 | 单一阈值很少适合整个周期 | 诚实的框架：如果操作者没有退出规则，DCA 构建了一个越来越有价值的持仓，但没有声明的成功条件。这是心理问题，不是机器人问题。 ## DCA 与网格：震荡市场中选哪个？ DCA 与 grid-trading-strategy 乍看相似——两者都执行计划买入，两者在没有强趋势时效果最好——但底层押注不同： | 问题 | DCA | 网格机器人 | |--------------------------|--------------------------|--------------------------| | 我在押注什么？ | 长期升值 | 近期震荡 | | 我在周期内卖出吗？ | 否（除非条件退出） | 是，每个价位都卖 | | 价格崩盘时会怎样？ | 我以更低价格买入更多 | 网格失效，"包袱"悬在下方 | | 价格飙涨时会怎样？ | 我持有升值的仓位 | 网格卖出，无法再入场 | | 调整复杂度 | 极低 | 中到高 | 在震荡市场中，DCA 缓慢积累基础仓位，网格在其上收割震荡利润。两者可以互补而非竞争。 ## 回测与 DCA DCA 回测是您能运行的最诚实的回测——参数如此之少，以至于过拟合几乎不可能——但它在一个特定方面仍具误导性：它依赖于样本窗口的路径。从 2020-01-01 开始的 BTC DCA，到 2021-11 看起来很好。同样的 DCA 从 2021-11-01 开始，到 2022-11 看起来很糟糕。关于一般陷阱参见 backtesting-explained；对于 DCA 具体来说，缓解措施是跨完整周期的多个开始日期进行回测，并报告分布而非单一的"从现在到今天"数字。 ## 风险说明 DCA 不能让坏资产变好。如果资产的论点失败——代币被下架、协议被攻击、项目团队消失——DCA 在一路下跌中不断买入。DCA 的 risk-management-automated-trading 上限通常是**每个资产的总名义上限**，而非每笔交易上限，因为每笔交易本身已经很小。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — DCA 在更广泛分类中的位置。 - grid-trading-strategy — 收割震荡的近亲策略。 - risk-management-automated-trading — DCA 最重要的那一个上限。 - backtesting-explained — 路径依赖陷阱。 ### zh/kb/exchange-api-key-security.md Source: https://pulsar.ink/zh/kb/exchange-api-key-security.html # 交易所 API 密钥安全 **API 密钥**是交易所颁发的一对凭证（密钥 + 密钥），允许外部程序对账户所有者的交易所账户进行操作。在自动交易（参见 what-is-automated-crypto-trading）的背景下，平台持有密钥并使用它代表操作者提交订单。 密钥是整个技术栈中最容易被滥用的对象。资金从不离开交易所进入平台，但密钥配置错误后仍可能造成真实损失。正确设置权限范围是每次交易所集成的第一个不可谈判步骤。 ## 唯一规则 **API 密钥上绝不能启用提款权限。** 该规则是绝对的。每个主要交易所将权限分为至少三类——读取、交易、提款——平台只需要读取和交易。交易机器人没有合法理由持有提款权限；平台不需要从交易所移走资金来完成其工作。 当提款关闭时，被盗密钥最坏能做的是对账户进行交易（通过预先安排的做市商对手机器人损失资金是经典攻击）。这是真实伤害，但账户本金仍在交易所，可通过交易所支持和限速触发的平仓窗口恢复。 当提款开启时，攻击者可以通过一笔交易清空账户。损失不可逆。 ## 最低权限范围 各交易所名称不同，但每个平台应只请求以下类别： | 权限 | 各平台典型名称 | 是否必需？ | |-------------------------|------------------------------------------------|--------------------| | 读取账户余额 | "Read Info" / "Account" / "Query" | 是 | | 读取订单历史 | "Read Orders" / "History" | 是 | | 下单和取消订单 | "Trade" / "Spot Trading" / "Margin Trading" | 是 | | 提取资金 | "Withdraw" / "Transfer" | **否** | | 启用保证金 | "Margin" / "Futures" | 仅当策略需要时 | | 启用期货 | "Derivatives" / "Perpetual" | 仅当策略需要时 | | 内部子账户转账 | "Universal Transfer" | **否**（几乎总是） | 操作者每次创建或轮换密钥时，应对照此列表检查交易所 UI 中的权限勾选项。 ## IP 白名单 大多数主要交易所允许操作者将 API 密钥绑定到**固定 IP 白名单**。来自白名单外 IP 的订单将被拒绝。 Pulsar.INK 像大多数平台一样，公布交易服务器的出口 IP，以便操作者将这些 IP 添加到白名单中。如果操作者的白名单为空 `[]`，密钥可以从任何地方使用，凭证的实际安全性仅为应有水平的一半。 权衡： - **固定白名单 + 操作者粘贴密钥。** 最佳安全性；平台必须发布并维护出口 IP；IP 列表更改时操作者需重新粘贴密钥。 - **无白名单。** 设置简单；密钥泄露的爆炸半径是整个互联网；除非交易所不支持白名单，否则坚决避免。 对于在多个平台运行的套利策略，参见 arbitrage-bots——跨平台转账流是操作者有时被诱惑为"方便"而启用提款权限的地方。不要这样做。如果需要跨平台再平衡，使用手动转账或内部子账户。 ## 轮换周期 API 密钥应按周期轮换。最低合理周期： - **每 90 天**，用于纯交易账户上的密钥。 - **立即**，如果发生以下任何事件： - 操作者怀疑密钥泄露。 - 操作者更改了 Telegram 账户（参见 telegram-native-trading-ux 了解原因）。 - 平台披露安全事件。 - 交易所通知异常活动。 在 Pulsar.INK 上，轮换是低摩擦操作：在交易所颁发新密钥，粘贴到 Telegram 界面，在交易所撤销旧密钥。平台不缓存旧密钥。 ## 平台端的密钥处理 操作者的密钥和密钥在平台上静态加密存储，仅被特定的订单提交服务使用。它们从不写入日志，不在输入后的 UI 消息中显示，也不向第三方发送。 从操作者角度看，保护控制包括： 1. **绝不将密钥复制到任何聊天、工单或电子邮件中**——包括平台支持。支持从不要求密钥。 2. **绝不将密钥粘贴到通过 HTTP（而非 HTTPS）提供的表单中**。Telegram Mini App 从设计上只支持 HTTPS。 3. **撤销密钥**，如果它曾被复制粘贴到平台密钥输入界面以外的任何地方。轮换成本低；泄露密钥的成本高。 ## 密钥被盗时该怎么做 被盗不仅仅是"我丢失了密钥"。还包括： - 有密钥的设备丢失或被盗。 - 有密钥的密码管理器被他人访问。 - 密钥出现在与另一方共享的任何日志、消息或文件中。 步骤： 1. **在交易所撤销密钥**（最快路径——通常一键即可）。 2. **在 Pulsar.INK 暂停所有策略**（Telegram 中的紧急开关）。 3. **检查未成交订单和持仓**，查找操作者未放置的入场。 4. **联系交易所支持**，如果有未授权交易的证据。 5. **轮换任何共享凭证**（Telegram 密码、设备级 PIN），如果攻击路径尚未明确。 6. **颁发新密钥**，设置新 IP 白名单；只有在确认之前的攻击已被遏制后才重新启用策略。 risk-management-automated-trading 框架也适用于此：每账户日亏损上限通常在攻击者能通过交叉交易摧毁账户之前就会触发。该上限是所有其他控制失效时的最后防线。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 更广泛的背景。 - telegram-native-trading-ux — 安全边界的 Telegram 端。 - risk-management-automated-trading — 在凭证被盗时仍能存活的亏损上限。 - arbitrage-bots — 最可能诱惑操作者错误配置密钥的策略。 ### zh/kb/grid-trading-strategy.md Source: https://pulsar.ink/zh/kb/grid-trading-strategy.html # 网格交易策略 **网格交易**在预先计算好的价格区间内分层布置买入和卖出订单，从市场在这些价位间上下震荡中获利。与方向性策略不同，网格**不**需要判断价格走向——只需判断价格将在哪个区间内维持。 这使得网格机器人成为最受欢迎的"零观点"自动交易策略（参见 what-is-automated-crypto-trading），适用于震荡或横盘市场。 ## 核心机制 假设 BTC/USDT 价格为 $50,000，您预期在未来几周内将在 $45,000 至 $55,000 之间震荡。您设定： - **区间**：$45,000 至 $55,000 - **网格数量**：10 个价位（间距 = $1,000） - **每个价位订单量**：0.01 BTC 机器人布置： - 买入订单：$49,000、$48,000、$47,000、$46,000、$45,000 - 卖出订单：$51,000、$52,000、$53,000、$54,000、$55,000 每当价格下穿某一价位，对应买单成交——机器人立即在高一档布置新的卖单。每当价格上穿某一价位，卖单成交，低一档布置新买单。每个完整循环（$49,000 买入，$50,000 卖出）锁定利润 $1,000 × 0.01 = $10，扣除手续费。 ## 区间理论 网格的盈利能力完全来源于区间内的波动性。两个参数相互作用： | 参数 | 对每次循环利润的影响 | 对循环次数的影响 | |--------------|------------------------------|-------------------------------| | 区间更宽 | 不变（单步利润不变） | 典型震荡中成交次数更少 | | 网格更密 | 每次循环利润更小 | 典型震荡中成交次数更多 | | 波动性更高 | 不变 | 给定时间窗口内成交次数更多 | 网格的优势大致为： ``` 预期利润 ≈ (每日穿越价位数) × (每价位利润 - 手续费) ``` 因此操作者实际上是在押注：（区间维持）×（区间内足够波动）×（交易所手续费相对间距较小）。 ## 网格密度的权衡 网格太稀疏，机器人在小幅波动中空转。网格太密集，每次循环的利润降到手续费水平以下，策略缓慢失血。 经验法则：间距应至少为**单向吃单手续费的 4 倍**，以使一个完整循环（两次吃单成交）获得 2 倍手续费缓冲。吃单手续费为 0.1% 时，最低间距为 0.4%。低于此水平，网格是在为交易所工作，而非为操作者工作。 ## Twitter 上无人提及的回撤数学 当价格**保持在区间内**时，网格表现完美。一旦价格突破区间，网格突然持有严重失衡的仓位： - 若价格跌破下限，所有买单已成交，而无任何卖单对冲。机器人以最差均价持有最大计划多头仓位。 - 若价格突破上限，所有卖单已成交（若策略做空）或策略已完全退出市场（若仅做多）。无论哪种情况，复利都已停止。 区间突破时的最大持仓量： ``` 最大持仓 = 每单量 × 买入价位数 突破时未实现亏损 = sum(成交价格 - 当前价格) × 每单量（对所有已成交买单求和） ``` 具体示例：区间 $45k–$55k，10 个买入价位，每位 0.01 BTC。价格暴跌至 $30k。机器人持有 0.05 BTC（底部五个价位全部成交），均价约为 $47k。未实现亏损：约 0.05 × $17,000 = $850，投入资金 $2,350，回撤约 36%。一个静静赚取每循环 $10 的网格，在一次区间突破中便亏掉了 85 次循环的利润。 这就是为什么网格与 risk-management-automated-trading 密不可分： - **下限以下设置止损**——承认网格失败并平仓，而非无限向下摊平。 - **仓位上限**——网格投入的总资金有上限，而非账户净值的固定比例；一个网格的突破不应摧毁整个账户。 - **区间审查周期**——每周或在任何状态转换事件时重新定价区间，而非"突破时再说"。 ## 网格类型 | 类型 | 描述 | 最适合 | |----------|-------------------------------------------|------------------| | 等差 | 各价位间距相等（美元） | 稳定、中等波动市场| | 等比 | 各价位间距相等（百分比） | 高波动资产 | | 无限 | 无上限；价格上涨时持续增加卖出价位 | 强上涨趋势投机者 | | 反向 | 做空而非做多；在熊市区间内获利 | 仅适合有经验的操作者| | 动态 | 区间根据最新 ATR 或布林带重新计算 | 适应状态转换 | Pulsar.INK 支持等差、等比和动态网格。 ## 网格失效的时机 三种状态会逐渐加重地击垮网格： 1. **低波动 / 极度横盘。** 成交频率太低；投入资金的机会成本超过网格收益。操作者的对策是缩小网格规模或将资金转向 dca-bot-strategy / 其他策略。 2. **趋势市场。** 价格朝一个方向走出区间；网格变成单边，停止复利。操作者的对策是尽早识别（在网格之上加趋势过滤器）并重新声明区间。 3. **急速崩盘 / 新闻事件。** 区间突破速度快于操作者响应速度，止损（若有）因跳空而以远比声明价位更差的价格触发。操作者的缓解措施是硬仓位上限：即使发生跳空，绝对美元亏损也被限制为 `每单量 × 买入价位数 × (区间宽度 + 跳空滑点)`。 回测（参见 backtesting-explained）系统性地低估了所有三种失效模式，因为回测使用理想化的 tick 数据，而非真实崩盘期间实际存在的稀薄订单簿。"100% 盈利"且无回撤的回测应被理解为"该策略从未经受压力测试"，而非"该策略是安全的"。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 网格在更广泛策略体系中的位置。 - dca-bot-strategy — 以积累为导向的近亲策略。 - risk-management-automated-trading — 网格必不可少的风险管理。 - backtesting-explained — 为何网格回测最具误导性。 ### zh/kb/risk-management-automated-trading.md Source: https://pulsar.ink/zh/kb/risk-management-automated-trading.html # 自动交易中的风险管理 策略描述机器人**做什么**。风险管理描述机器人被允许在被停止之前**损害多少**账户。在手动交易中，两者通常被合并为单一判断。在自动交易中，它们必须分离，因为机器人不会停下来重新考虑。 本页故意平淡无奇。内容并不聪明；它是将存活操作者与未存活操作者区分开来的上限集合。 ## 三层结构 将风险管理视为三个独立层次，每层都应独立触发，无需其他层次： 1. **单笔交易上限。** 任何单笔交易的最大亏损通过预先放置的止损或仓位大小来约束。一笔灾难性交易不能超过此限。 2. **单策略上限。** 任何单一策略在滚动窗口（日/周/月）内的最大累计亏损受到约束。触达后，该策略暂停以供人工审查。 3. **账户上限。** **所有**策略的最大累计亏损受到约束。触达后，账户上所有策略暂停。 每个上限都有自己的警报阈值（如上限的 80%），以便操作者在上限触发之前收到警告，而非之后。 ## 仓位规模 三种规模规则在实践中使用。每个策略选择一种并写下来。 ### 1. 固定比例（最简单） ``` 名义仓位 = 账户净值 × 风险比例 ``` 信念型交易的 `风险比例` 通常为 1–2%，来自第三方源的信号交易为 0.25–0.5%。这忽略了波动性和止损距离，是个弱点，但这是最能在操作者错误下存活的规则。 ### 2. 风险平价（波动率调整） ``` 名义仓位 = (账户净值 × 每笔风险) / (止损距离百分比) ``` 仓位大小与止损距离成反比，因此止损紧的交易更大，止损宽的交易更小。这使各交易的美元风险均等，但要求操作者放置诚实、有依据的止损。 ### 3. 凯利分数（高级，容易误用） ``` 凯利分数 = 胜率 - (1 - 胜率) / 赔率 名义仓位 = 账户净值 × (凯利分数 × 凯利缩放) ``` `凯利缩放` 通常为 0.25–0.5（"部分凯利"），因为完整凯利仅在胜率和赔率估计完全正确时才最优，而这从来不可能。大多数散户操作者不应使用此规则，因为从较短的实盘历史中估算 `胜率` 和 `赔率` 会产生糟糕的数字。 ## 最大回撤上限 最重要的单一风险管理参数是每策略和每账户的**最大回撤上限**。20% 的回撤需要 25% 的恢复；50% 的回撤需要 100% 的恢复；90% 的回撤需要 900% 的恢复。以百分比计复利是对称的，但以美元计是不对称的。 保守散户设置： | 上限 | 每策略 | 每账户 | |----------|--------|--------| | 日亏损 | 3% | 2% | | 周亏损 | 7% | 5% | | 月亏损 | 15% | 10% | 触达后，策略（或账户）暂停，直到操作者审查并明确重新启用。暂停是不可谈判的；它是防止糟糕的一周变成糟糕的一年的东西。 ## 紧急开关 每个策略应至少有两个独立的紧急开关： 1. **策略本地。** 机器人本身有回撤逻辑，当上限触发时停止策略。要求机器人存活并读取市场数据。 2. **平台级别。** 外部监视器（Pulsar.INK 平台）可以暂停策略，无论策略本身怎么认为。用于交易所中断、账户级回撤上限和 API 密钥撤销。 仅依赖策略本地紧急开关是操作者在基础设施中断期间大量损失的原因——机器人挂起，没有任何东西停止它，因为什么都没在运行。 ## 单策略爆炸半径 当多个策略共享一个账户时，一个策略的爆炸半径成为其他策略的系统性风险。最简单的爆炸半径限制器是**资金分配**：提前声明任何时候一个策略可以持有的最大名义额，并拒绝任何会违反它的订单。 $10,000 账户的分配示例： - 40% BTC 和 ETH 的 DCA 机器人（$4,000） - 25% BTC/USDT 网格机器人（$2,500） - 20% 主流山寨币信号机器人（$2,000） - 15% 储备金（永不部署）（$1,500） 储备金是不可谈判的。它是保证金追缴的缓冲区，是回撤上限暂停后机会性再入场的资金，以及您尚未发现的策略错误的成本。 ## 与策略节点的集成 本知识库中每个策略系列都有其特定风险特征： - grid-trading-strategy — 主导风险是区间突破；上限是区间下方的硬止损，而非软性回撤上限。 - dca-bot-strategy — 主导风险是积累死资产；上限是每资产总名义上限，而非每笔交易上限。 - arbitrage-bots — 主导风险是交易对手/转账；上限是每平台资金上限加每日提款测试。 - signal-trading-bots — 主导风险是糟糕的信号；上限包括每笔交易风险上限和信号源的滚动盈亏上限。 - copy-trading-explained — 主导风险是领袖行为改变；上限是滚动盈亏审查和有时间限制的审查周期。 每个策略在其自己的上限集下运行，加上适用于所有策略的账户级上限。 ## 人工审查循环 风险管理不仅仅是参数。还有审查周期： - **每日：** 快速查看每个策略的盈亏和盈亏/上限比例。任何超过上限 80% 的都需要关注。 - **每周：** 审查已平仓交易和成交。它们是策略预期的吗？意外行为比意外亏损更响的信号。 - **每月：** 重新验证策略论点。市场状态仍然是该策略设计用于的状态吗？如果不是，暂停。 - **每季度：** 重新平衡策略间的分配；淘汰连续两个季度未能实现其论点的策略。 这个循环将自动交易从"赌注"变成"运营"。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 更广泛的背景。 - backtesting-explained — 为何没有回测能捕捉全部风险景观。 - exchange-api-key-security — 位于所有这些之下、在其他任何地方都未定价的凭证级风险。 ### zh/kb/signal-trading-bots.md Source: https://pulsar.ink/zh/kb/signal-trading-bots.html # 信号交易机器人 **信号交易机器人**从外部来源接收信号，并通过对操作者的交易所账户提交订单来执行。操作者选择信号源；机器人是不质疑信号的纪律性执行者。 这是跟单交易（参见 copy-trading-explained）最近的兄弟，但信号源通常是规则集、信息流或 Webhook，而非另一个交易者的实盘账户。 ## 信号分类 | 信号类型 | 示例 | 可审计性 | 典型频率 | |------------------|--------------------------------------------------|----------|---------------| | 技术指标 | RSI 穿越 30，MACD 柱状图翻转 | 是 | 秒至小时 | | 价格行为规则 | 收盘突破 20 日高点（唐奇安突破） | 是 | 每日 | | TradingView Webhook | 通过 HTTPS 发送警报的任何自定义脚本 | 有时 | 可变 | | Telegram 频道 | 人类分析师发帖"BUY BTC 50000 SL 48000" | 否 | 不定期 | | 内部模型 | 您自己发出 JSON 信号的 Python 脚本 | 是 | 完全可变 | | 第三方 API | 按计划返回买入/卖出的供应商端点 | 少见 | 取决于供应商 | Pulsar.INK 可以通过 Webhook 端点或 Telegram 集成聊天消费前五种信号。操作者决定信任哪类来源，信任决策是一等重要的风险问题——见下文。 ## 执行策略与信号同等重要 信号说"买入"。机器人必须决定： - **入场方式。** 市价单、限价在信号价格、限价加 X 个基点滑点、在 Y 分钟内 TWAP？ - **仓位规模。** 固定名义、净值百分比、波动率标准化、凯利分数？ - **止损位置。** 使用信号的止损（如有）？使用 ATR 倍数？固定百分比？ - **止盈位置。** 反方向同样的问题。 - **重复信号处理。** 若同一信号在持仓期间再次触发，加仓、忽略还是平仓并反向？ 使用同一信号源的两位操作者，仅因选择了不同的执行策略，就可能产生截然不同的盈亏。这是大多数信号消费者思考不足的部分。良好的基线： - 在信号价格的限价单，最大滑点 15 个基点 - 固定净值百分比规模（如每个信号 2%） - 止损在 1.5× ATR(14) 或信号明确止损，取较紧者 - 止盈在 1.0× ATR(14) 追踪，或不设（让信号源发出退出） - 持仓期间忽略重复信号 ## 幸存者偏差陷阱 公开信号源是幸存者排行榜。产生亏损的信号提供者沉默了；剩余的产生了收益。他们网站上的回测从他们的策略开始奏效的那天算起，而非他们启动项目的那天。 在订阅任何外部信号源之前，操作者应： 1. 请求涵盖 ≥12 个月（理想 ≥24）的完整带时间戳的信号日志，包括未产生盈利的信号。 2. 使用操作者自己的执行策略（而非提供者的策略）计算该日志的盈亏。 3. 检查提供者是否从日志中删除了亏损记录（时间空缺是迹象）。 4. 模拟**悲观滑点模型**：在流动性强的市场，使用买价而非中间价；在流动性差的市场，使用买价减 X 个基点。 如果提供者无法提供日志，信号源就是一个未经审计的信誉押注。这仍然可以是一个有效的押注；只是它不是数据驱动的决策。 关于一般幸存者模式，参见 backtesting-explained，以及为何前瞻偏差是密切相关的兄弟陷阱。 ## 为何执行者不应推断信号 一旦操作者决定信任信号源，执行者唯一的工作是： - **及时接收信号。** 良好信号捕获的延迟预算通常为 100–500 ms。 - **确定性地应用执行策略。** 不存在"我觉得这个是错的"的覆盖。 - **记录结果。** 每个信号、每次成交、每次滑点——因为该日志是下一个审查周期的输入。 "改进"信号的执行者将信号提供者的不确定性与操作者的情绪覆盖相结合。这就是散户信号交易消亡的方式。纪律是：选择来源，选择策略，机械执行，按周期审查，在审查时更改来源或策略——而非在交易期间。 ## 与跟单交易的关系 跟单交易（参见 copy-trading-explained）是信号交易的退化案例，其中"信号"是"这个领袖账户做了什么"。以上所有内容仍然适用——执行策略、幸存者偏差、审计追踪——但信号的可观察性更差，因为领袖可以在一夜之间改变策略，而跟随者看不到推理过程。 具有可审计规则集的信号交易严格来说比跟单交易更透明——这就是为什么对于希望理解自己在做什么的操作者来说，它是更好的默认选择。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 更广泛的类别。 - copy-trading-explained — 基于身份的变体。 - risk-management-automated-trading — 限制任何信号源损害账户能力的上限。 - backtesting-explained — 审计任何来源所需的幸存者/前瞻/样本期纪律。 ### zh/kb/telegram-native-trading-ux.md Source: https://pulsar.ink/zh/kb/telegram-native-trading-ux.html # Telegram 原生交易用户体验 Pulsar.INK 围绕**Telegram 原生**界面设计：操作者无需创建密码，无需安装独立应用，也不需要专用的交易屏幕。平台能做的一切——连接交易所、启用策略、调整参数、暂停、审查盈亏——都发生在 Telegram 对话内。 本页解释这一选择的原因及其设计含义。 ## 为何选择 Telegram 加密货币用户已经生活在 Telegram 中。社区、信号、支持和更新都通过同一个应用流动，因此共享这个界面的交易接口消除了上下文切换。更具体地说： - **无处不在，跨平台。** 在 iOS、Android、macOS、Windows、Linux 和 Web 上运行完全相同。无需依赖 App Store 审批，也无区域下架风险。 - **原生推送通知。** 平台发出的每个警报都会在操作者使用 Telegram 的每台设备上到达，无需单独的通知渠道。 - **聊天日志即审计日志。** 每个命令、每次参数更改、每次通知都永久保存在对话历史中。操作者无需维护单独的日志。 - **借用认证模型。** Telegram 自身的账户安全（2FA、云密码、设备级确认）成为平台的安全边界——我们不重新构建它。 ## 认证面 认证流程是 Telegram **Mini App** 登录： 1. 操作者在 Telegram 中打开平台。 2. Telegram 颁发一个签名的 `initData` 载荷，标识操作者的 Telegram 用户 ID、会话和设备。 3. 平台服务器使用机器人密钥验证签名，并将 Telegram 用户 ID 视为平台身份。 4. 所有后续操作都在该身份的上下文中进行。 **平台端没有密码**，因此也没有可被盗、重置或钓鱼的平台密码。 存在一个权衡：如果操作者的 Telegram 账户被盗，攻击者继承平台会话。缓解措施位于 Telegram 层（2FA、云密码、最近设备审计）和交易所层（exchange-api-key-security 关闭提款权限，因此攻击者最坏只能交叉交易账户而非清空它）。 另见 risk-management-automated-trading，了解不依赖 Telegram 可达性的紧急开关设计——当操作者无法访问手机时，平台仍必须可停止。 ## 按消息顺序排列的用户体验 以聊天为首的界面按时间而非导航对操作进行排序。操作者在屏幕底部看到最后发生的事情，上方是完整历史。对于交易具体而言： - **策略更改**消息包含参数差异（旧→新），以便操作者可以滚动回顾了解自己改了什么。 - **成交**消息包含价格、规模、手续费以及自上条消息以来的盈亏变化。 - **警报**消息按严重程度标记（信息/警告/严重），严重警报会自动置顶。 这里的用户体验纪律是使消息**自描述**——用户应该能在不打开任何其他界面的情况下理解一个月前的警报。需要用户深入查找的交易平台是会错过警报的平台。 ## 通知预算 通知过多的交易机器人训练操作者忽略通知。Pulsar.INK 的设计目标大致是： | 事件类别 | 通知频率 | |--------------------------------------|-----------------------------------| | 每次个别成交 | 默认关闭；可选择开启 | | 累计盈亏摘要 | 每日摘要，可选 | | 回撤阈值接近 | 立即，不可屏蔽 | | 回撤上限触发/策略暂停 | 立即，不可屏蔽 | | API 密钥即将过期 | 提前 72 小时，然后 24 小时 | | 检测到交易所中断 | 立即 | | 安全事件（异常 IP、密钥轮换） | 立即，不可屏蔽 | 原则是：**常规事件被拉取，关键事件被推送**。每日审查是操作者的选择；回撤上限触发警报不是。 ## 为何不是 Web 控制台？ Pulsar.INK 确实提供只读 Web 控制台用于更深入的审查（长期盈亏历史、多策略比较、导出）。但**控制面**位于 Telegram，因为需要操作者登录其他地方的控制面会被使用得更少。控制面使用减少意味着对问题的反应变慢，这意味着更大的已实现损失。 ## Telegram 原生的权衡 这种设计并非没有缺点： - **区域访问。** Telegram 在少数司法管辖区被封锁或限速。这些地区的操作者需要在 Telegram 自身的反封锁机制之上使用 VPN。 - **Telegram 中断。** 当 Telegram 宕机时，控制面降级。平台自身的紧急开关基础设施仍然运行（参见 risk-management-automated-trading），但操作者在中断期间无法调整策略。 - **Telegram 账户恢复。** 如果操作者失去了 Telegram 账户，恢复是 Telegram 端的流程，而非 Pulsar.INK 的流程。平台无法为无法证明自己是同一 Telegram 用户的人恢复访问权限。 考虑到设计优先级，每一点都是可接受的；操作者应该提前了解它们，而非在危机中途遇到它们。 ## 本知识库延伸阅读 - what-is-automated-crypto-trading — 平台的核心功能。 - exchange-api-key-security — 凭证级纵深防御。 - risk-management-automated-trading — Telegram 不可用时仍能工作的紧急开关堆栈。 ### zh/kb/what-is-automated-crypto-trading.md Source: https://pulsar.ink/zh/kb/what-is-automated-crypto-trading.html # 什么是加密货币自动交易？ **加密货币自动交易**是指通过遵循预先声明的规则集的软件，在加密货币交易所执行买入和卖出订单，而非依赖人工当下判断的实践。该规则集——通常称为**策略**或**机器人**——持续运行，接收市场数据作为输入并输出订单。 操作者（您）需要预先决定三件事： 1. **交易哪个市场**（例如特定交易所的 `BTC/USDT`，或跨多个平台的一篮子资产）。 2. **机器人遵循哪些规则**（网格、DCA、动量信号、套利、跟单、再平衡——参见 grid-trading-strategy、dca-bot-strategy、copy-trading-explained、arbitrage-bots 各策略专项节点）。 3. **哪些风险上限会停止机器人**（最大回撤、最大仓位规模、日内暂停——参见 risk-management-automated-trading）。 一旦声明这三点，机器人便会在您不在线的情况下执行交易。 ## 与手动交易的区别 | 维度 | 手动交易 | 自动交易 | |----------------|---------------------------------------|--------------------------------------------------| | 决策延迟 | 秒至分钟（人工反应） | 毫秒（API 往返时间） | | 一致性 | 情绪、疲劳、睡眠影响结果 | 每一个 tick 完全遵守规则，无论好坏 | | 覆盖范围 | 您清醒并在屏幕前的时间 | 24/7，同时覆盖数十个市场 | | 情绪干预 | 频繁；通常是最大亏损来源 | 不可能，除非操作者主动干预 | | 失败模式 | 通常较小且可恢复 | 若风险上限配置错误，可能迅速造成较大损失 | 一致性是双刃剑。自动化消除了散户的主要亏损来源（恐慌性抛售、报复性交易），同时也消除了恢复机制——若规则错误，机器人将以机器速度持续应用错误规则，直到风险上限触发。正因如此，risk-management-automated-trading 不是脚注，而就是策略本身。 ## 三类风险 一个有用的心智模型：每位自动交易操作者同时承担三类风险： 1. **市场风险**——资产走向与策略论点相反。这是您有意承担的风险，也是策略构建的基础。 2. **基础设施风险**——机器人无法连接交易所（您的 VPS 宕机、API 限流、证书过期）。订单未发出，或重复发出。您以为已平仓，实际上仍持仓。 3. **凭证风险**——机器人持有的 API 密钥被盗、被滥用或权限配置错误。世界上最好的策略，如果密钥可以提款，价值为零。该风险的处理方案详见 exchange-api-key-security。 平台可以为您分担部分压力： | 风险类别 | 操作者负责 | Pulsar.INK 负责 | |------------|--------------------------|------------------------------------------| | 市场 | 策略选择 + 参数 | 执行引擎、数据源规范化 | | 基础设施 | Telegram 账户正常运行（极低要求）| VPS、故障切换、订单核对、重试 | | 凭证 | 交易所端 API 密钥权限配置 | 传输加密，不使用提款权限 | ## Pulsar.INK 的位置 Pulsar.INK 是**执行层**。它不托管您的资产——您的加密货币仍在交易所。它持有**仅交易**权限的 API 密钥（强制权限范围列表详见 exchange-api-key-security），并针对该密钥运行您启用的策略。 登录基于 Telegram（参见 telegram-native-trading-ux）：操作者关联 Telegram 账户，通过 API 密钥绑定一个或多个交易所账户，选择策略模板，调整参数并激活。平台的职责是让每个策略都可观察、可随时从手机中断，因为加密货币市场不尊重工作时间。 ## "自动化"*不*意味着什么 它不意味着"被动收入"。每个运行中的策略都有一位操作者： - 审查策略的推理逻辑（为什么好的回测是必要但不充分的条件，参见 backtesting-explained）。 - 随着市场状态变化（牛市、熊市、震荡）调整参数。 - 当市场条件超出策略设计范围时拔插头。 自动化压缩了执行的时间成本，并不压缩监督的时间成本。实际操作者每天大约花五到十五分钟检查系统，切换策略或接入新交易所时则需要更多时间。 ## 本知识库延伸阅读 - copy-trading-explained — 继承他人的交易决策。 - grid-trading-strategy — 最流行的"零观点"策略。 - dca-bot-strategy — 无需触碰手机的成本平均法。 - signal-trading-bots — 基于第三方或内部信号行动。 - arbitrage-bots — 利用各平台间的价差。 - risk-management-automated-trading — 防止单一糟糕策略摧毁账户的上限。 - backtesting-explained — 为何回测结果鲜少在真实市场中存活。 - telegram-native-trading-ux — Pulsar.INK 界面背后的设计选择。 - exchange-api-key-security — 凭证层面的详细说明。 --- ## Language: ar (Arabic) Locale KB corpus for LLM indexing. Source: https://pulsar.ink/ar/kb/ ### ar/kb/arbitrage-bots.md Source: https://pulsar.ink/ar/kb/arbitrage-bots.html # بوتات المراجحة **المراجحة** هي الشراء والبيع المتزامن للأصل الجوهري ذاته لالتقاط فارق السعر. **بوت المراجحة** يُؤتمت اكتشاف الساقين وتنفيذهما. على عكس الاستراتيجيات الاتجاهية، يجب أن تكون المراجحة محايدة تجاه السوق: ارتفاع أو انخفاض BTC لا يغير ميزة الصفقة، بل تكلفة التنفيذ فقط. في الواقع العملي، تهيمن على مراجحة العملات المشفرة في قطاع التجزئة حقيقتان: 1. الفوارق المربحة تُرصد أولاً من بوتات أسرع مع خوادم مُدمجة في البورصة واتفاقيات صنع السوق على مستوى البورصة. 2. الفوارق التي يراها قطاع التجزئة عادةً صغيرة جداً لتغطية الرسوم بعد التنفيذ، أو موجودة لأن زمن الاستجابة للسحب/التحويل يجعلها غير قابلة للمراجحة. تشرح بقية هذه الصفحة الأنواع الأربعة الشائعة وأين لا يزال بإمكان قطاع التجزئة الكسب. ## 1. المراجحة المكانية (بين البورصات) الشكل الأبسط. نفس الأصل، منصات مختلفة. - الاكتشاف: سعر شراء BTC/USDT في البورصة A أعلى من سعر بيع BTC/USDT في البورصة B. - التنفيذ: شراء من B بسعر البيع، بيع في A بسعر الشراء. - التسوية: أنت محايد في التعرض لـBTC لكنك تحتاج إلى إعادة موازنة المخزون بين المنصات. الساق الخفية هي **إعادة موازنة المخزون**. للشراء في B تحتاج USDT في B؛ للبيع في A تحتاج BTC في A. تعتمد الدورة المربحة لا على الفارق فقط، بل على توفر المخزون اللازم لتكرار الصفقة في المكان المطلوب. نموذجان موجودان: - **كلا الجانبين ممولان مسبقاً.** يحتفظ المشغل بمخزون متوازن في كلا البورصتين، دون تحريك أموال خلال الصفقة. سريع، لكن رأس المال يتضاعف (النصف في كل منصة). - **التحويل عند الطلب.** يُحوِّل المشغل الأصل المُشترى من B إلى A لاستعادة المخزون. بطيء (دقائق إلى ساعات للتحويلات المشفرة) وحساس للسعر خلال نافذة التحويل. معظم إعدادات المراجحة المكانية المربحة تستخدم كلا الجانبين ممولاً مسبقاً مع إعادة موازنة صغيرة ومتكررة عند نفاد أحد الجانبين. حدود السحب ورسوم التحويل تصبح عوامل أولية الأهمية. ## 2. المراجحة المثلثية (داخل البورصة) ثلاثة أزواج، منصة واحدة. مثال في بورصة تُدرج BTC/USDT وETH/USDT وETH/BTC: - ابدأ بـ1000 USDT. - الساق 1: شراء BTC بـUSDT بالسعر الحالي لـBTC/USDT. - الساق 2: شراء ETH بـBTC بالسعر الحالي لـETH/BTC. - الساق 3: بيع ETH مقابل USDT بالسعر الحالي لـETH/USDT. - النتيجة: أكثر من 1000 USDT إذا كانت الأسعار الثلاثة غير متسقة. هذا يلغي تماماً مخاطر التحويل بين البورصات — كل شيء يجري داخل حساب واحد — لكن الفوارق أضيق لأن صانعي السوق في البورصة ذاتها يغلقونها باستمرار. المراجحة المثلثية هي في المقام الأول انضباط زمن الاستجابة وهيكل الرسوم: منصات رسوم صانع السوق تتيح نشر الساقين كأوامر محددة وكسب الخصم، مما يحول فارقاً شبه صفري إلى صفقة إيجابية. ## 3. مراجحة معدل التمويل (العقود الدائمة) تمتلك عقود العملات المشفرة الدائمة **معدل تمويل** يُحوِّل القيمة دورياً بين المراكز الطويلة والقصيرة للإبقاء على العقد الدائم مثبتاً بالسعر الفوري. عندما يكون التمويل إيجابياً، يدفع الشراطون للبائعين على المكشوف؛ عندما يكون سلبياً، يدفع البائعون على المكشوف للشراطين. الصفقة: - شراء BTC الفوري في البورصة A. - بيع عقد BTC الدائم على المكشوف في البورصة A (أو B) بالحجم ذاته. - تحصيل مدفوعات التمويل عندما يدفع السوق للبائعين على المكشوف أكثر مما يدفع للشراطين، أو العكس. أنت محايد في سعر BTC وتجني التمويل. يعمل هذا حتى: - يتغير اتجاه التمويل ويأكل العائد. - يُكلَّف جانب الشراء الفوري احتجازه في البورصة (مساهمات صندوق التأمين، معدلات الاقتراض). - يُصفَّى هامش العقد الدائم في تحرك سريع على أحد الجانبين، رغم أن المركز الفوري يعوض الخسارة — ميكانيكية التصفية لا تعرف التحوط في بورصة أخرى. مراجحة التمويل عبر البورصات (فوري في بورصة، دائم في أخرى) تضيف طبقة من مخاطر التحويل؛ مراجحة التمويل في بورصة واحدة تلغي تلك الطبقة بتكلفة تركيز المخزون. ## 4. المراجحة الإحصائية (أزواج، سلال) أصلان أو أكثر يتحركان تاريخياً معاً. عندما يتسع الفارق بينهما فوق المعايير التاريخية، البيع على المكشوف للساق الغالية والشراء للساق الرخيصة. الإغلاق عند ارتداد الفارق. ليست مراجحة بالمعنى الصارم (قد تكون الصفقة خاطئة)، لكنها تُسمى مراجحة في الصناعة لأن الأطروحة هي "الارتداد الإحصائي نحو المتوسط" لا "رؤية اتجاهية". يتطلب هذا بنية تحتية بحثية أكبر من الأنواع الثلاثة الأخرى — اختبارات التكامل المشترك، النوافذ المتحركة، مرشحات الأنظمة — وهو عموماً لعبة صناديق كمية، لا قطاع التجزئة. ## ميزانيات زمن الاستجابة الواقعية الصفقة المربحة في المراجحة عادةً لها نافذة زمنية من ميلي ثانية إلى ثوانٍ قليلة قبل أن يُغلقها شخص آخر. سلسلة زمن الاستجابة لقطاع التجزئة: | القفزة | زمن الاستجابة النموذجي | |------------------------------------|----------------------------------| | بيانات السوق: البورصة → VPS | 20–150 ms (REST)، 5–30 ms (WS) | | الاكتشاف + القرار | 1–20 ms | | إرسال الأمر: VPS → البورصة | 20–150 ms | | تحديث دفتر أوامر البورصة | 5–50 ms | دورة قطاع التجزئة الكاملة هي إذاً 50–400 ms في أفضل الأحوال. أي فارق استمر طويلاً كان ضيقاً أصلاً. مكاتب المراجحة الاحترافية تُخفضه إلى 1–5 ms عبر التضمين والاتصالات المباشرة مع صانعي السوق — وهم من يأخذون الفوارق السميكة أولاً. المتخصصات الميسورة لقطاع التجزئة تميل إلى أن تكون: - **بورصات المستوى الثاني** حيث المكاتب الاحترافية أقل حضوراً. - **الفوارق الطويلة الأمد** المدفوعة بقيود الإيداع/السحب (مثلاً خلال صيانة البورصة). - **مراجحة معدل التمويل** في العقود الدائمة، التي تتعلق بالعائد على مدى أيام لا ميلي ثانية. - **الأزواج الغريبة** والرموز المُدرجة حيث السيولة ضيقة لكن المنافسة أيضاً ضيقة. ## ركن المخاطر تُسوَّق المراجحة على أنها "خالية من المخاطر"، وهذا خاطئ بأي تعريف للمخاطر: - **مخاطر التنفيذ.** تنفذ ساق واحدة والأخرى لا. الآن لديك تعرض اتجاهي لم تقصده. - **مخاطر التحويل.** يمكن أن تتعطل التحويلات بين البورصات. تتغير الفوارق خلال العطل؛ ينتهي المخزون في البورصة الخاطئة. - **مخاطر الطرف المقابل.** تتعطل بورصة، أو تُغلق السحوبات، أو تُجمد الحساب. كل رأس مال المراجحة لديك في تلك البورصة محجوز. هذا هو المصدر الأكبر للخسارة في تاريخ مراجحة التجزئة للعملات المشفرة في 2022–2023. - **عدم التماثل في التصفية.** تُصفَّى ساق العقد الدائم في تحرك سريع رغم أن التحوط الفوري لم يتغير؛ تُحقق خسارة العقد الدائم، ولا تتحقق مكسبة الفوري. - **مخاطر API.** يُسرق مفتاح API؛ تُؤخذ الأموال في حساب البورصة عبر صلاحيات التداول (لا حاجة للسحب — المهاجم يمكنه التداول المتقاطع ضدك). راجع exchange-api-key-security. هذه المخاطر موجودة في القاع سواء أجريت اختباراً خلفياً أم لا؛ backtesting-explained لا تلتقط أياً منها. حدود المركز في risk-management-automated-trading هي الطريقة للتحكم فيها. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — موقع المراجحة في التصنيف. - exchange-api-key-security — سطح الهجوم "التداول بدون سحب" الأكثر أهمية هنا. - risk-management-automated-trading — حدود تخصيص رأس المال. - backtesting-explained — لماذا تُخفي اختبارات المراجحة الخلفية سيناريوهات مخاطر الطرف المقابل التي تُنتج أكبر الخسائر الفعلية. ### ar/kb/backtesting-explained.md Source: https://pulsar.ink/ar/kb/backtesting-explained.html # شرح الاختبار الخلفي **الاختبار الخلفي** هو محاكاة استراتيجية على بيانات تاريخية. الهدف هو تقرير ما إذا كانت الاستراتيجية تمتلك ميزة كافية تستحق التشغيل الحي. ناتج الاختبار الخلفي هو منحنى PnL، وملف التراجع، وإحصاءات الصفقات — يُقرر المشغل بناءً عليها النشر أو إعادة الضبط أو الاستبعاد. المشكلة في الاختبارات الخلفية ليست أنها تكذب. بل أنها تحكي نوعاً محدداً جداً من الحقيقة — "كيف كانت ستؤدي الاستراتيجية في **هذا** التاريخ مع **هذه** الافتراضات" — والمشغلون يُفسّرون هذه الحقيقة باستمرار على أنها توقع. ## ما يُخبرك به الاختبار الخلفي الصادق | المقياس | ما يخبرك به | ما لا يخبرك به | |-------------------------------|------------------------------------------------|---------------------------------------------| | العائد الإجمالي | PnL التراكمي خلال العينة | مدى تذبذب المسار | | نسبة Sharpe | العائد لكل وحدة تذبذب | مخاطر الذيل؛ التذبذب الهبوطي مقابل الصاعد | | الحد الأقصى للتراجع | أسوأ قمة إلى قاع في العينة | التراجع الممكن خارج العينة | | معدل الانتصار | نسبة الصفقات المربحة | توزيع حجم المكاسب والخسائر | | عامل الربح | مجموع(المكاسب) / مجموع(الخسائر) | استقرار هذه النسبة عبر الزمن | | وقت التعرض | نسبة الوقت مع رأس مال مُشتغل | تكلفة الفرصة لرأس المال الخامل | | عدد الصفقات | حجم عينة النتائج | ما إذا كانت كل التنفيذات واقعية | | محاسبة الإزلاق + العمولات | الربحية بعد التكاليف | عمق الدفتر الفعلي عند حجم الأمر | إذا لم يُبلّغ اختبار خلفي عن كل هذا، فهو إعلان تجاري لا اختبار خلفي. ## التحيزات الأربعة التي تُدمر اختبارات التجزئة الخلفية ### 1. تحيز look-ahead تستخدم الاستراتيجية بيانات لم تكن متاحة في وقت القرار. الحالة الكلاسيكية هي حساب مؤشر على إغلاق الشمعة الحالية ثم التداول داخل نفس الشمعة. شائع أيضاً: إعادة التوازن مقابل كون اخترته بمعرفة أي الرموز نجت حتى اليوم (ومن هنا "تحيز البقاء"). التصحيح: القرارات في الزمن `t` يجب أن تستخدم فقط البيانات المتاحة في `t`. طبّق ذلك بإزاحة جميع الإشارات شمعة واحدة على الأقل والتداول عند افتتاح الشمعة **التالية**، لا عند إغلاق الشمعة الحالية. ### 2. تحيز البقاء الكون الذي تختبره هو الكون الموجود **اليوم**. كل رمز أُلغي من القائمة، وكل بورصة ماتت، وكل بروتوكول فشل — غائب. استراتيجية الارتداد للمتوسط التي "تنجح" في كون اليوم كانت ستُدمَّر بالكون الموجود قبل خمس سنوات، لأن الخاسرين اختفوا. التصحيح: اختبر مقابل **كون في لحظة زمنية محددة** — مجموعة الأصول القابلة للتداول في كل تاريخ — وهو مُكلف التجميع في العملات المشفرة وشبه مستحيل للرموز ذات القيم الطويلة. أفضل تصحيح تالٍ هو تحديد نطاق الاختبار بأعلى N أصول من حيث السيولة، الاعتراف بالتحيز، والتحجيم وفقاً لذلك. ### 3. تحيز فترة العينة نافذة الاختبار الخلفي هي مقطع واحد من تاريخ السوق، والمقطع الذي تختاره يدفع النتيجة أكثر من الاستراتيجية. الشبكة على BTC/USDT من 2023-01 إلى 2024-01 تبدو مثالية (نطاق جانبي). نفس الشبكة من 2024-02 إلى 2025-04 تبدو سيئة (اتجاهية). لا نافذة خاطئة؛ كلتاهما ناقصة. التصحيح: أبلغ عن النتائج عبر **نوافذ خارج العينة** متعددة، بما في ذلك دورة كاملة صاعدة-هابطة-صاعدة. أبلغ عن التوزيع، لا الرقم المفرد. ### 4. نمذجة إزلاق غير كافية يُنفِّذ الاختبار الخلفي بالسعر الوسط التاريخي. تُنفِّذ الأسواق الحية مقابل الفارق السعري، وأحياناً خارجه عندما يكون الدفتر ضيقاً أو التحرك سريعاً. بالنسبة لبوتات الشبكة التي تُنفِّذ مئات الصفقات يومياً، يتراكم خطأ إزلاق بمقدار 5 نقاط أساس ليُنتج رأس مال نهائي مختلفاً جداً. التصحيح: نمذجة **تنفيذات واقعية**: - أوامر التنفيذ الفوري بأسوأ سعر مرئي للحجم المطلوب عند تلك اللحظة الزمنية. - أوامر صانع السوق تُنفَّذ فقط إذا تداول السعر **خلال** المستوى المُعلن، لا مجرد لمسه. - خلال شمعات التذبذب العالي، وسّع نموذج الفارق السعري؛ خلال ساعات السيولة المنخفضة، حدّ حجم الأمر إلى نسبة واقعية من حجم الشمعة. لا يُصيب أي محرك اختبار خلفي عام كل هذا. المنهج العملي هو تشغيل الاختبار الخلفي، ثم خصم النتيجة — 20–40% عائد متوقع أقل، 30–50% تراجع أعلى — للحصول على شيء أقرب لما ستُنتجه الاستراتيجية الحية فعلياً. ## التحقق من صحة walk-forward البديل الصادق لـ"التدريب على كل التاريخ والادعاء بأنه يعمل" هو **التحقق من الصحة walk-forward**: 1. اختر نافذة داخل العينة (مثلاً 2021-01 إلى 2022-01) واضبط الاستراتيجية عليها. 2. اختر نافذة خارج العينة (2022-01 إلى 2022-04) وشغّل الاستراتيجية المضبوطة عليها **بدون ضبط إضافي**. 3. أزح النافذة للأمام (2021-04 إلى 2022-04 داخل العينة، 2022-04 إلى 2022-07 خارج العينة) وكرر. 4. أجمع كل قيم PnL خارج العينة. هذا التجميع هو ما يُتوقع أن تُنتجه الاستراتيجية. يُخفض التحقق من الصحة walk-forward العوائد المُبلَّغ عنها بشكل روتيني بنسبة 30–60% مقارنةً بضبط نافذة واحدة. المشغلون الذين لا يُشغّلون walk-forward يحصلون على رقم مُفرط الضبط. ## فخاخ خاصة بالعملات المشفرة - **انتقال البورصة.** الاختبار الخلفي لـBTC/USDT في البورصة A منذ 2019 قد يجمع بيانات بورصة لم تعد موجودة. السيولة والفوارق السعرية غير قابلة للنقل. - **فك ارتباط العملة المستقرة.** استراتيجية تستخدم USDT كعملة تسعير تفترض أن USDT = 1 دولار في كل شمعة. هذا كان خاطئاً خلال نوافذ ممتدة (مايو 2022، مارس 2023) والاختبار الخلفي عادةً لا يُصحح ذلك. - **تخفيف الرمز / الهبوط الجوي.** تغييرات في مخزون الرموز تُغير صامتاً "السعر" خلال نوافذ طويلة. - **تغييرات جدول الرسوم.** تُغيّر البورصات رسوم صانع السوق/التنفيذ الفوري ربع سنوياً. الاختبار الخلفي لعام 2020 باستخدام رسوم 2026 متفائل. - **أسس معدلات تمويل العقود الدائمة.** انخفضت معدلات التمويل منذ 2021 مع نضج السيولة؛ الاختبار الخلفي لمراجحة التمويل في 2018 ليس توقعاً لعام 2026. ## ملاحظات خاصة بكل استراتيجية - grid-trading-strategy — اختبارات الشبكة الخلفية على نطاق واحد دائماً تبدو مثالية. أعد الاختبار الخلفي لنفس الشبكة خلال السوق الهابطة في 2022 وانفجار الربع الأول من 2024؛ الأرقام مختلفة جداً. - dca-bot-strategy — اختبارات DCA الخلفية هي الأكثر صدقاً لكنها تعتمد على المسار وفق تاريخ البدء. حل متعدد تواريخ البدء هو الحل. - arbitrage-bots — تتجاهل الاختبارات الخلفية مخاطر الطرف المقابل وزمن استجابة التحويل، وهما المصدران الأكبر للخسارة في السوق الحي. - signal-trading-bots — الاختبار الخلفي لمزود الإشارات يعاني دائماً تقريباً من تحيز البقاء؛ أعد تشغيله مقابل سياسة التنفيذ الخاصة بالمشغل. الانضباط الأوسع مغطى في risk-management-automated-trading: لا قدر من دقة الاختبار الخلفي يلغي الحاجة إلى حدود في الحساب الحي، لأن المتغير الوحيد الذي لا يستطيع الاختبار الخلفي محاكاته هو المشغل. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — الفئة الأوسع. - risk-management-automated-trading — الحدود التي تُحدد الجانب السفلي لأي استراتيجية بصرف النظر عما قاله الاختبار الخلفي. ### ar/kb/copy-trading-explained.md Source: https://pulsar.ink/ar/kb/copy-trading-explained.html # شرح التداول بالنسخ **التداول بالنسخ** هو شكل من أشكال التداول الآلي (راجع what-is-automated-crypto-trading) حيث لا يتخذ بوت التابع قرارات تداول بنفسه. بدلاً من ذلك، **يعكس** صفقات قائد مختار — متداول بشري، أو صندوق كمي، أو بوت آخر — في حساب البورصة الخاص بالتابع، في زمن شبه حقيقي، عبر API. يمتلك التابع الأموال ومفتاح API؛ يمتلك القائد القرارات. المنصة هي القناة بينهما. ## حلقة المرآة 1. يُرسل القائد أمراً في حساب البورصة الخاص به. 2. تكتشف المنصة التنفيذ (عبر استطلاع API البورصة أو تغذية websocket). 3. تُطبّع المنصة التنفيذ إلى أمر بحجم التابع وفق نموذج التحجيم المُعلن من التابع. 4. ترسل المنصة أمر التابع مقابل مفتاح API الخاص بالتابع. 5. تُوفَّق المنصة — هل نُفِّذ أمر التابع كاملاً أم جزئياً أم لم يُنفَّذ أصلاً؟ — وتُسجل الانحراف في سجل PnL للتابع. كل خطوة تُدخل كمية صغيرة من **الإزلاق**: لا يحصل التابع على السعر ذاته الذي حصله القائد تماماً. مقدار الإزلاق المقبول هو أحد المعاملَين الرئيسيين من جانب التابع (الآخر هو التحجيم، أدناه). ## نماذج التحجيم قائد بحساب بقيمة مليون دولار يمكنه شراء 10 BTC في صفقة واحدة. إذا عكس تابع بحساب قيمته 5,000 دولار هذا بشكل ساذج، إما لا يستطيع التابع تحمل تكاليف الصفقة أو يُحرق حسابه في مركز واحد. ثلاثة نماذج تحجيم شائعة الاستخدام: ### 1. التناسبي (الاسمي) يتداول التابع `قيمة_صفقة_القائد × (رأس_مال_التابع / رأس_مال_القائد)`. بسيط وبديهي ويعمل جيداً مع اختلافات حجم الحساب. العيب: عندما يكون حساب القائد أكبر بكثير من حساب التابع، قد تُقرَّب المركز التناسبية للحد الأدنى القابل للتداول وتُحذف بصمت. ### 2. الاسمي الثابت يتداول التابع دائماً قيمة ثابتة بالدولار (مثلاً 100 دولار لكل صفقة منعكسة). بسيط، لكنه يفقد إشارة قناعة القائد — تُصبح "الرهان الكبير" و"الرهان الصغير" للقائد بالحجم ذاته في جانب التابع. ### 3. تعادل المخاطر يُحجّم التابع المركز بالمسافة المُعلنة لوقف الخسارة من القائد والحد الأقصى للمخاطرة لكل صفقة من التابع. يتوافق مع ممارسة المكاتب الاحترافية، أصعب في الضبط الصحيح، يتطلب عادةً أن يُنشر القائد وقف خسارة إلى جانب كل دخول. تدعم Pulsar.INK الأنواع الثلاثة. الاختيار للتابع ويجب تسجيله في سياسة risk-management-automated-trading للمشغل. ## ما يشترك فيه التداول بالنسخ مع التداول بالإشارات، وما لا يشترك التداول بالنسخ هو الأقرب إلى متابعة الإشارات (راجع signal-trading-bots). الفرق في مستوى الثقة: | الجانب | التداول بالنسخ | التداول بالإشارات | |-----------------------------|---------------------------------------------|--------------------------------------------------| | من يُصدر الصفقة؟ | قائد محدد، بهويته | مصدر إشارة (مؤشر، قناة، خوارزمية) | | حساسية لزمن الاستجابة؟ | نعم — يجب العكس بسرعة | نعم، لكن يعتمد على نوع الإشارة | | رؤية الخروج | مثل الدخول — عندما يخرج القائد | قد لا تُصدر الإشارة خروجاً صريحاً | | مخاطر تحيز البقاء | عالية (القادة الفاشلون غير مرئيين) | عالية (الإشارات الفاشلة غير مرئية) | | هل يمكن مراجعة المنطق؟ | فقط ما يُفصح عنه القائد | يعتمد — الإشارات القائمة على قواعد قابلة للمراجعة الكاملة | الفخ الرئيسي في التداول بالنسخ هو **تحيز البقاء**: يُظهر الترتيب في أي منصة الناجحين. القادة الذين أفلسوا اختفوا من القائمة. هذه هي الآلية ذاتها التي تجعل نتائج backtesting-explained تبدو أكثر إيجابية من النتائج الحية — وهذا هو سبب حاجة العناية الواجبة عند تأهيل التابع إلى تجاوز "الأعلى ترتيباً الأسبوع الماضي". ## ميزانية الإزلاق إذا نفّذ القائد بسعر 50,000 دولار ونفّذ التابع بسعر 50,030 دولار، فهذا إزلاق قدره 6 نقاط أساس (0.06%). تحافظ خط أنابيب مرآة جيد على متوسط إزلاق يقل عن 10 نقاط أساس للأزواج السائلة؛ يتدهور في الأزواج الضيقة، والتحركات المدفوعة بالأخبار، والاستراتيجيات عالية التردد التي ينفذها القائد بشكل أسرع مما يستطيع المرآة متابعته. تابع تكون ميزته المتوقعة لكل صفقة أقل من ميزانية إزلاق خط الأنابيب مضمون بالخسارة حسابياً، بصرف النظر عن مدى جودة القائد. لهذا يعمل التداول بالنسخ بشكل أفضل مع قادة منخفضي التردد وعالي القناعة بدلاً من القادة على نمط HFT. ## السطح الضريبي التداول بالنسخ لا يلغي الالتزام الضريبي للصفقات الفردية. كل تنفيذ منعكس في بورصة التابع هو حدث ضريبي في معظم الولايات القضائية، تماماً كما لو دخل التابع وخرج بنفسه. المنصة ليست الطرف الضريبي المقابل؛ البورصة هي. تابع يتداول مع قائد عالي التردد قد يتراكم آلاف الأحداث الضريبية سنوياً ويجب أن يميّز ميزانية لبرامج المحاسبة. ## أنماط الفشل الواجب مراقبتها - **اختراق حساب القائد.** إذا اختُرق حساب القائد، تنعكس الصفقات الضارة قبل أن يلاحظ أحد. الدفاع الوحيد للتابع هو حد على حجم الصفقة وحد إجمالي للتراجع اليومي — راجع risk-management-automated-trading. - **صلاحيات مفرطة لمفتاح API.** التداول بالنسخ لا يحتاج صلاحية السحب على مفتاح التابع؛ راجع exchange-api-key-security للقائمة الكاملة من الصلاحيات. - **تغير ظروف السوق.** قائد كان مربحاً في سوق ذي اتجاه قد يكون مخطئاً باستمرار في سوق متذبذب. يجب أن تكون علاقة النسخ محددة بوقت أو مشروطة بالأداء؛ إنها ليست ترتيباً "اضبط وانسَ". - **انقطاع المنصة أثناء خروج القائد.** إذا كان خط أنابيب المرآة معطوباً بينما القائد يُغلق مركزاً رابحاً، يظل التابع يحتفظ بالمركز مفتوحاً. سلوك التحويل الطارئ في Pulsar.INK هو تسوية المراكز المنسوخة المفتوحة إذا فقدت حلقة المرآة نبضاتها لفترة أطول من عتبة قابلة للضبط. هذا أأمن من ترك مركز "عالق" مفتوحاً، لكنه قرار غير هين من جانب التابع. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — الفئة الأوسع التي تنتمي إليها هذه الاستراتيجية. - signal-trading-bots — القريب غير المنسوخ. - risk-management-automated-trading — الحدود التي تُقيّد نطاق تأثير القائد. - exchange-api-key-security — لماذا تبقى صلاحية السحب معطلة على مفاتيح التابعين. - backtesting-explained — لماذا الترتيب ليس اختباراً خلفياً. ### ar/kb/dca-bot-strategy.md Source: https://pulsar.ink/ar/kb/dca-bot-strategy.html # استراتيجية بوت DCA **متوسط التكلفة بالدولار (DCA)** هو ممارسة شراء مبلغ ثابت بالدولار من أصل ما وفق جدول زمني ثابت — كأن تشتري 100 دولار من BTC كل يوم اثنين — بصرف النظر عن السعر الحالي. تقوم **بوت DCA** بذلك تلقائياً بإيقاع يُهيئه المستخدم، ويمكنها اختيارياً التوسع بشكل أكبر عند انخفاض السعر دون المتوسطات المتتبعة الأخيرة. تنتمي DCA إلى نفس عائلة الاستراتيجيات الآلية الأخرى (راجع what-is-automated-crypto-trading) لكنها الأبسط للفهم: القرار الوحيد الذي يبقى هو "هل لا أزال متفائلاً بشأن هذا الأصل على مدى أفق التراكم الخاص بي؟" ## DCA الكلاسيكي المعاملات: - **الأصل**: مثلاً BTC - **الإيقاع**: مثلاً أسبوعي، كل اثنين الساعة 12:00 UTC - **مبلغ الدولار لكل عملية شراء**: مثلاً 100 دولار - **الأفق**: مثلاً 24 شهراً يُنفَّذ البوت `cadence × horizon` عمليات شراء، واحدة لكل فترة. لا منطق خروج. الناتج هو مركز بتكلفة أساس تساوي المتوسط الحسابي لأسعار إغلاق الفترات. خاصيتان لـDCA الكلاسيكي تستحقان الاستيعاب: 1. **دائماً يكون أداؤه أدنى من عملية الشراء عند القمة المثالية أو القاع المثالي** — بالتعريف، لأن DCA يحسب المتوسط. إنها استراتيجية "الحالة المتوسطة". 2. **دائماً يتفوق على أسوأ حالة الشراء عند القمة** وغالباً يتفوق على البيع بذعر، لأن DCA يزيل كمون نقطة القرار حيث تتدخل العاطفة. بالأسلوب البسيط: أنت تتنازل عن الأداء الصاعد مقابل الاستمرارية. ## DCA الشرطي (متوسط القيمة / مارتينغال خفيف) DCA الزمني الصرف هو انضباط. يُضيف DCA الشرطي محفزاً سعرياً ويصبح أقرب إلى الاستراتيجية: - **شراء أساسي كل فترة** (DCA الكلاسيكي) - **شراء إضافي عندما يكون السعر X% أقل من المتوسط الأخير** - **تخطي الشراء عندما يكون السعر Y% أعلى من المتوسط الأخير** هذا يُميّل التراكم نحو الأدنى وبعيداً عن الأعلى، بتكلفة إدخال معاملات للضبط (X، Y، نافذة "المتوسط الأخير"). في الحدود القصوى يصبح مارتينغال — مضاعفة الرهان عند كل هبوط — وله أنماط فشل شهيرة عندما يكون الانخفاض هيكلياً لا مؤقتاً. تدعم بوت DCA في Pulsar.INK كلا المتغيرين؛ يختار المشغل ما إذا كان سيُضيف شروطاً فوق الجدول الأساسي. ## مشكلة الخروج DCA قوية في التراكم وصامتة بشأن الخروج. هذه ميزة لا عيب: أطروحة الاستراتيجية هي "أعتقد أن هذا الأصل سيكون أكثر قيمة عند أفق الاستثمار من تكلفة أساسه." عندما يصل المشغل إلى الأفق، يُقرر الخروج — DCA لا تُقرره عنه. ثلاثة أساليب خروج مستخدمة عملياً: | الأسلوب | متى يُستخدم | العيب | |-----------------|----------------------------------------------|--------------------------------------------| | الاحتفاظ / الحضانة الذاتية | أفق بعيد، لا حاجة للعملة الورقية | مخاطر ذيلية على البورصة أو الحضانة الذاتية | | DCA عكسي للخروج | عندما يريد المشغل خروجاً آلياً أيضاً | يحد من الأداء الصاعد عند الخروج | | محفز الربح | خروج كامل عندما يكون المركز X% فوق التكلفة الأساس | عتبة واحدة نادراً ما تناسب الدورة بأكملها | الإطار الصادق: إذا لم يكن لدى المشغل قاعدة خروج، فقد بنى DCA مركزاً متزايد القيمة بدون شرط نجاح معلن. هذه مشكلة نفسية، ليست مشكلة بوت. ## DCA مقابل الشبكة: أيهما في سوق متذبذب؟ تبدو DCA وgrid-trading-strategy متشابهتين للوهلة الأولى — كلتاهما تُنفَّذ عمليات شراء مجدولة وكلتاهما تعمل بشكل أفضل بدون اتجاهات قوية — لكن الرهانات الجوهرية تختلف: | السؤال | DCA | الشبكة | |--------------------------------------|--------------------------------|-------------------------------| | على ماذا أراهن؟ | ارتفاع على المدى البعيد | تذبذب قريب المدى | | هل أبيع داخل الفترة؟ | لا (ما لم يكن هناك خروج شرطي) | نعم، عند كل مستوى | | ماذا يحدث إذا انهار السعر؟ | أشتري المزيد بأسعار أدنى | تنكسر الشبكة، يجلس الكيس تحت | | ماذا يحدث إذا ارتفع السعر بشدة؟ | أحتفظ بمركز مرتفع القيمة | تبيع الشبكة كل شيء، لا دخول جديدة | | تعقيد الضبط | أدنى حد | معتدل إلى عالٍ | في سوق متذبذب، تتراكم DCA ببطء مركزاً أساسياً، وتحصد الشبكة ربح التذبذب فوقه. يمكن أن يكونا مكمِّلين لا منافسين. ## الاختبارات الخلفية وDCA الاختبار الخلفي لـDCA هو أصدق اختبار خلفي يمكنك إجراؤه — فالمعاملات قليلة جداً لدرجة أن الإفراط في الضبط يكاد يكون مستحيلاً — لكنه لا يزال مضللاً بطريقة واحدة محددة: إنه يعتمد على المسار وفق نافذة العينة. DCA لـBTC يبدأ من 2020-01-01 يبدو رائعاً حتى 2021-11. نفس DCA يبدأ من 2021-11-01 يبدو سيئاً حتى 2022-11. راجع backtesting-explained للفخ العام؛ بالنسبة لـDCA تحديداً، التخفيف هو الاختبار الخلفي بتواريخ بدء متعددة عبر دورة كاملة والإبلاغ عن التوزيع، لا رقم "من هنا حتى الآن" المفرد. ## ملاحظات المخاطر DCA لا تُحول أصلاً سيئاً إلى جيد. إذا فشلت أطروحة الأصل — أُلغي الرمز من القائمة، أو استُغل البروتوكول، أو اختفى فريق المشروع — فـDCA اشترت طوال الهبوط. الحد في risk-management-automated-trading لـDCA عادةً ما يكون **حداً إجمالياً اسمياً** لكل أصل بدلاً من كل صفقة، لأن حجم كل صفقة صغير بالأساس. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — موقع DCA في التصنيف الأوسع. - grid-trading-strategy — القريبة المُتخصصة في حصاد التذبذب. - risk-management-automated-trading — الحد الوحيد المهم لـDCA. - backtesting-explained — فخ الاعتماد على المسار. ### ar/kb/exchange-api-key-security.md Source: https://pulsar.ink/ar/kb/exchange-api-key-security.html # أمان مفاتيح API للبورصة **مفتاح API** هو زوج من بيانات الاعتماد (مفتاح + سر) يُصدره بورصة ما ليسمح لبرنامج خارجي بالتصرف في حساب البورصة الخاص بالمالك. في سياق التداول الآلي (راجع what-is-automated-crypto-trading)، تمتلك المنصة المفتاح وتستخدمه لإرسال أوامر نيابةً عن المشغل. المفتاح هو الكيان الأكثر عرضة للإساءة في كامل المنظومة. لا تغادر الأموال البورصة أبداً لتدخل المنصة، لكن المفتاح يمكنه إلحاق ضرر حقيقي إذا كان نطاق صلاحياته خاطئاً. صحة النطاق هي الخطوة الأولى غير القابلة للتفاوض في كل تكامل بورصة. ## القاعدة الوحيدة **يجب عدم تفعيل صلاحية السحب على مفتاح API.** هذه القاعدة مطلقة. كل بورصة رئيسية تُقسّم الصلاحيات إلى ثلاث فئات على الأقل — قراءة، تداول، سحب — والمنصة تحتاج فقط إلى القراءة والتداول. لا يوجد سبب مشروع لامتلاك بوت تداول لصلاحية السحب؛ المنصة لا تحتاج إلى نقل أموال خارج البورصة لأداء عملها. عندما تكون صلاحية السحب مُعطَّلة، أسوأ ما يمكن لمفتاح مخترق فعله هو التداول ضد الحساب (الخسارة أمام بوت صانع سوق مرتب مسبقاً هو الهجوم الكلاسيكي). هذا ضرر حقيقي، لكن أصل الحساب لا يزال في البورصة ويمكن استرداده عبر دعم البورصة ونوافذ التصفية المُفعَّلة بحد المعدل. عندما تكون صلاحية السحب مُفعَّلة، يمكن للمهاجم استنزاف الحساب في معاملة واحدة. الخسارة لا رجعة فيها. ## الحد الأدنى لنطاق الصلاحيات الأسماء الدقيقة تختلف من بورصة إلى أخرى، لكن كل منصة يجب أن تطلب هذه الفئات فقط: | الصلاحية | الاسم النموذجي على المنصات المختلفة | مطلوب؟ | |----------------------------------|------------------------------------------------------|----------------------------| | قراءة أرصدة الحساب | "Read Info" / "Account" / "Query" | نعم | | قراءة سجل الأوامر | "Read Orders" / "History" | نعم | | تقديم وإلغاء الأوامر | "Trade" / "Spot Trading" / "Margin Trading" | نعم | | سحب الأموال | "Withdraw" / "Transfer" | **لا** | | تفعيل الهامش | "Margin" / "Futures" | فقط إذا احتاجتها الاستراتيجية | | تفعيل العقود الآجلة | "Derivatives" / "Perpetual" | فقط إذا احتاجتها الاستراتيجية | | التحويل الداخلي للحساب الفرعي | "Universal Transfer" | **لا** (في الغالب) | يجب على المشغل التحقق من مربعات الصلاحيات في واجهة مستخدم البورصة مقابل هذه القائمة في كل مرة يُنشئ فيها مفتاحاً أو يُدوّره. ## قائمة IP المسموح بها تسمح معظم البورصات الرئيسية للمشغل بربط مفتاح API بـ**قائمة IP ثابتة مسموح بها**. يُرفض الأمر المُرسَل من IP خارج القائمة. Pulsar.INK، كمعظم المنصات، تُنشر IPs الصادرة لخوادم التداول حتى يتمكن المشغلون من وضع تلك IPs بالضبط في القائمة المسموح بها. إذا كانت قائمة المشغل المسموح بها فارغة `[]`، فالمفتاح قابل للاستخدام من أي مكان والأمان الفعلي للاعتمادات يكون نصف ما ينبغي أن يكون. المقايضات: - **قائمة مسموح بها ثابتة + المشغل يلصق المفتاح.** أمان أفضل؛ يجب على المنصة نشر وصيانة IPs الصادرة؛ يعيد المشغل لصق المفتاح عند تغيير القائمة. - **بدون قائمة مسموح بها.** سهل الإعداد؛ نطاق تأثير سرقة المفتاح هو الإنترنت بأكمله؛ تجنب تماماً ما لم تكن البورصة لا تدعم القوائم المسموح بها. لاستراتيجيات المراجحة التي تعمل على منصات متعددة، راجع arbitrage-bots — تدفق التحويل بين المنصات هو المكان الذي يُغري أحياناً المشغلين بتفعيل السحب "للراحة". لا تفعل ذلك. استخدم التحويلات اليدوية أو حساباً فرعياً داخلياً إذا احتجت إعادة التوازن بين المنصات. ## جدول التدوير يجب تدوير مفاتيح API بجدول منتظم. الجدول الزمني الأدنى المعقول: - **كل 90 يوماً** للمفاتيح الموجودة في حسابات التداول فقط. - **فوراً** إذا حدث أي من هذه الأحداث: - يشك المشغل في تسرب المفتاح. - غيّر المشغل حساب Telegram (راجع telegram-native-trading-ux لمعرفة سبب أهمية ذلك). - أفصحت المنصة عن حادثة أمنية. - أبلغت البورصة عن نشاط غير معتاد. التدوير عملية منخفضة الاحتكاك في Pulsar.INK: مفتاح جديد صادر من البورصة، يُلصق في واجهة Telegram، المفتاح القديم مُلغى في البورصة. لا تحتفظ المنصة بالمفاتيح القديمة في ذاكرة التخزين المؤقت. ## معالجة السر في جانب المنصة المفتاح والسر للمشغل مُشفّران في حالة الراحة على المنصة ويستخدمهما فقط خدمة إرسال الأوامر المحددة. لا يُكتبان أبداً في السجلات، ولا يُعرضان في رسائل واجهة المستخدم بعد الإدخال، ولا يُرسلان إلى أطراف ثالثة. من منظور المشغل، ضوابط الحماية هي: 1. **لا تنسخ السر في أي محادثة أو تذكرة أو بريد إلكتروني** — بما في ذلك دعم المنصة. الدعم لا يطلب السر أبداً. 2. **لا تلصق السر في نموذج يُقدَّم عبر HTTP** (بدلاً من HTTPS). تطبيق Telegram Mini App هو HTTPS فقط بحكم التصميم. 3. **ألغِ المفتاح** إذا نُسخ ولصق في أي شيء غير شاشة إدخال مفتاح المنصة. تكلفة التدوير منخفضة؛ تكلفة مفتاح مسرَّب مرتفعة جداً. ## ماذا تفعل إذا اختُرق مفتاح الاختراق ليس فقط "فقدت المفتاح". يشمل أيضاً: - جهاز يحتوي على المفتاح فُقد أو سُرق. - مدير كلمات مرور يحتوي على المفتاح وصله شخص آخر. - المفتاح يظهر في أي سجل أو رسالة أو ملف مشترك مع طرف آخر. الخطوات: 1. **إلغاء المفتاح في البورصة** (أسرع مسار — عادةً نقرة واحدة). 2. **إيقاف مؤقت لجميع الاستراتيجيات في Pulsar.INK** (مفتاح الطوارئ في Telegram). 3. **مراجعة الأوامر المفتوحة والمراكز** للدخولات التي لم يضعها المشغل. 4. **التواصل مع دعم البورصة** إذا كانت هناك دليل على صفقات غير مصرح بها. 5. **تدوير أي بيانات اعتماد مشتركة** (كلمة مرور Telegram، رقم PIN على مستوى الجهاز) إذا لم تُعرف بعد طريقة الاختراق. 6. **إصدار مفتاح جديد** بقائمة IP مسموح بها جديدة؛ إعادة تنشيط الاستراتيجيات فقط بعد التحقق من احتواء الاختراق السابق. إطار risk-management-automated-trading ينطبق هنا أيضاً: حد الخسارة اليومية على مستوى الحساب عادةً ما يُفعَّل قبل أن يتمكن المهاجم من تداول الحساب حتى الإفلاس. هذا الحد هو خط الدفاع الأخير عندما تفشل جميع الضوابط الأخرى. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — السياق الأوسع. - telegram-native-trading-ux — النصف المتعلق بـTelegram من محيط الأمان. - risk-management-automated-trading — حدود الخسارة التي تصمد أمام اختراق بيانات الاعتماد. - arbitrage-bots — الاستراتيجية الأكثر إغراءً للمشغلين لتهيئة المفاتيح بشكل خاطئ. ### ar/kb/grid-trading-strategy.md Source: https://pulsar.ink/ar/kb/grid-trading-strategy.html # استراتيجية تداول الشبكة **تداول الشبكة** يضع سلسلة من أوامر الشراء والبيع عند مستويات سعرية محسوبة مسبقاً عبر نطاق ما، ويستفيد من تذبذب السوق صعوداً وهبوطاً بين تلك المستويات. على عكس الاستراتيجيات الاتجاهية، لا تتطلب الشبكة **أي رأي** بشأن وجهة السعر — بل فقط بشأن النطاق الذي ستبقى فيه. هذا يجعل الشبكات الاستراتيجية الآلية الأكثر شيوعاً "بدون رأي" (راجع what-is-automated-crypto-trading) للأسواق المتذبذبة أو المتقطعة. ## الآلية الأساسية لنفترض أن BTC/USDT يتداول عند 50,000 دولار وتتوقع أن يتذبذب بين 45,000 و55,000 دولار للأسابيع القادمة. تُحدد: - **النطاق**: 45,000 إلى 55,000 دولار - **حجم الشبكة**: 10 مستويات (خطوة = 1,000 دولار) - **حجم الأمر لكل مستوى**: 0.01 BTC يضع البوت: - أوامر شراء عند 49,000، 48,000، 47,000، 46,000، 45,000 دولار - أوامر بيع عند 51,000، 52,000، 53,000، 54,000، 55,000 دولار في كل مرة ينخفض السعر خلال مستوى، يُنفَّذ أمر الشراء المقابل — ويضع البوت فوراً أمر بيع جديداً بخطوة واحدة أعلى. في كل مرة يرتفع السعر خلال مستوى، يُنفَّذ البيع ويُوضع أمر شراء جديد بخطوة أدنى. كل رحلة ذهاب وعودة مكتملة (شراء بـ49,000، بيع بـ50,000) هي ربح محجوز: 1,000 × 0.01 = 10 دولارات، ناقص الرسوم. ## نظرية النطاق تأتي ربحية الشبكة بالكامل من التذبذب داخل النطاق المُعلن. معاملان يتفاعلان: | المعامل | التأثير على الربح لكل رحلة ذهاب وعودة | التأثير على عدد رحلات الذهاب والعودة | |----------------|----------------------------------------------|-----------------------------------------------| | نطاق أوسع | لا تغيير (ربح خطوة واحدة ثابت) | تنفيذات أقل خلال التذبذب الاعتيادي | | شبكة أكثر كثافة | ربح أصغر لكل رحلة ذهاب وعودة | تنفيذات أكثر خلال التذبذب الاعتيادي | | تذبذب أعلى | لا تغيير | تنفيذات أكثر في نافزة زمنية معطاة | الميزة التقريبية للشبكة هي: ``` expected_profit ≈ (levels_crossed_per_day) × (profit_per_level - fees) ``` لذا فالمشغل يراهن ضمنياً على مجموعة من: (ثبات النطاق) × (تذبذب كافٍ داخل النطاق) × (رسوم البورصة أصغر من حجم الخطوة). ## المقايضة في كثافة الشبكة إذا كانت الشبكة متفرقة جداً، يبقى البوت خاملاً خلال التحركات الصغيرة. وإذا كانت كثيفة جداً، ينخفض ربح كل رحلة ذهاب وعودة دون مستوى الرسوم وتنزف الاستراتيجية ببطء. قاعدة الإبهام الشائعة: يجب أن يكون حجم الخطوة على الأقل **4 أضعاف رسوم التنفيذ الفوري أحادية الاتجاه** لمنح رحلة الذهاب والعودة (تنفيذان فوريان) وسادة رسوم ضعفين. بالنسبة لرسوم تنفيذ فوري بنسبة 0.1%، ذلك خطوة لا تقل عن 0.4%. دون ذلك، الشبكة تعمل لصالح البورصة وليس المشغل. ## رياضيات التراجع التي لا يذكرها أحد على تويتر تبدو الشبكة جميلة **طالما يبقى السعر في النطاق**. عندما يخرج السعر من النطاق، تحمل الشبكة فجأة مركزاً مائلاً: - إذا اخترق السعر الحد الأدنى، نُفِّذت كل أوامر الشراء ولم يُقابلها أي بيع. يحمل البوت الحد الأقصى من المركز الطويل المقصود عند أسوأ متوسط سعر. - إذا اخترق السعر الحد الأعلى، نُفِّذت كل أوامر البيع (إذا كانت الاستراتيجية تبيع على المكشوف) أو توقفت الاستراتيجية عن التراكم (إذا كانت تشتري فقط). في كلتا الحالتين، توقفت عن التراكم. الحد الأقصى للمركز عند اختراق النطاق: ``` max_bag = order_size × number_of_buy_levels unrealised_loss_at_break = sum over filled buys of (fill_price - current_price) × order_size ``` مثال ملموس: نطاق 45k–55k دولار، 10 مستويات شراء بـ0.01 BTC. انهار السعر إلى 30k دولار. يحتفظ البوت بـ0.05 BTC (المستويات الخمسة السفلية كلها نُفِّذت)، اشترى بمتوسط حوالي 47k دولار. الخسارة غير المحققة: نحو 0.05 × 17,000 = 850 دولار على رأس مال مُنشر قدره 2,350 دولار، أو تراجع بنسبة 36%. شبكة كانت تكسب 10 دولارات لكل رحلة ذهاب وعودة بهدوء، تخلت للتو عن ما يعادل أرباح 85 رحلة ذهاب وعودة في اختراق واحد. لهذا تكون الشبكات لا تنفصل عن risk-management-automated-trading: - **وقف الخسارة تحت الحد الأدنى** — اقبل فشل الشبكة وأغلق المركز، بدلاً من متوسط الهبوط إلى الأبد. - **حد المركز** — رأس المال الإجمالي المُنشر من الشبكة محدود، وليس نسبة ثابتة من حقوق الملكية؛ اختراق شبكة واحدة لا يجب أن يُدمر الحساب. - **جدول مراجعة النطاق** — أعد تسعير النطاق أسبوعياً أو عند أي حدث تحول في النظام، وليس "عند الاختراق". ## أنواع الشبكات | النوع | الوصف | الأنسب لـ | |--------------|----------------------------------------------------------------|-----------------------------------| | حسابي | تباعد متساوٍ بالدولار بين المستويات | أسواق مستقرة، تذبذب معتدل | | هندسي | تباعد متساوٍ بالنسبة المئوية بين المستويات | أصول ذات تذبذب أعلى | | لا نهائي | لا حد أعلى؛ يستمر في إضافة مستويات بيع مع ارتفاع السعر | المضاربون على الاتجاه الصاعد القوي | | عكسي | يبيع على المكشوف بدلاً من الشراء؛ يستفيد من النطاق في نظام هبوطي | المشغلون ذوو الخبرة فقط | | ديناميكي | يُعاد حساب النطاق من ATR الأخير أو نطاقات Bollinger | التكيف مع تحولات النظام | تدعم Pulsar.INK الشبكات الحسابية والهندسية والديناميكية. ## أوقات فشل الشبكات ثلاثة أنظمة تقتل الشبكات بترتيب تصاعدي من حيث الخطورة: 1. **تذبذب منخفض / تقطع ضيق.** التنفيذات نادرة جداً؛ تكلفة الفرصة للرأس المال المُنشر تتجاوز عوائد الشبكة. حل المشغل هو تقليل حجم الشبكة أو إعادة توجيه رأس المال إلى dca-bot-strategy / استراتيجيات أخرى. 2. **سوق ذو اتجاه.** يسير السعر خارج النطاق في اتجاه واحد؛ تصبح الشبكة أحادية الجانب وتتوقف عن التراكم. حل المشغل هو الاكتشاف المبكر (مرشح الاتجاه فوق الشبكة) وإعادة تحديد النطاق. 3. **انهيار مفاجئ / حدث إخباري.** يحدث اختراق النطاق أسرع مما يمكن للمشغل الاستجابة له، ويُنفَّذ وقف الخسارة (إن وُجد) عند سعر أسوأ بكثير من مستواه المُعلن بسبب الفجوة. تخفيف المشغل هو حد المركز الصارم: حتى بعد الفجوة، الخسارة الإجمالية بالدولار محدودة بـ`order_size × buy_levels × (range_width + gap_slippage)`. كثيراً ما تُقلل الاختبارات الخلفية (راجع backtesting-explained) من شأن أنماط الفشل الثلاثة لأنها تستخدم بيانات إيقاع مثالية، وليس دفاتر الأوامر الضيقة التي تُوجد خلال الانهيارات الحية. الاختبار الخلفي "المربح 100%" بلا تراجع يجب قراءته على أنه "لم تتعرض هذه الاستراتيجية للضغط قط"، وليس "هذه الاستراتيجية آمنة". ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — مكانة الشبكات في تصنيف الاستراتيجيات الأوسع. - dca-bot-strategy — القريب المُركّز على التراكم من الشبكات. - risk-management-automated-trading — إلزامي للشبكات. - backtesting-explained — لماذا تكون اختبارات الشبكة الخلفية الأكثر تضليلاً. ### ar/kb/risk-management-automated-trading.md Source: https://pulsar.ink/ar/kb/risk-management-automated-trading.html # إدارة المخاطر في التداول الآلي تصف الاستراتيجية **ما** سيفعله البوت. تصف إدارة المخاطر **كم** يمكن للبوت إيذاء الحساب قبل إيقافه. في التداول اليدوي، غالباً ما يتداخل الاثنان في حكم واحد. في التداول الآلي يجب فصلهما، لأن البوت لا يتوقف للتفكير من جديد. هذه الصفحة مملة بتعمد. المحتوى ليس ذكياً؛ إنه مجموعة الحدود التي تفصل بين المشغلين الذين ينجون وأولئك الذين لا ينجون. ## الطبقات الثلاث فكّر في إدارة المخاطر كثلاث طبقات مستقلة، كل منها يجب أن تُفعَّل وحدها دون الحاجة إلى الطبقتين الأخريين: 1. **الحد لكل صفقة.** الخسارة القصوى في أي صفقة فردية محدودة بوقف خسارة مُوضوع مسبقاً أو حجم المركز. صفقة واحدة كارثية لا يمكنها تجاوز هذا الحد. 2. **الحد لكل استراتيجية.** الخسارة التراكمية القصوى لأي استراتيجية فردية خلال نافذة متحركة (يوم / أسبوع / شهر) محدودة. عند الوصول إليها، تُوقف الاستراتيجية مؤقتاً للمراجعة البشرية. 3. **الحد على مستوى الحساب.** الخسارة التراكمية القصوى عبر **جميع** الاستراتيجيات محدودة. عند الوصول إليها، تُوقف كل استراتيجية في الحساب مؤقتاً. لكل حد عتبة تنبيه خاصة به (مثلاً عند 80% من الحد) حتى يتلقى المشغل تحذيراً قبل تفعيل الحد، لا بعده. ## تحجيم المراكز ثلاث قواعد تحجيم مستخدمة عملياً. اختر واحدة لكل استراتيجية واكتبها. ### 1. الكسر الثابت (الأبسط) ``` حجم_المركز_الاسمي = رأس_مال_الحساب × كسر_المخاطرة ``` مع `كسر_المخاطرة` عادةً 1–2% لصفقة عالية القناعة، 0.25–0.5% لصفقة إشارة من مصدر خارجي. يتجاهل التذبذب ومسافة الوقف، وهذا ضعف، لكنه القاعدة التي تصمد أطول أمام أخطاء المشغل. ### 2. تعادل المخاطر (مُعدَّل بالتذبذب) ``` حجم_المركز_الاسمي = (رأس_مال_الحساب × المخاطرة_لكل_صفقة) / (مسافة_الوقف_بالنسبة_المئوية) ``` حجم المركز يتناسب عكسياً مع مسافة الوقف، لذا صفقة ذات وقف ضيق أكبر وصفقة ذات وقف واسع أصغر. هذا يُساوي المخاطرة بالدولار بين الإعدادات، لكنه يتطلب أن يضع المشغل وقفاً صادقاً ومدروساً. ### 3. كسر Kelly (متقدم، سهل الإساءة في الاستخدام) ``` كسر_kelly = معدل_الانتصار - (1 - معدل_الانتصار) / نسبة_العائد حجم_المركز_الاسمي = رأس_مال_الحساب × (كسر_kelly × مقياس_kelly) ``` مع `مقياس_kelly` عادةً 0.25–0.5 ("Kelly الكسري") لأن Kelly الكامل هو الأمثل فقط إذا كانت تقديراتك لمعدل الانتصار والعائد دقيقة تماماً، وهذا لا يتحقق أبداً. معظم المتداولين من قطاع التجزئة لا يجب أن يستخدموا هذه القاعدة لأن تقدير `معدل_الانتصار` و`نسبة_العائد` من سجل حي قصير يُنتج أرقاماً سيئة. ## حدود الحد الأقصى للتراجع المعامل الوحيد الأكثر أهمية في إدارة المخاطر هو **حد الحد الأقصى للتراجع** لكل استراتيجية ولكل حساب. تراجع 20% يتطلب استرداداً بنسبة 25%؛ تراجع 50% يتطلب استرداداً بنسبة 100%؛ تراجع 90% يتطلب استرداداً بنسبة 900%. الفائدة المركبة متماثلة في النسبة المئوية لكن غير متماثلة بالدولار. الإعدادات المحافظة لقطاع التجزئة: | الحد | لكل استراتيجية | لكل حساب | |-----------------|----------------|----------| | الخسارة اليومية | 3% | 2% | | الخسارة الأسبوعية | 7% | 5% | | الخسارة الشهرية | 15% | 10% | عند الوصول إليه، تُوقف الاستراتيجية (أو الحساب) مؤقتاً حتى يراجع المشغل ويُعيد التمكين صراحةً. الإيقاف المؤقت غير قابل للتفاوض؛ هو ما يمنع الأسبوع السيئ من أن يصبح عاماً سيئاً. ## مفاتيح الطوارئ يجب أن تمتلك كل استراتيجية اثنين على الأقل من مفاتيح الطوارئ المستقلة: 1. **محلي للاستراتيجية.** البوت نفسه يحتوي على منطق التراجع الذي يوقف الاستراتيجية عند تفعيل الحد. يتطلب أن يكون البوت نشطاً ويقرأ بيانات السوق. 2. **على مستوى المنصة.** مراقب خارجي (منصة Pulsar.INK) يمكنه إيقاف استراتيجية مؤقتاً بصرف النظر عما تعتقده الاستراتيجية. يُستخدم لانقطاعات البورصة، وحدود التراجع على مستوى الحساب، وإلغاء مفاتيح API. الاعتماد على مفتاح الطوارئ المحلي للاستراتيجية فقط هو كيف يخسر المشغلون كثيراً خلال انقطاعات البنية التحتية — البوت معلق، لا شيء يوقفه لأن لا شيء يعمل. ## نطاق تأثير الاستراتيجية عندما تشترك استراتيجيات متعددة في حساب واحد، يصبح نطاق تأثير استراتيجية واحدة مخاطرة منهجية للاستراتيجيات الأخرى. أبسط محدد لنطاق التأثير هو **تخصيص رأس المال**: الإعلان مسبقاً عن الحد الأقصى الاسمي الذي يمكن لاستراتيجية ما الاحتفاظ به في أي وقت ورفض أي أمر يُخالف ذلك. مثال على التخصيص لحساب قيمته 10,000 دولار: - 40% بوت DCA في BTC وETH (4,000 دولار) - 25% بوت شبكة في BTC/USDT (2,500 دولار) - 20% بوت إشارات في العملات البديلة الرئيسية (2,000 دولار) - 15% احتياطي (لم يُنشر أبداً) (1,500 دولار) الاحتياطي غير قابل للتفاوض. إنه الوسادة لنداءات الهامش، وإعادة الدخول الفرصية بعد توقف بسبب حد التراجع، وتكلفة الخطأ الموجود في الاستراتيجية التي لم تكتشفه بعد. ## التكامل مع عقد الاستراتيجية لكل عائلة من الاستراتيجيات في قاعدة المعرفة هذه ملفها الخاص من المخاطر: - grid-trading-strategy — المخاطرة السائدة هي اختراق النطاق؛ الحد هو وقف خسارة ثابت أسفل النطاق، وليس حد تراجع ناعم. - dca-bot-strategy — المخاطرة السائدة هي تراكم أصل ميت؛ الحد هو حد اسمي إجمالي لكل أصل، وليس لكل صفقة. - arbitrage-bots — المخاطرة السائدة هي الطرف المقابل/التحويل؛ الحد هو حد رأس مال لكل منصة بالإضافة إلى اختبار سحب يومي. - signal-trading-bots — المخاطرة السائدة هي الإشارات السيئة؛ الحد هو حد مخاطرة لكل صفقة وحد PnL متحرك على مصدر الإشارة. - copy-trading-explained — المخاطرة السائدة هي تغيير سلوك القائد؛ الحد هو مراجعة PnL المتحركة وجدول مراجعة محدود زمنياً. تعمل كل استراتيجية في ظل مجموعة حدودها الخاصة، بالإضافة إلى الحد على مستوى الحساب الذي ينطبق على جميعها. ## حلقة المراجعة البشرية إدارة المخاطر ليست مجرد معاملات. إنها أيضاً جدول المراجعة: - **يومياً:** نظرة سريعة على PnL كل استراتيجية ونسبة PnL/الحد. أي شيء فوق 80% من الحد يستحق الاهتمام. - **أسبوعياً:** مراجعة الصفقات المُغلقة والتنفيذات. هل هي ما قصدته الاستراتيجية؟ السلوك غير المتوقع إشارة أقوى من الخسارة غير المتوقعة. - **شهرياً:** إعادة التحقق من أطروحة الاستراتيجية. هل لا تزال حالة السوق واحدة صُممت لها هذه الاستراتيجية؟ إذا لا، أوقفها مؤقتاً. - **ربع سنوي:** إعادة توازن التخصيص بين الاستراتيجيات؛ سحب تلك التي أخفقت في تحقيق أطروحتها لربعين متتاليين. هذه الحلقة هي ما يحوّل التداول الآلي من "رهان" إلى "عملية". ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — السياق الأوسع. - backtesting-explained — لماذا لا يلتقط أي اختبار خلفي الصورة الكاملة للمخاطر. - exchange-api-key-security — مخاطر مستوى بيانات الاعتماد التي تكمن تحت كل هذا ولا تُسعَّر في أي مكان آخر. ### ar/kb/signal-trading-bots.md Source: https://pulsar.ink/ar/kb/signal-trading-bots.html # بوتات التداول بالإشارات **بوت التداول بالإشارات** يتلقى إشارة من مصدر خارجي ويتصرف بناءً عليها بإرسال أمر مقابل حساب البورصة للمشغل. يختار المشغل مصدر الإشارة؛ البوت هو المُنفِّذ المنضبط الذي لا يُشكّك في الإشارة. هذا هو الأقرب للتداول بالنسخ (راجع copy-trading-explained)، لكن مصدر الإشارة عادةً ما يكون مجموعة قواعد أو تغذية أو webhook بدلاً من حساب متداول حي آخر. ## تصنيف الإشارات | نوع الإشارة | مثال | قابل للمراجعة؟ | الإيقاع النموذجي | |-----------------------|----------------------------------------------------|----------------|---------------------| | مؤشر تقني | RSI يتجاوز 30، انعكاس هيستوغرام MACD | نعم | ثوانٍ إلى ساعات | | قاعدة price-action | إغلاق فوق أعلى 20 يوماً (اختراق Donchian) | نعم | يومي | | Webhook من TradingView | أي سكريبت مخصص يُرسل تنبيهات عبر HTTPS | أحياناً | متغير | | قناة Telegram | محلل بشري ينشر "BUY BTC 50000 SL 48000" | لا | غير منتظم | | نموذج داخلي | سكريبت Python الخاص بك يُرسل إشارات JSON | نعم | متغير تماماً | | API خارجي | نقطة نهاية مزود تُعيد شراء/بيع بجدول زمني | نادراً | يعتمد على المزود | تستطيع Pulsar.INK استهلاك إشارات من أول خمسة من هذه الأنواع عبر نقطة نهاية webhook أو دردشة متكاملة مع Telegram. يُقرر المشغل في أي فئة مصدر يثق، وقرار الثقة هو مصدر قلق المخاطر الأول — راجع أدناه. ## سياسة التنفيذ مهمة بقدر الإشارة إشارة تقول "اشترِ." يجب على البوت أن يُقرر: - **طريقة الدخول.** أمر بالسوق، محدد بسعر الإشارة، محدد مع إزلاق X نقطة أساس، TWAP خلال Y دقيقة؟ - **حجم المركز.** اسمي ثابت، نسبة مئوية من رأس المال، مُعيَّر بالتذبذب، كسر Kelly؟ - **وضع وقف الخسارة.** استخدم SL الإشارة (إن وُجد)؟ استخدم مضاعف ATR؟ نسبة مئوية ثابتة؟ - **وضع هدف الربح.** السؤال ذاته في الاتجاه الآخر. - **معالجة الإشارات المكررة.** إذا أُعيد إطلاق الإشارة ذاتها أثناء وجود مركز مفتوح، هل تُضخَّم التوسعة أم تُتجاهل أم تُغلق وتُعكس؟ يمكن لمشغلَين يستخدمان مصدر إشارة ذاته أن ينتجا PnL مختلفاً جذرياً باختيار سياسات تنفيذ مختلفة. هذا هو الجزء الذي يُقلّل معظم مستهلكي الإشارات من شأنه. خط أساس جيد: - أوامر محددة بسعر الإشارة مع إزلاق أقصى 15 نقطة أساس - تحجيم بنسبة ثابتة من رأس المال (مثلاً 2% لكل إشارة) - SL عند 1.5× ATR(14) أو SL الصريح للإشارة، أيهما أضيق - TP عند 1.0× ATR(14) متحرك، أو لا شيء (اترك مصدر الإشارة يُصدر الخروج) - تجاهل الإشارات المكررة بينما المركز مفتوح ## فخ تحيز البقاء مصادر الإشارة العامة هي ترتيب للناجحين. مزودو الإشارات الذين أنتجوا خسائر صمتوا؛ الباقون أنتجوا مكاسب. الاختبار الخلفي على موقعهم يبدأ من اليوم الذي بدأت فيه استراتيجيتهم تعمل، لا من اليوم الذي بدأوا فيه المشروع. قبل الاشتراك في أي مصدر إشارة خارجي، يجب على المشغل: 1. طلب سجل إشارات كامل مُدوَّن بالوقت يغطي ≥12 شهراً، ومثالياً ≥24، بما في ذلك الإشارات التي لم تُنتج فائزين. 2. حساب PnL ذلك السجل باستخدام سياسة التنفيذ الخاصة بالمشغل، لا سياسة المزود. 3. التحقق من أن المزود لم يحذف الخاسرين من السجل (فجوات الوقت هي علامة دالة). 4. محاكاة **نموذج إزلاق متشائم**: في الأسواق السائلة، bid بدلاً من mid؛ في الأسواق غير السائلة، bid ناقص X نقطة أساس. إذا لم يستطع المزود توفير السجل، مصدر الإشارة هو رهان غير مراجع على السمعة. يمكن أن يظل رهاناً صحيحاً؛ إنه ببساطة ليس قراراً مبنياً على البيانات. راجع backtesting-explained لنمط البقاء العام ولماذا يُعد تحيز look-ahead الفخ الأخ المرتبط ارتباطاً وثيقاً. ## لماذا يجب ألا يستدل المُنفِّذ على الإشارة بمجرد اختيار المشغل لثقته في مصدر إشارة، مهام المُنفِّذ الوحيدة هي: - **استلام الإشارة بسرعة.** ميزانية زمن الاستجابة لالتقاط إشارة جيدة هي عادةً 100–500 ms. - **تطبيق سياسة التنفيذ بشكل حتمي.** لا تجاوز "أعتقد أن هذه الإشارة خاطئة". - **تسجيل النتيجة.** كل إشارة، وكل تنفيذ، وكل إزلاق — لأن ذلك السجل هو المدخل لدورة المراجعة التالية. مُنفِّذ "يُحسِّن" الإشارات بتقديره الخاص يجمع عدم يقين مزود الإشارة مع التجاوزات العاطفية للمشغل. هكذا يموت التداول بالإشارات في قطاع التجزئة. الانضباط هو: اختر المصدر، اختر السياسة، نفّذ آلياً، راجع بجدول منتظم، غيّر المصادر أو السياسات عند المراجعة — لا أثناء الصفقات. ## العلاقة مع التداول بالنسخ التداول بالنسخ (راجع copy-trading-explained) هو حالة منحلة من التداول بالإشارات حيث "الإشارة" هي "ما فعله حساب هذا القائد." كل ما سبق لا يزال ينطبق — سياسة التنفيذ، وتحيز البقاء، وسجل المراجعة — لكن إمكانية رؤية الإشارة أسوأ، لأن القائد يمكنه تغيير الاستراتيجية بين ليلة وضحاها والتابع لا يستطيع رؤية المنطق. التداول بالإشارات بمجموعة قواعد قابلة للمراجعة أكثر شفافية بشكل صارم من التداول بالنسخ، ولهذا يعد الخيار الأفضل للمشغلين الذين يريدون فهم ما يفعلونه. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — الفئة الأوسع. - copy-trading-explained — المتغير القائم على الهوية. - risk-management-automated-trading — الحدود التي تُقيّد قدرة أي مصدر إشارة على إلحاق الضرر بالحساب. - backtesting-explained — الانضباط المطلوب للبقاء / look-ahead / فترة العينة لمراجعة أي مصدر. ### ar/kb/telegram-native-trading-ux.md Source: https://pulsar.ink/ar/kb/telegram-native-trading-ux.html # تجربة التداول المدمجة في Telegram صُمِّمت Pulsar.INK حول واجهة **مدمجة في Telegram**: لا يُنشئ المشغل كلمة مرور، ولا يثبّت تطبيقاً منفصلاً، ولا يحتاج إلى شاشة تداول مخصصة. كل ما تستطيع المنصة فعله — ربط البورصات، وتمكين الاستراتيجيات، وضبط المعاملات، والإيقاف المؤقت، ومراجعة PnL — يجري داخل محادثة Telegram. تشرح هذه الصفحة سبب اتخاذ هذا الاختيار وما هي انعكاساته التصميمية. ## لماذا Telegram يعيش مستخدمو العملات المشفرة بالفعل في Telegram. المجتمع والإشارات والدعم والتحديثات تتدفق كلها عبر التطبيق ذاته، لذا فإن واجهة تداول تُشارك هذا السطح تُزيل تبديل السياق. بشكل أكثر تحديداً: - **شاملة، متعددة المنصات.** تعمل بشكل متطابق على iOS وAndroid وmacOS وWindows وLinux والويب. لا اعتماد على موافقة متجر التطبيقات ولا مخاطر الاستبعاد الإقليمي من App Store. - **إشعارات الدفع مدمجة.** كل تنبيه تُصدره المنصة يصل إلى المشغل على كل الأجهزة التي يستخدم عليها Telegram، دون قناة إشعارات منفصلة. - **سجل الدردشة هو سجل المراجعة.** كل أمر، وكل تغيير في المعاملات، وكل إشعار موجود بشكل دائم في تاريخ المحادثة. لا يحتاج المشغل إلى الاحتفاظ بسجل منفصل. - **نموذج المصادقة مُستعار.** تصبح الأمان الخاص بحساب Telegram (2FA، كلمة مرور السحابة، تأكيد مستوى الجهاز) هو محيط أمان المنصة — لا نُعيد بناءه. ## سطح المصادقة تدفق المصادقة هو تسجيل دخول **Mini App** في Telegram: 1. يفتح المشغل المنصة في Telegram. 2. يُصدر Telegram حمولة `initData` موقّعة تُحدد معرف مستخدم Telegram للمشغل والجلسة والجهاز. 3. يتحقق خادم المنصة من التوقيع باستخدام سر البوت ويُعامل معرف مستخدم Telegram على أنه هوية المنصة. 4. تحدث جميع الإجراءات اللاحقة في سياق تلك الهوية. **لا توجد كلمة مرور من جانب المنصة**، وبالتالي لا توجد كلمة مرور من جانب المنصة يمكن سرقتها أو إعادة تعيينها أو التصيد بها. توجد مقايضة: إذا اختُرق حساب Telegram للمشغل، يرث المهاجم جلسة المنصة. تعيش التخفيفات في طبقة Telegram (2FA، كلمة مرور السحابة، مراجعة الأجهزة الأخيرة) وفي طبقة البورصة (exchange-api-key-security يُبقي السحب مُعطَّلاً، لذا أسوأ ما يمكن للمهاجم فعله هو التداول المتقاطع على الحساب بدلاً من إفراغه). راجع أيضاً risk-management-automated-trading لتصميمات مفاتيح الطوارئ التي لا تعتمد على إمكانية الوصول إلى Telegram — يجب أن تظل المنصة قابلة للإيقاف إذا فقد المشغل الوصول إلى هاتفه. ## تجربة المستخدم المرتبة بالرسائل واجهة الدردشة أولاً ترتب الإجراءات بالزمن، لا بالتنقل. يرى المشغل آخر ما حدث في أسفل الشاشة، مع كامل التاريخ في الأعلى. للتداول تحديداً: - تتضمن رسائل **تغيير الاستراتيجية** الفرق في المعاملات (قديم ← جديد) حتى يتمكن المشغل من التمرير للخلف لفهم ما غيّره. - تتضمن رسائل **التنفيذ** السعر والحجم والرسوم وفرق PnL منذ آخر رسالة. - رسائل **التنبيه** مُوسومة بالخطورة (معلومات / تحذير / حرج) ويُعاد تثبيت التنبيهات الحرجة تلقائياً. الانضباط في تجربة المستخدم هنا هو إبقاء الرسائل **وصفية لنفسها** — يجب على المستخدم أن يكون قادراً على فهم تنبيه قديم بشهر دون فتح أي شاشة أخرى. منصة تداول تُجبر المستخدم على البحث هي منصة تداول تفوتها التنبيهات. ## ميزانية الإشعارات بوت التداول كثير الإشعارات يُدرّب المشغلين على تجاهل الإشعارات. هدف تصميم Pulsar.INK هو تقريباً: | فئة الحدث | جدول الإشعارات | |--------------------------------------|-------------------------------| | كل تنفيذ فردي | مُغلَق افتراضياً؛ اشتراك اختياري | | ملخص PnL التراكمي | ملخص يومي، اختياري | | اقتراب عتبة التراجع | فوري، غير قابل للكتم | | تفعيل حد التراجع / الاستراتيجية مُوقفة مؤقتاً | فوري، غير قابل للكتم | | مفتاح API على وشك الانتهاء | قبل 72 ساعة، ثم 24 ساعة | | انقطاع البورصة المكتشف | فوري | | حدث أمني (IP غير معتاد، تدوير مفتاح) | فوري، غير قابل للكتم | المبدأ هو: **الأحداث الروتينية تُستشار، والأحداث الحرجة تُدفع**. مراجعة يومية هي اختيار المشغل؛ تنبيه تفعيل حد التراجع ليس كذلك. ## لماذا لا لوحة تحكم ويب؟ تُوفّر Pulsar.INK لوحة تحكم ويب للقراءة فقط للمراجعات الأعمق (تاريخ PnL الطويل، مقارنة الاستراتيجيات المتعددة، التصدير). لكن **سطح التحكم** يعيش في Telegram، لأن سطح تحكم يتطلب من المشغل تسجيل الدخول في مكان آخر هو سطح تحكم يُستخدم بشكل أقل. استخدام أقل لسطح التحكم يعني ردود فعل أبطأ على المشكلات، مما يعني خسائر محققة أكبر. ## المقايضات في الواجهة المدمجة في Telegram التصميم ليس خالياً من العيوب: - **الوصول الإقليمي.** Telegram محجوب أو مُقيَّد في بعض الولايات القضائية. المشغلون في تلك المناطق يحتاجون VPN إضافة إلى آليات مكافحة الحجب الخاصة بـTelegram. - **انقطاعات Telegram.** عندما يكون Telegram معطوباً يتدهور سطح التحكم. البنية التحتية الخاصة لمفاتيح الطوارئ في المنصة لا تزال تعمل (راجع risk-management-automated-trading)، لكن المشغل لا يستطيع ضبط الاستراتيجيات خلال الانقطاع. - **استرداد حساب Telegram.** إذا فقد المشغل حساب Telegram الخاص به، فالاسترداد هو عملية من جانب Telegram، ليست من جانب Pulsar.INK. لا تستطيع المنصة استعادة الوصول لشخص لا يستطيع إثبات أنه مستخدم Telegram ذاته. كل من هذه مقبول في ضوء أولويات التصميم؛ يجب على المشغلين معرفتها مسبقاً بدلاً من مواجهتها في خضم أزمة. ## قراءة إضافية في قاعدة المعرفة - what-is-automated-crypto-trading — الوظيفة الأساسية للمنصة. - exchange-api-key-security — الدفاع المتعمق على مستوى بيانات الاعتماد. - risk-management-automated-trading — مكدس مفاتيح الطوارئ الذي يعمل عندما لا يعمل Telegram. ### ar/kb/what-is-automated-crypto-trading.md Source: https://pulsar.ink/ar/kb/what-is-automated-crypto-trading.html # ما هو تداول العملات المشفرة الآلي؟ **تداول العملات المشفرة الآلي** هو ممارسة تنفيذ أوامر الشراء والبيع على بورصة العملات المشفرة عبر برنامج يتبع مجموعة قواعد محددة مسبقاً، بدلاً من الاعتماد على حكم الإنسان اللحظي. تُعرف هذه المجموعة من القواعد عادةً باسم **الاستراتيجية** أو **البوت**، وتعمل باستمرار، وتأخذ بيانات السوق مدخلات وتُصدر الأوامر مخرجات. يتخذ المشغل (أنت) ثلاثة قرارات مسبقاً: 1. **أي سوق** سيتداول فيه البوت (مثلاً `BTC/USDT` على بورصة معينة، أو سلة أصول عبر منصات متعددة). 2. **أي قواعد** سيتبعها البوت (شبكة، DCA، إشارة زخم، مراجحة، نسخ، إعادة توازن — راجع الاستراتيجيات المختلفة في grid-trading-strategy، dca-bot-strategy، copy-trading-explained، arbitrage-bots). 3. **أي حدود مخاطر** ستوقف البوت (الحد الأقصى للتراجع، الحد الأقصى لحجم المركز، توقفات في أوقات محددة — راجع risk-management-automated-trading). بمجرد تحديد هذه الثلاثة، يُنفذ البوت دون الحاجة إلى تواجدك. ## كيف يختلف عن التداول اليدوي | البُعد | التداول اليدوي | التداول الآلي | |---------------------|-----------------------------------------------|--------------------------------------------------------| | زمن الاستجابة | ثوانٍ إلى دقائق (ردة فعل بشرية) | ميلي ثانية (رحلة API) | | الاتساق | المزاج والتعب والنوم تؤثر على النتائج | تطبيق قواعد متطابق عند كل نقطة سعر، لصالحك أو ضدك | | التغطية | الساعات التي تكون مستيقظاً أمام الشاشة | 24/7، عبر عشرات الأسواق بالتوازي | | التدخل العاطفي | متكرر؛ وغالباً المصدر الأكبر للخسائر | مستحيل ما لم يتدخل المشغل | | نمط الفشل | صغير عادةً وقابل للتعافي | قد يكون كبيراً وسريعاً إذا كانت حدود المخاطر مُعَيَّنة بشكل خاطئ | الاتساق سلاح ذو حدين. يزيل الأتمتة المصدر الرئيسي لخسائر المتداول الفردي (البيع بذعر، التداول الانتقامي). كما يزيل آلية الاسترداد — إذا كانت القاعدة خاطئة، سيستمر البوت في تطبيقها بسرعة الآلة حتى يُفعَّل حد مخاطرة. لذلك فإن risk-management-automated-trading ليست هامشاً: إنها الاستراتيجية ذاتها. ## فئات المخاطر الثلاث نموذج ذهني مفيد: كل مشغل للتداول الآلي يحمل ثلاثة مخاطر متزامنة: 1. **مخاطر السوق** — يتحرك الأصل عكس أطروحة الاستراتيجية. هذه هي المخاطرة التي تنوي أخذها، وما صُممت الاستراتيجية لتسعيره. 2. **مخاطر البنية التحتية** — لا يستطيع البوت الوصول إلى البورصة (خادمك الخاص معطل، أو واجهة API محدودة المعدل، أو شهادة منتهية). لا تُنفَّذ الأوامر، أو تُنفَّذ مرتين. اعتقدت أنك خرجت؛ لكنك لا تزال داخل المركز. 3. **مخاطر بيانات الاعتماد** — مفتاح API الذي يحمله البوت مسروق أو مُساء استخدامه أو مُهيأ بنطاق صلاحيات خاطئ. أفضل استراتيجية في العالم لا قيمة لها إذا كان المفتاح يمكنه سحب الأموال. معالجة هذه المخاطرة هي موضوع exchange-api-key-security. تتولى المنصة تخفيف جزء من هذا العبء: | فئة المخاطر | ما يملكه المشغل | ما تتكفل به Pulsar.INK | |----------------|-----------------------------------|-------------------------------------------------| | السوق | اختيار الاستراتيجية + معاملاتها | محرك التنفيذ، تطبيع بيانات السوق | | البنية التحتية | توفر حساب Telegram (حد أدنى) | الخادم، التعافي من الأعطال، مطابقة الأوامر، إعادة المحاولة | | بيانات الاعتماد | تحديد نطاق مفتاح API من جهة البورصة | التشفير أثناء النقل، عدم استخدام صلاحية السحب | ## موقع Pulsar.INK Pulsar.INK هي **طبقة التنفيذ**. لا تحتجز عملاتك — تبقى في بورصتك. تحتفظ بمفتاح API بصلاحيات **التداول فقط** (راجع exchange-api-key-security لقائمة النطاق الإلزامي) وتُشغّل الاستراتيجيات التي فعّلتها مقابل هذا المفتاح. تسجيل الدخول عبر Telegram بشكل طبيعي (راجع telegram-native-trading-ux): يربط المشغل حساب Telegram الخاص به، ويُدرج حساباً واحداً أو أكثر من حسابات البورصة عبر مفتاح API، ويختار قالب استراتيجية، ويضبط المعاملات، ويُفعّلها. مهمة المنصة هي جعل كل استراتيجية قابلة للمراقبة وكل استراتيجية قابلة للإيقاف من الهاتف، لأن أسواق العملات المشفرة لا تحترم ساعات العمل. ## ما لا يعنيه مصطلح "آلي" لا يعني "دخل سلبي". لكل استراتيجية مُشغَّلة مشغّل يقوم بما يلي: - مراجعة منطق الاستراتيجية (راجع backtesting-explained لمعرفة سبب كون الاختبار الخلفي الجيد ضرورياً لكنه غير كافٍ). - ضبط المعاملات مع تغير حالة السوق (صاعد، هابط، متذبذب). - إيقاف التشغيل عندما تخرج الظروف عن نطاق ما صُممت له الاستراتيجية. تُقلّص الأتمتة تكلفة وقت التنفيذ؛ لكنها لا تُقلّص تكلفة وقت الإشراف. يُمضي المشغل الواقعي ربما خمس إلى خمس عشرة دقيقة يومياً في فحص المنظومة، وأكثر من ذلك بكثير عند تغيير الاستراتيجيات أو تهيئة بورصة جديدة. ## قراءة إضافية في قاعدة المعرفة - copy-trading-explained — توارث قرارات شخص آخر. - grid-trading-strategy — أكثر استراتيجية "بدون رأي" شيوعاً. - dca-bot-strategy — متوسط التكلفة بدون لمس هاتفك. - signal-trading-bots — التصرف بناءً على إشارات من أطراف ثالثة أو من الداخل. - arbitrage-bots — استغلال فوارق الأسعار بين المنصات. - risk-management-automated-trading — الحدود التي تمنع استراتيجية سيئة واحدة من إنهاء الحساب. - backtesting-explained — لماذا نادراً ما تصمد نتائج الاختبار الخلفي أمام الأسواق الحية. - telegram-native-trading-ux — الخيار التصميمي خلف واجهة Pulsar.INK. - exchange-api-key-security — سطح بيانات الاعتماد، بالتفصيل. --- ## Language: es (Spanish) Locale KB corpus for LLM indexing. Source: https://pulsar.ink/es/kb/ ### es/kb/arbitrage-bots.md Source: https://pulsar.ink/es/kb/arbitrage-bots.html # Bots de arbitraje El **arbitraje** es la compra y venta simultánea del mismo activo subyacente para capturar un diferencial de precio. Un **bot de arbitraje** automatiza la detección y la ejecución de dos piernas. A diferencia de las estrategias direccionales, el arbitraje debe ser neutral al mercado: que BTC suba o baje no cambia la ventaja de la operación, solo el costo de ejecución. En la práctica, el arbitraje de criptomonedas minorista está dominado por dos realidades: 1. Los diferenciales rentables son vistos primero por bots más rápidos con colocación y acuerdos de creación de mercado a nivel de exchange. 2. Los diferenciales que ve el minorista generalmente son demasiado pequeños para cubrir las comisiones después de la ejecución, o existen porque la latencia de retiro/transferencia los hace inarbitrables. El resto de esta página explica los cuatro tipos comunes y dónde el minorista todavía puede ganar. ## 1. Arbitraje espacial (entre exchanges) La forma más simple. El mismo activo, plataformas diferentes. - Detectar: el precio de compra de BTC/USDT en el Exchange A es superior al precio de venta de BTC/USDT en el Exchange B. - Ejecutar: comprar en B al precio de venta, vender en A al precio de compra. - Liquidar: usted está neutro en exposición a BTC pero necesita reequilibrar el inventario entre plataformas. La pierna oculta es el **reequilibrio de inventario**. Para comprar en B necesita USDT en B; para vender en A necesita BTC en A. El ciclo rentable depende no solo del diferencial, sino de si el inventario para repetir la operación está donde necesita estar. Existen dos modelos: - **Ambos lados prefunded.** El operador mantiene inventario equilibrado en ambos exchanges, nunca moviendo fondos en medio de una operación. Rápido, pero el capital se duplica (la mitad en cada plataforma). - **Transferencia bajo demanda.** El operador transfiere el activo comprado de B a A para restaurar el inventario. Lento (minutos a horas para transferencias de criptomonedas) y sensible al precio durante la ventana de transferencia. La mayoría de las configuraciones de arbitraje espacial rentables utilizan ambos lados prefunded con reequilibrios pequeños y frecuentes cuando un lado se agota. Los límites de retiro y las comisiones de transferencia se convierten en factores de primera importancia. ## 2. Arbitraje triangular (dentro del exchange) Tres pares, una plataforma. Ejemplo en un exchange que lista BTC/USDT, ETH/USDT, ETH/BTC: - Empezar con 1000 USDT. - Pierna 1: comprar BTC con USDT al precio actual de BTC/USDT. - Pierna 2: comprar ETH con BTC al precio actual de ETH/BTC. - Pierna 3: vender ETH por USDT al precio actual de ETH/USDT. - Resultado: más de 1000 USDT si los tres precios son inconsistentes. Esto elimina por completo el riesgo de transferencia entre exchanges — todo sucede dentro de una cuenta — pero los diferenciales son más estrechos porque los propios creadores de mercado del exchange los están cerrando constantemente. El arbitraje triangular es principalmente una disciplina de latencia y estructura de comisiones: las plataformas de comisión de maker le permiten publicar piernas como órdenes límite y ganar el reembolso, convirtiendo un diferencial casi nulo en una operación positiva. ## 3. Arbitraje de tasa de financiación (perpetuos) Los futuros perpetuos de criptomonedas tienen una **tasa de financiación** que transfiere periódicamente valor entre posiciones largas y cortas para mantener el perpetuo anclado al spot. Cuando la financiación es positiva, los largos pagan a los cortos; cuando es negativa, los cortos pagan a los largos. La operación: - Comprar BTC spot en el Exchange A. - Vender en corto el perpetuo de BTC en el Exchange A (o B) en el mismo tamaño. - Cobrar pagos de financiación cuando el mercado paga más a los cortos que a los largos, o viceversa. Usted es neutral en el precio de BTC y cosecha financiación. Esto funciona hasta que: - La financiación cambia de signo y consume el carry. - El lado spot cuesta dinero custodiarlo en el exchange (contribuciones al fondo de seguros, tasas de préstamo). - El margen del perpetuo es liquidado en un movimiento rápido en un lado, aunque la posición spot compense la pérdida — la mecánica de liquidación no conoce su cobertura en otro exchange. El arbitraje de financiación entre exchanges (spot en un exchange, perpetuo en otro) añade una capa de riesgo de transferencia; el arbitraje de financiación en un solo exchange elimina esa capa a costa de concentración de inventario. ## 4. Arbitraje estadístico (pares, cestas) Dos o más activos que históricamente se mueven juntos. Cuando el diferencial entre ellos se amplía más allá de las normas históricas, vender en corto la pierna cara y comprar en largo la pierna barata. Cerrar cuando el diferencial revierte. No es arbitraje en sentido estricto (la operación puede estar equivocada), pero se llama arbitraje en la industria porque la tesis es "reversión estadística a la media" en lugar de "visión direccional". Esto requiere más infraestructura de investigación que los otros tres — pruebas de cointegración, ventanas móviles, filtros de régimen — y generalmente es un juego de fondos cuantitativos, no del minorista. ## Presupuestos de latencia realistas Una operación de arbitraje rentable típicamente tiene una ventana de milisegundos a pocos segundos antes de que alguien más la cierre. La cadena de latencia minorista: | Salto | Latencia típica | |------------------------------------|--------------------------| | Datos de mercado: exchange → VPS | 20–150 ms (REST), 5–30 ms (WS) | | Detección del bot + decisión | 1–20 ms | | Envío de orden: VPS → exchange | 20–150 ms | | Actualización del libro de órdenes del exchange | 5–50 ms | Un ciclo completo minorista es por tanto 50–400 ms en el mejor caso. Cualquier diferencial que duró tanto ya era delgado. Los escritorios de arbitraje profesionales lo reducen a 1–5 ms mediante colocación y conexiones directas con creadores de mercado — y ellos son los que toman primero los diferenciales gruesos. Los nichos accesibles para el minorista tienden a ser: - **Exchanges de segundo nivel** donde los escritorios profesionales tienen menor presencia. - **Diferenciales de larga duración** impulsados por restricciones de depósito/retiro (por ejemplo, durante el mantenimiento del exchange). - **Arbitraje de tasa de financiación** en perpetuos, que trata del carry durante días, no milisegundos. - **Pares exóticos** y tokens listados donde la liquidez es delgada pero también lo es la competencia. ## El rincón del riesgo El arbitraje se anuncia como "libre de riesgo", lo que es falso bajo cualquier definición de riesgo: - **Riesgo de ejecución.** Una pierna se ejecuta, la otra no. Ahora usted tiene exposición direccional cuando no lo pretendía. - **Riesgo de transferencia.** Las transferencias entre exchanges pueden atascarse. Los diferenciales cambian durante el atasco; el inventario termina en el exchange equivocado. - **Riesgo de contraparte.** Un exchange se cae, cierra los retiros, congela la cuenta. Todo su capital de arbitraje en ese exchange está bloqueado. Esta es la mayor fuente de pérdida en la historia del arbitraje minorista de 2022–2023. - **Asimetría de liquidación.** La pierna del perpetuo se liquida en un movimiento rápido aunque la cobertura spot no haya cambiado; la pérdida del perpetuo se realiza, la ganancia del spot no. - **Riesgo del API.** La clave API es robada; los fondos en la cuenta del exchange son tomados mediante los permisos de trading (no se necesita retiro — el atacante puede hacerle cross-trading). Véase exchange-api-key-security. Estos riesgos viven en el fondo tanto si hace backtest como si no; backtesting-explained no captura ninguno de ellos. Los límites de posición en risk-management-automated-trading son la forma de acotarlos. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — el lugar del arbitraje en la taxonomía. - exchange-api-key-security — la superficie de ataque "trading sin retiro" que más importa aquí. - risk-management-automated-trading — límites de asignación de capital. - backtesting-explained — por qué los backtests de arbitraje ocultan los escenarios de riesgo de contraparte que producen las mayores pérdidas reales. ### es/kb/backtesting-explained.md Source: https://pulsar.ink/es/kb/backtesting-explained.html # Backtesting explicado El **backtesting** es la simulación de una estrategia sobre datos históricos. El objetivo es decidir si la estrategia tiene suficiente ventaja para valer la pena ejecutarla en vivo. El resultado del backtest es una curva de PnL, un perfil de caída y estadísticas de operaciones — a partir de los cuales el operador elige desplegar, reajustar o descartar. El problema con los backtests no es que mientan. Es que cuentan un tipo muy específico de verdad — "cómo habría funcionado la estrategia en **esta** historia con **estas** suposiciones" — y los operadores consistentemente malinterpretan esa verdad como una previsión. ## Lo que informa un backtest honesto | Métrica | Qué le dice | Qué no le dice | |-------------------------------|------------------------------------------------|----------------------------------------------| | Retorno total | PnL acumulado durante la muestra | Cuán volátil fue el camino | | Ratio de Sharpe | Retorno por unidad de volatilidad | Riesgo de cola; volatilidad bajista vs alcista | | Máxima caída | Peor pico a valle en la muestra | Caída posible fuera de la muestra | | Tasa de victorias | Porcentaje de operaciones rentables | Distribución del tamaño de ganancias y pérdidas | | Factor de beneficio | Suma(ganancias) / Suma(pérdidas) | La estabilidad de esta ratio a lo largo del tiempo | | Tiempo de exposición | Porcentaje del tiempo con capital en trabajo | Costo de oportunidad del capital inactivo | | Número de operaciones | Tamaño de muestra de los resultados | Si todas las ejecuciones fueron realistas | | Contabilidad de slippage + comisiones | Rentabilidad después de costos | Profundidad real del libro al tamaño de la orden | Si un backtest no informa todo esto, es un anuncio, no un backtest. ## Los cuatro sesgos que destruyen los backtests minoristas ### 1. Sesgo de look-ahead La estrategia utiliza datos que no estaban disponibles en el momento de la decisión. El caso clásico es calcular un indicador en el cierre de la barra actual y luego operar dentro de esa misma barra. También es común: reequilibrar contra un universo elegido con conocimiento de qué tokens sobrevivieron hasta hoy (de ahí el "sesgo de supervivencia"). Corrección: las decisiones en el tiempo `t` deben usar solo datos disponibles en `t`. Haga cumplir esto desplazando todas las señales al menos una barra y operando en el open de la **siguiente** barra, no en el cierre de la barra actual. ### 2. Sesgo de supervivencia El universo que está probando es el universo que existe **hoy**. Cada token dado de baja, cada exchange muerto, cada protocolo fallido está ausente. Una estrategia de reversión a la media que "funciona" en el universo de hoy habría sido diezmada por el universo que existía hace cinco años, porque los perdedores han desaparecido. Corrección: pruebe contra un **universo en un momento específico del tiempo** — el conjunto de activos que eran negociables en cada fecha — lo que es costoso de ensamblar para cripto y casi imposible para tokens de cola larga. La siguiente mejor corrección es limitar el alcance del backtest a los N activos principales por liquidez, reconocer el sesgo y dimensionar en consecuencia. ### 3. Sesgo del período de muestra La ventana del backtest es un único corte de la historia del mercado, y el corte que elija impulsa el resultado más que la estrategia. Una cuadrícula en BTC/USDT del 2023-01 al 2024-01 parece perfecta (rango lateral). La misma cuadrícula del 2024-02 al 2025-04 parece terrible (tendencia). Ninguna ventana es incorrecta; ambas están incompletas. Corrección: informe resultados a través de múltiples **ventanas fuera de muestra**, incluyendo un ciclo completo alcista-bajista-alcista. Informe la distribución, no el número único. ### 4. Modelado insuficiente del slippage El backtest ejecuta al precio medio histórico. Los mercados en vivo ejecutan contra el spread, y a veces fuera de él cuando el libro es delgado o el movimiento es rápido. Para bots de cuadrícula que realizan cientos de operaciones al día, un error de slippage de 5 puntos básicos se acumula hasta un capital final muy diferente. Corrección: modele **ejecuciones realistas**: - Las órdenes de taker al peor precio visible del tamaño solicitado en ese timestamp. - Las órdenes de maker solo se ejecutan si el precio opera **a través** del nivel publicado, no solo lo toca. - Durante las barras de alta volatilidad, amplíe el modelo de spread; durante las horas de baja liquidez, limite el tamaño de la orden a una fracción realista del volumen de la barra. Ningún motor de backtest público clava todo esto. El enfoque pragmático es ejecutar el backtest, luego descontar el resultado — 20–40% menor retorno esperado, 30–50% mayor caída — para obtener algo más cercano a lo que la estrategia en vivo realmente hará. ## Validación walk-forward El reemplazo honesto de "entrenar en toda la historia, afirmar que funciona" es la **validación walk-forward**: 1. Elija una ventana dentro de muestra (por ejemplo, 2021-01 a 2022-01) y ajuste la estrategia sobre ella. 2. Elija una ventana fuera de muestra (2022-01 a 2022-04) y ejecute la estrategia ajustada contra ella **sin más ajustes**. 3. Deslice la ventana hacia adelante (2021-04 a 2022-04 dentro de muestra, 2022-04 a 2022-07 fuera de muestra) y repita. 4. Concatene todos los PnL fuera de muestra. Esa concatenación es lo que la estrategia puede esperarse que produzca. La validación walk-forward rutinariamente reduce los retornos reportados en un 30–60% frente a un ajuste de ventana única. Los operadores que no ejecutan walk-forward obtienen un número sobreajustado. ## Trampas específicas de las criptomonedas - **Migración de exchange.** Un backtest de BTC/USDT en el Exchange A desde 2019 puede unir datos de un exchange que ya no existe. La liquidez y los spreads no son transferibles. - **Desvinculación de stablecoin.** Una estrategia que usa USDT como moneda de cotización asume USDT = $1 en cada barra. Esto ha sido incorrecto durante ventanas extendidas (mayo 2022, marzo 2023) y el backtest generalmente no lo corrige. - **Dilución de token / airdrop.** Los cambios en el suministro de tokens cambian silenciosamente el "precio" durante ventanas largas. - **Cambios en el calendario de comisiones.** Los exchanges cambian las comisiones de maker/taker trimestralmente. Un backtest de 2020 usando comisiones de 2026 es optimista. - **Bases de tasas de financiación de futuros.** Las tasas de financiación han tendido a la baja desde 2021 a medida que maduró la liquidez; un backtest de arbitraje de financiación de 2018 no es una previsión para 2026. ## Notas específicas por estrategia - grid-trading-strategy — los backtests de cuadrícula sobre un solo rango siempre parecen perfectos. Vuelva a hacer el backtest de la misma cuadrícula durante el mercado bajista de 2022 y el breakout de Q1 2024; los números son muy diferentes. - dca-bot-strategy — los backtests de DCA son los más honestos pero dependen del camino según la fecha de inicio. El backtest de múltiples fechas de inicio es la solución. - arbitrage-bots — los backtests ignoran el riesgo de contraparte y la latencia de transferencia, que son las dos mayores fuentes de pérdida en vivo. - signal-trading-bots — el backtest del proveedor de señales casi siempre sufre de sesgo de supervivencia; vuelva a ejecutarlo contra la propia política de ejecución del operador. La disciplina más amplia está cubierta en risk-management-automated-trading: ninguna cantidad de precisión del backtest elimina la necesidad de límites en la cuenta en vivo, porque la única variable que el backtest no puede simular es el operador. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — la categoría más amplia. - risk-management-automated-trading — los límites que acotan el lado negativo de cualquier estrategia independientemente de lo que dijera el backtest. ### es/kb/copy-trading-explained.md Source: https://pulsar.ink/es/kb/copy-trading-explained.html # Copy trading explicado El **copy trading** es una forma de trading automático (véase what-is-automated-crypto-trading) donde el bot del seguidor no toma decisiones de trading por sí mismo. En cambio, **refleja** las operaciones de un líder elegido — un trader humano, un fondo cuantitativo u otro bot — en la propia cuenta del exchange del seguidor, en tiempo casi real, a través de un API. El seguidor posee los fondos y la clave API; el líder posee las decisiones. La plataforma es el conducto entre ellos. ## El bucle de espejo 1. El líder envía una orden en su propia cuenta del exchange. 2. La plataforma detecta la ejecución (mediante polling del API del exchange o un feed de websocket). 3. La plataforma normaliza la ejecución en una orden del tamaño del seguidor de acuerdo con el modelo de dimensionamiento declarado por el seguidor. 4. La plataforma envía la orden del seguidor contra la clave API del seguidor. 5. La plataforma concilia — ¿se ejecutó la orden del seguidor completamente, parcialmente o no del todo? — y registra la desviación para el log de PnL del seguidor. Cada paso introduce una pequeña cantidad de **slippage**: el seguidor no obtiene exactamente el mismo precio que el líder. La cantidad de slippage aceptable es uno de los dos parámetros principales del lado del seguidor (el otro es el dimensionamiento, a continuación). ## Modelos de dimensionamiento Un líder con una cuenta de $1 millón puede comprar 10 BTC en una sola operación. Si un seguidor con una cuenta de $5,000 refleja esto ingenuamente, el seguidor o bien no puede permitirse la operación o quema su cuenta en una sola posición. Tres modelos de dimensionamiento son de uso común: ### 1. Proporcional (nominal) El seguidor opera `valor_operación_líder × (capital_seguidor / capital_líder)`. Simple, intuitivo, funciona bien con diferencias de tamaño de cuenta. Debilidad: cuando la cuenta del líder es mucho más grande que la del seguidor, la posición proporcional puede redondearse al mínimo negociable y ser silenciosamente omitida. ### 2. Nominal fijo El seguidor siempre opera un valor fijo en dólares (por ejemplo, $100 por operación reflejada). Simple, pero pierde la señal de convicción del líder — la "gran apuesta" y la "pequeña apuesta" del líder se convierten en el mismo tamaño en el lado del seguidor. ### 3. Paridad de riesgo El seguidor escala la posición por la distancia de stop declarada del líder y el riesgo máximo por operación del seguidor. Se corresponde con la práctica de escritorios profesionales, más difícil de configurar correctamente, generalmente requiere que el líder publique un stop-loss junto con cada entrada. Pulsar.INK soporta los tres. La elección es del seguidor y debe registrarse en la política de risk-management-automated-trading del operador. ## Lo que el copy trading comparte con el trading de señales, y lo que no El copy trading es el pariente más cercano al seguimiento de señales (véase signal-trading-bots). La diferencia está en el nivel de confianza: | Aspecto | Copy trading | Trading de señales | |------------------------------|-------------------------------------------|---------------------------------------------------| | ¿Quién emite la operación? | Un líder específico, por identidad | Una fuente de señal (indicador, canal, algoritmo) | | ¿Sensible a la latencia? | Sí — debe reflejar rápidamente | Sí, pero depende del tipo de señal | | Visibilidad de la salida | Igual que la entrada — cuando el líder sale | La señal puede no emitir una salida explícita | | Riesgo de sesgo de supervivencia | Alto (los líderes muertos son invisibles) | Alto (las señales muertas son invisibles) | | ¿Se puede auditar el razonamiento? | Solo lo que el líder divulgue | Depende — las señales basadas en reglas son completamente auditables | La principal trampa del copy trading es el **sesgo de supervivencia**: el ranking en cualquier plataforma muestra los supervivientes. Los líderes que quebraron han desaparecido de la lista. Este es el mismo mecanismo que hace que los resultados de backtesting-explained parezcan más positivos que los resultados en vivo — y es la razón por la que la debida diligencia de incorporación de un seguidor necesita ir más allá de "lo más alto del ranking la semana pasada". ## Presupuesto de slippage Si el líder ejecuta a $50,000 y el seguidor ejecuta a $50,030, eso es 6 puntos básicos (0,06%) de slippage. Una buena tubería de espejo mantiene el slippage promedio por debajo de 10 pb para pares líquidos; se degrada en pares delgados, movimientos impulsados por noticias y estrategias de alta frecuencia que el líder ejecuta más rápido de lo que el espejo puede seguir. Un seguidor cuya ventaja esperada por operación es menor que el presupuesto de slippage de la tubería está garantizado a perder dinero por aritmética, sin importar cuán bueno sea el líder. Por eso el copy trading funciona mejor para líderes de baja frecuencia y alta convicción que para líderes al estilo HFT. ## Superficie fiscal El copy trading no elimina la obligación fiscal de las operaciones individuales. Cada ejecución reflejada en el exchange del seguidor es un evento fiscal en la mayoría de las jurisdicciones, exactamente como si el seguidor hubiera entrado y salido por sí mismo. La plataforma no es la contraparte fiscal; el exchange lo es. Un seguidor que opera con un líder de alta frecuencia puede acumular miles de eventos fiscales al año y debería presupuestar para software de contabilidad en consecuencia. ## Modos de fallo a vigilar - **Compromiso de la cuenta del líder.** Si la cuenta del líder se ve comprometida, las operaciones maliciosas se reflejan antes de que nadie lo note. La única defensa del seguidor es un límite en el tamaño por operación y un límite total de caída diaria — véase risk-management-automated-trading. - **Permisos excesivos de la clave API.** El copy trading no necesita el permiso de retiro en la clave del seguidor; véase exchange-api-key-security para la lista completa de permisos. - **Cambio de condiciones de mercado.** Un líder que era rentable en un mercado en tendencia puede estar consistentemente equivocado en un mercado lateral. La relación de copia debe tener un límite de tiempo o estar condicionada al rendimiento; no es un arreglo de "configúralo y olvídalo". - **Interrupción de la plataforma durante la salida del líder.** Si la tubería de espejo está inactiva mientras el líder cierra una posición ganadora, el seguidor mantiene la posición abierta. El comportamiento de conmutación por error de Pulsar.INK es aplanar las posiciones de copia abiertas si el bucle de espejo pierde latidos durante más tiempo que un umbral configurable. Esto es más seguro que dejar una posición "atascada" abierta, pero es una decisión no trivial del lado del seguidor. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — la categoría más amplia a la que pertenece esta estrategia. - signal-trading-bots — el pariente más cercano no copy. - risk-management-automated-trading — los límites que acotan el radio de explosión del líder. - exchange-api-key-security — por qué el permiso de retiro permanece desactivado en las claves de los seguidores. - backtesting-explained — por qué el ranking no es un backtest. ### es/kb/dca-bot-strategy.md Source: https://pulsar.ink/es/kb/dca-bot-strategy.html # Estrategia de bot DCA El **promediado del costo en dólares (DCA)** es la práctica de comprar una cantidad fija en dólares de un activo en un calendario fijo — por ejemplo, $100 de BTC cada lunes — independientemente del precio actual. Un **bot DCA** hace esto automáticamente con una cadencia configurada por el usuario y puede, opcionalmente, escalar la compra cuando el precio cae por debajo de promedios móviles recientes. El DCA pertenece a la misma familia que otras estrategias automáticas (véase what-is-automated-crypto-trading) pero es la más sencilla de razonar: la única decisión que sobrevive es "¿sigo siendo optimista sobre este activo durante mi horizonte de acumulación?" ## DCA clásico Parámetros: - **Activo**: por ejemplo, BTC - **Cadencia**: por ejemplo, semanal, los lunes a las 12:00 UTC - **Monto en dólares por compra**: por ejemplo, $100 - **Horizonte**: por ejemplo, 24 meses El bot ejecuta `cadencia × horizonte` compras, una por período. Sin lógica de salida. El resultado es una posición con una base de costo igual a la media aritmética de los precios de cierre de cada período. Dos propiedades del DCA clásico vale la pena absorber: 1. **Siempre tiene un rendimiento inferior al de una compra perfecta en la cima o en el fondo** — por construcción, porque el DCA promedia. Es la estrategia del "caso promedio". 2. **Siempre supera a la peor compra posible en la cima** y generalmente supera a la venta por pánico, porque el DCA elimina el punto de decisión donde la emoción se infiltra. En términos sencillos: está sacrificando parte del potencial alcista a cambio de supervivencia. ## DCA condicional (promediado de valor / martingala ligero) El DCA puramente basado en tiempo es una disciplina. El DCA condicional añade un disparador de precio y se acerca más a una estrategia: - **Compra base cada período** (DCA clásico) - **Compra extra cuando el precio está X% por debajo del promedio reciente** - **Omitir la compra cuando el precio está Y% por encima del promedio reciente** Esto inclina la acumulación hacia los mínimos y se aleja de los máximos, a costa de introducir parámetros a ajustar (X, Y, ventana del "promedio reciente"). En el extremo, se convierte en un sistema martingala — duplicar la apuesta en cada caída — que tiene modos de fallo conocidos cuando la caída es estructural y no transitoria. El bot DCA de Pulsar.INK soporta ambas variantes; el operador elige si agregar condiciones sobre el calendario base. ## El problema de la salida El DCA es fuerte en la acumulación y silencioso sobre la salida. Esto es una característica, no un error: la tesis de la estrategia es "creo que este activo valdrá más en mi horizonte que en mi base de costo". Cuando el operador alcanza el horizonte, él decide la salida — el DCA no lo hace por él. En la práctica se utilizan tres enfoques de salida: | Enfoque | Cuándo usar | Desventaja | |-----------------------|-----------------------------------------------|---------------------------------------------| | Mantener / autocustodia | Horizonte largo, sin necesidad de fiat | Riesgo de cola en el exchange o autocustodia | | DCA inverso de salida | Cuando el operador también quiere una salida mecánica | Limita el potencial alcista en la salida | | Disparador de ganancia | Salir todo cuando la posición está X% por encima de la base de costo | Un umbral raramente se ajusta a todo el ciclo | El encuadre honesto: si el operador no tiene regla de salida, el DCA ha construido una posición cada vez más valiosa sin una condición de éxito declarada. Eso es un problema de psicología, no de bot. ## DCA vs cuadrícula: ¿cuál en un mercado lateral? El DCA y grid-trading-strategy parecen similares a primera vista — ambos disparan compras programadas y ambos funcionan mejor sin fuertes tendencias — pero las apuestas subyacentes difieren: | Pregunta | DCA | Cuadrícula | |---------------------------------------|----------------------------------|----------------------------------| | ¿En qué estoy apostando? | Apreciación a largo plazo | Oscilación a corto plazo | | ¿Vendo dentro del período? | No (salvo salida condicional) | Sí, en cada nivel | | ¿Qué pasa si el precio cae? | Compro más a precios más bajos | La cuadrícula falla, la "bolsa" queda debajo | | ¿Qué pasa si el precio sube? | Tengo una posición que se aprecia | La cuadrícula vende, no hay más entrada | | Complejidad de ajuste | Mínima | Moderada a alta | En un mercado lateral, el DCA acumula lentamente una posición base, la cuadrícula cosecha ganancias de oscilación por encima. Pueden ser complementarios en lugar de competidores. ## Backtests y DCA Un backtest de DCA es el backtest más honesto que puede ejecutar — hay tan pocos parámetros que el sobreajuste es casi imposible — pero sigue siendo engañoso de una manera específica: depende del camino en la ventana de muestra. Un DCA de BTC empezando el 2020-01-01 parece excelente hasta el 2021-11. El mismo DCA empezando el 2021-11-01 parece terrible hasta el 2022-11. Véase backtesting-explained para la trampa general; para el DCA específicamente, la mitigación es hacer backtest con múltiples fechas de inicio a lo largo de un ciclo completo e informar la distribución, no el número único "de aquí a ahora". ## Notas de riesgo El DCA no hace que un activo malo sea bueno. Si la tesis del activo falla — el token es dado de baja, el protocolo es explotado, el equipo del proyecto desaparece — el DCA ha estado comprando durante toda la caída. El límite de risk-management-automated-trading para el DCA suele ser un **límite nominal total** por activo en lugar de por operación, porque por operación ya es pequeño por construcción. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — dónde encaja el DCA en la taxonomía más amplia. - grid-trading-strategy — la estrategia prima de cosecha de oscilaciones. - risk-management-automated-trading — el único límite que importa para el DCA. - backtesting-explained — la trampa de dependencia del camino. ### es/kb/exchange-api-key-security.md Source: https://pulsar.ink/es/kb/exchange-api-key-security.html # Seguridad de claves API del exchange Una **clave API** es un par de credenciales (clave + secreto) emitido por un exchange que permite a un programa externo actuar en la cuenta del exchange del propietario. En el contexto del trading automático (véase what-is-automated-crypto-trading), la plataforma tiene la clave y la usa para enviar órdenes en nombre del operador. La clave es el objeto más susceptible de abuso en todo el stack. Los fondos nunca salen del exchange para entrar en la plataforma, pero la clave aún puede causar daño real si tiene un alcance incorrecto. Obtener el alcance correcto es el primer paso no negociable de cada integración de exchange. ## La única regla **El permiso de retiro NO DEBE habilitarse en la clave API.** Esta regla es absoluta. Cada exchange importante divide los permisos en al menos tres clases — Lectura, Trading, Retiro — y la plataforma solo necesita Lectura y Trading. No hay ninguna razón legítima para que un bot de trading tenga Retiro; la plataforma no necesita mover fondos fuera del exchange para hacer su trabajo. Cuando el Retiro está desactivado, lo peor que puede hacer una clave comprometida es operar contra la cuenta (perder dinero ante un contra-bot de creador de mercado prearreglado es el ataque clásico). Eso es daño real, pero el principal de la cuenta sigue en el exchange y es recuperable a través del soporte del exchange y las ventanas de liquidación activadas por límite de velocidad. Cuando el Retiro está activado, el atacante puede vaciar la cuenta en una sola transacción. La pérdida es irreversible. ## Alcance mínimo de permisos Los nombres exactos difieren según el exchange, pero cada plataforma solo debe solicitar estas clases: | Permiso | Nombre típico en distintas plataformas | ¿Requerido? | |---------------------------------|------------------------------------------------------|----------------------------| | Leer saldos de cuenta | "Read Info" / "Account" / "Query" | Sí | | Leer historial de órdenes | "Read Orders" / "History" | Sí | | Colocar y cancelar órdenes | "Trade" / "Spot Trading" / "Margin Trading" | Sí | | Retirar fondos | "Withdraw" / "Transfer" | **NO** | | Habilitar margen | "Margin" / "Futures" | Solo si la estrategia lo necesita | | Habilitar futuros | "Derivatives" / "Perpetual" | Solo si la estrategia lo necesita | | Transferencia interna de subcuenta | "Universal Transfer" | **NO** (casi siempre) | El operador debe verificar las casillas de permisos en la UI del exchange contra esta lista cada vez que se crea o rota una clave. ## Lista de IP permitidas La mayoría de los exchanges importantes permiten al operador vincular la clave API a una **lista de IP permitidas fija**. Una orden enviada desde una IP fuera de la lista es rechazada. Pulsar.INK, como la mayoría de las plataformas, publica las IPs de salida de los servidores de trading para que los operadores puedan poner exactamente esas IPs en la lista permitida. Si la lista permitida del operador está vacía `[]`, la clave es usable desde cualquier lugar y la seguridad efectiva de las credenciales es la mitad de lo que debería ser. Compensaciones: - **Lista permitida fija + el operador pega la clave.** Mejor seguridad; la plataforma debe publicar y mantener sus IPs de salida; el operador vuelve a pegar la clave cuando la lista cambia. - **Sin lista permitida.** Fácil de configurar; el radio de explosión del robo de clave es todo el internet; evitar absolutamente a menos que el exchange no soporte listas permitidas. Para estrategias de arbitraje que se ejecutan en múltiples plataformas, véase arbitrage-bots — el flujo de transferencia entre plataformas es un lugar donde los operadores a veces se sienten tentados a activar el Retiro por "comodidad". No lo haga. Use transferencias manuales o una subcuenta interna si se necesita reequilibrio entre plataformas. ## Cadencia de rotación Las claves API deben rotarse en una cadencia. La cadencia mínima razonable: - **Cada 90 días** para claves en cuentas de solo trading. - **Inmediatamente** si ocurre alguno de estos eventos: - El operador sospecha que la clave se filtró. - El operador cambió su cuenta de Telegram (véase telegram-native-trading-ux para saber por qué esto importa). - La plataforma divulga un incidente de seguridad. - El exchange notifica actividad inusual. La rotación es una operación de baja fricción en Pulsar.INK: nueva clave emitida en el exchange, pegada en la interfaz de Telegram, clave antigua revocada en el exchange. La plataforma no cachea claves antiguas. ## Manejo del secreto en el lado de la plataforma La clave y el secreto del operador están cifrados en reposo en la plataforma y son usados solo por el servicio específico de envío de órdenes. Nunca se escriben en logs, nunca se muestran en mensajes de UI después de la entrada, y nunca se emiten a terceros. Desde la perspectiva del operador, los controles de protección son: 1. **Nunca copie el secreto en ningún chat, ticket o correo electrónico** — incluido el soporte de la plataforma. El soporte nunca pide el secreto. 2. **Nunca pegue el secreto en un formulario servido sobre HTTP** (en lugar de HTTPS). La Telegram Mini App es solo HTTPS por diseño. 3. **Revoque la clave** si alguna vez se copió y pegó en algo que no sea la pantalla de entrada de clave de la plataforma. El costo de la rotación es bajo; el costo de una clave filtrada es muy alto. ## Qué hacer si una clave se ve comprometida El compromiso no es solo "perdí la clave". También cubre: - Un dispositivo que tiene la clave se perdió o fue robado. - Un gestor de contraseñas que tiene la clave fue accedido por otra persona. - La clave aparece en cualquier log, mensaje o archivo compartido con otra parte. Pasos: 1. **Revocar la clave en el exchange** (camino más rápido — generalmente un clic). 2. **Pausar todas las estrategias en Pulsar.INK** (interruptor de emergencia en Telegram). 3. **Revisar órdenes abiertas y posiciones** para entradas que el operador no colocó. 4. **Contactar el soporte del exchange** si hay evidencia de operaciones no autorizadas. 5. **Rotar cualquier credencial compartida** (contraseña de Telegram, PINs a nivel de dispositivo) si la vía del compromiso aún no se conoce. 6. **Emitir una nueva clave** con una nueva lista de IP permitidas; reactivar las estrategias solo después de verificar que el compromiso anterior está contenido. El marco de risk-management-automated-trading también aplica aquí: el límite de pérdida diaria por cuenta generalmente se activará mucho antes de que un atacante haya podido cross-tradear la cuenta hasta la ruina. Ese límite es el último recurso cuando todos los demás controles fallan. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — el contexto más amplio. - telegram-native-trading-ux — la mitad Telegram del perímetro de seguridad. - risk-management-automated-trading — límites de pérdida que sobreviven al compromiso de credenciales. - arbitrage-bots — la estrategia más propensa a tentar a los operadores a configurar incorrectamente las claves. ### es/kb/grid-trading-strategy.md Source: https://pulsar.ink/es/kb/grid-trading-strategy.html # Estrategia de trading en cuadrícula El **trading en cuadrícula** coloca una escalera de órdenes de compra y venta en niveles de precios precalculados a lo largo de un rango y obtiene ganancias del mercado al oscilar hacia arriba y hacia abajo entre esos niveles. A diferencia de las estrategias direccionales, la cuadrícula **no** requiere una visión sobre hacia dónde va el precio, solo sobre el rango en el que permanecerá. Esto hace de las cuadrículas la estrategia automática de "cero visión" más popular (véase what-is-automated-crypto-trading) para mercados laterales o con choppy. ## La mecánica central Supongamos que BTC/USDT cotiza a $50,000 y espera que oscile entre $45,000 y $55,000 durante las próximas semanas. Usted define: - **Rango**: $45,000 a $55,000 - **Tamaño de cuadrícula**: 10 niveles (paso = $1,000) - **Tamaño de orden por nivel**: 0,01 BTC El bot coloca: - Órdenes de compra en $49,000, $48,000, $47,000, $46,000, $45,000 - Órdenes de venta en $51,000, $52,000, $53,000, $54,000, $55,000 Cada vez que el precio baja a través de un nivel, la orden de compra correspondiente se ejecuta — y el bot inmediatamente coloca una nueva orden de venta un paso por encima. Cada vez que el precio sube a través de un nivel, la venta se ejecuta y una nueva compra entra un paso por debajo. Cada ciclo completo (compra a $49,000, venta a $50,000) es una ganancia asegurada de $1,000 × 0,01 = $10, menos comisiones. ## Teoría del rango La rentabilidad de la cuadrícula proviene enteramente de la volatilidad dentro del rango declarado. Dos parámetros interactúan: | Parámetro | Efecto en la ganancia por ciclo | Efecto en el número de ciclos | |--------------------|----------------------------------------------------|-----------------------------------------------| | Rango más amplio | Igual (ganancia por paso sin cambios) | Menos ejecuciones durante una oscilación típica | | Cuadrícula más densa | Menor ganancia por ciclo | Más ejecuciones durante una oscilación típica | | Mayor volatilidad | Igual | Más ejecuciones en una ventana de tiempo dada | La ventaja de la cuadrícula es aproximadamente: ``` ganancia_esperada ≈ (niveles_cruzados_por_día) × (ganancia_por_nivel - comisiones) ``` por lo que el operador está implícitamente apostando a una combinación de (rango se mantiene) × (suficiente volatilidad dentro del rango) × (comisión del exchange pequeña en relación al tamaño del paso). ## El equilibrio de la densidad de la cuadrícula Una cuadrícula demasiado dispersa y el bot está inactivo durante pequeños movimientos. Una cuadrícula demasiado densa y la ganancia de cada ciclo cae por debajo del nivel de comisiones y la estrategia sangra lentamente. Una regla general común: el tamaño del paso debería ser al menos **4× la comisión de taker unidireccional** para dar a un ciclo completo (dos ejecuciones de taker) un margen de 2× sobre las comisiones. Para una comisión de taker del 0,1%, eso es un paso de al menos 0,4%. Por debajo de eso, la cuadrícula está trabajando para el exchange, no para el operador. ## Las matemáticas de la caída que nadie menciona en Twitter Una cuadrícula parece perfecta **mientras el precio permanece en el rango**. Cuando el precio sale del rango, la cuadrícula repentinamente mantiene una posición desequilibrada: - Si el precio cae por debajo del límite inferior, todas las órdenes de compra se ejecutaron y ninguna venta las compensó. El bot mantiene la máxima posición larga prevista al peor precio promedio posible. - Si el precio supera el límite superior, todas las ventas se ejecutaron (si la estrategia vende en corto) o la estrategia está completamente fuera del mercado (si solo va en largo). De cualquier manera, ha dejado de acumular ganancias. Tamaño máximo de la "bolsa" en la ruptura del rango: ``` bolsa_máxima = tamaño_orden × número_de_niveles_compra pérdida_no_realizada_en_ruptura = suma de (precio_ejecución - precio_actual) × tamaño_orden — para todas las compras ejecutadas ``` Un ejemplo concreto: rango $45k–$55k, 10 niveles de compra de 0,01 BTC. El precio cae a $30k. El bot tiene 0,05 BTC (cinco niveles inferiores todos ejecutados), comprados a un promedio de alrededor de $47k. Pérdida no realizada: aproximadamente 0,05 × $17,000 = $850 con $2,350 de capital desplegado, o una caída del 36%. Una cuadrícula que ganaba silenciosamente $10 por ciclo acaba de devolver las ganancias de 85 ciclos en una sola ruptura de rango. Por eso las cuadrículas son inseparables de risk-management-automated-trading: - **Stop-loss por debajo del límite inferior** — aceptar que la cuadrícula falló y cerrar la posición, en lugar de promediar hacia abajo para siempre. - **Límite de posición** — el capital total desplegado por la cuadrícula está acotado, no es una fracción fija del capital; la ruptura de una cuadrícula no debería acabar con la cuenta. - **Cadencia de revisión del rango** — redefinir el precio del rango semanalmente o en cualquier evento de cambio de régimen, no "cuando se rompa". ## Tipos de cuadrícula | Tipo | Descripción | Mejor para | |------------|-----------------------------------------------------------------------|-----------------------------------| | Aritmética | Espaciado en dólares igual entre niveles | Mercados estables y de volatilidad moderada | | Geométrica | Espaciado porcentual igual entre niveles | Activos de mayor volatilidad | | Infinita | Sin límite superior; sigue añadiendo niveles de venta conforme sube el precio | Especuladores en fuerte tendencia alcista | | Inversa | Posiciones cortas en lugar de largas; ganancias en rango en régimen bajista | Solo para operadores experimentados | | Dinámica | El rango se recalcula a partir del ATR reciente o las bandas de Bollinger | Adaptativo a cambios de régimen | Pulsar.INK soporta cuadrículas aritméticas, geométricas y dinámicas. ## Cuándo fallan las cuadrículas Tres regímenes destruyen las cuadrículas en orden creciente de gravedad: 1. **Baja volatilidad / movimiento lateral extremo.** Las ejecuciones son demasiado infrecuentes; el costo de oportunidad del capital desplegado supera los retornos de la cuadrícula. La solución del operador es reducir el tamaño de la cuadrícula o redirigir el capital a dca-bot-strategy / otras estrategias. 2. **Mercado en tendencia.** El precio sale del rango en una dirección; la cuadrícula es unilateral y deja de acumular ganancias. La solución del operador es el reconocimiento temprano (filtro de tendencia sobre la cuadrícula) y la redeclaración del rango. 3. **Flash crash / evento de noticias.** La ruptura del rango ocurre más rápido de lo que el operador puede responder, y el stop-loss (si lo hay) se activa a un precio mucho peor que su nivel declarado debido al gap. La mitigación del operador es un límite de posición fijo: incluso después del gap, la pérdida absoluta en dólares está acotada por `tamaño_orden × niveles_compra × (ancho_rango + slippage_gap)`. Los backtests (véase backtesting-explained) subestiman sistemáticamente los tres modos de fallo porque utilizan datos de tick idealizados, no los libros de órdenes delgados que existen durante los crashes reales. Un backtest "100% rentable" sin caídas debe interpretarse como "esta estrategia nunca ha sido sometida a estrés", no como "esta estrategia es segura". ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — donde las cuadrículas encajan en la taxonomía de estrategias más amplia. - dca-bot-strategy — la estrategia primo orientada a la acumulación. - risk-management-automated-trading — no opcional para las cuadrículas. - backtesting-explained — por qué los backtests de cuadrículas son los más engañosos. ### es/kb/risk-management-automated-trading.md Source: https://pulsar.ink/es/kb/risk-management-automated-trading.html # Gestión de riesgo en el trading automático Una estrategia describe **qué** hará el bot. La gestión de riesgo describe **cuánto** de la cuenta puede dañar el bot antes de ser detenido. En el trading manual, los dos a menudo se colapsan en un solo juicio. En el trading automático deben separarse, porque el bot no hace pausa para reconsiderar. Esta página es deliberadamente aburrida. El contenido no es inteligente; es el conjunto de límites que separan a los operadores que sobreviven de los que no. ## Las tres capas Piense en la gestión de riesgo como tres capas independientes, cada una de las cuales debe activarse sola sin requerir las otras: 1. **Límite por operación.** La pérdida máxima en cualquier operación individual está acotada por un stop-loss precolocado o el tamaño de la posición. Una sola operación catastrófica no puede superar este límite. 2. **Límite por estrategia.** La pérdida acumulada máxima de cualquier estrategia individual durante una ventana móvil (día / semana / mes) está acotada. Cuando se alcanza, la estrategia se pausa para revisión humana. 3. **Límite de cuenta.** La pérdida acumulada máxima en **todas** las estrategias está acotada. Cuando se alcanza, cada estrategia en la cuenta se pausa. Cada límite tiene su propio umbral de alerta (por ejemplo, al 80% del límite) para que el operador reciba una advertencia antes de que se active el límite, no después. ## Dimensionamiento de posiciones Tres reglas de dimensionamiento están en uso práctico. Elija una por estrategia y escríbala. ### 1. Fracción fija (la más simple) ``` tamaño_posición_nominal = capital_cuenta × fracción_riesgo ``` Con `fracción_riesgo` generalmente del 1–2% para una operación de convicción, 0,25–0,5% para una operación de señal de una fuente de terceros. Esto ignora la volatilidad y la distancia del stop, lo que es una debilidad, pero es la regla que sobrevive más tiempo a los errores del operador. ### 2. Paridad de riesgo (ajustada por volatilidad) ``` tamaño_posición_nominal = (capital_cuenta × riesgo_por_operación) / (distancia_stop_porcentaje) ``` El tamaño de la posición es inversamente proporcional a la distancia del stop, por lo que una operación con stop ajustado es más grande y una operación con stop amplio es más pequeña. Esto iguala el riesgo en dólares entre configuraciones, pero requiere que el operador coloque stops honestos e informados. ### 3. Fracción de Kelly (avanzado, fácil de usar incorrectamente) ``` fracción_kelly = tasa_victorias - (1 - tasa_victorias) / ratio_pago tamaño_posición_nominal = capital_cuenta × (fracción_kelly × escala_kelly) ``` Con `escala_kelly` generalmente de 0,25–0,5 ("Kelly fraccional") porque el Kelly completo solo es óptimo si sus estimaciones de tasa de victorias y pago son exactamente correctas, y nunca lo son. La mayoría de los operadores minoristas no deberían usar esta regla porque estimar `tasa_victorias` y `ratio_pago` a partir de un historial en vivo corto produce números terribles. ## Límites de caída máxima El único parámetro de gestión de riesgo más importante es el **límite de caída máxima** por estrategia y por cuenta. Una caída del 20% requiere una recuperación del 25%; una caída del 50% requiere una recuperación del 100%; una caída del 90% requiere una recuperación del 900%. El interés compuesto es simétrico en porcentaje pero asimétrico en dólares. Configuraciones minoristas conservadoras: | Límite | Por estrategia | Por cuenta | |------------------|----------------|------------| | Pérdida diaria | 3% | 2% | | Pérdida semanal | 7% | 5% | | Pérdida mensual | 15% | 10% | Cuando se alcanza, la estrategia (o la cuenta) se pausa hasta que el operador revise y vuelva a habilitarla explícitamente. La pausa es no negociable; es lo que evita que una semana mala se convierta en un año malo. ## Interruptores de emergencia Cada estrategia debería tener al menos dos interruptores de emergencia independientes: 1. **Local de la estrategia.** El bot mismo tiene lógica de caída que detiene la estrategia cuando se activa el límite. Requiere que el bot esté activo y leyendo datos de mercado. 2. **A nivel de plataforma.** Un observador externo (la plataforma Pulsar.INK) puede pausar una estrategia independientemente de lo que piense la estrategia. Se usa para interrupciones del exchange, límites de caída a nivel de cuenta y revocación de claves API. Depender solo del interruptor de emergencia local de la estrategia es como los operadores pierden mucho durante las interrupciones de infraestructura — el bot está colgado, nada lo detiene porque nada está funcionando. ## Radio de explosión por estrategia Cuando múltiples estrategias comparten una cuenta, el radio de explosión de una estrategia se convierte en un riesgo sistémico para las otras. El limitador de radio de explosión más simple es la **asignación de capital**: declarar de antemano el nominal máximo que una estrategia puede mantener en cualquier momento y rechazar cualquier orden que lo viole. Ejemplo de asignación para una cuenta de $10,000: - 40% Bot DCA en BTC y ETH ($4,000) - 25% Bot de cuadrícula en BTC/USDT ($2,500) - 20% Bot de señales en alt majors ($2,000) - 15% Reserva (nunca desplegada) ($1,500) La reserva es no negociable. Es el colchón para las llamadas de margen, para una reentrada oportunista tras una pausa por límite de caída, y para el costo del error que está en la estrategia que aún no ha descubierto. ## Integración con los nodos de estrategia Cada familia de estrategias en esta base de conocimientos tiene su propio perfil de riesgo específico: - grid-trading-strategy — el riesgo dominante es la ruptura del rango; el límite es un stop fijo por debajo del rango, no un límite suave de caída. - dca-bot-strategy — el riesgo dominante es acumular un activo muerto; el límite es un límite nominal total por activo, no por operación. - arbitrage-bots — el riesgo dominante es contraparte / transferencia; el límite es un límite de capital por plataforma más una prueba diaria de retiro. - signal-trading-bots — el riesgo dominante son las malas señales; el límite es tanto un límite de riesgo por operación como un límite de PnL móvil sobre la fuente de señal. - copy-trading-explained — el riesgo dominante es el cambio de comportamiento del líder; el límite es una revisión de PnL móvil y una cadencia de revisión limitada en el tiempo. Cada estrategia opera bajo su propio conjunto de límites, más el límite a nivel de cuenta que se aplica a todas ellas. ## El bucle de revisión humana La gestión de riesgo no son solo parámetros. También es la cadencia de revisión: - **Diariamente:** un vistazo rápido al PnL de cada estrategia y la ratio PnL / límite. Cualquier cosa por encima del 80% del límite recibe atención. - **Semanalmente:** revisar las operaciones cerradas y las ejecuciones. ¿Son lo que la estrategia pretendía? El comportamiento inesperado es una señal más fuerte que la pérdida inesperada. - **Mensualmente:** revalidar la tesis de la estrategia. ¿El régimen de mercado sigue siendo uno para el que se diseñó esta estrategia? Si no, pausar. - **Trimestralmente:** reequilibrar la asignación entre estrategias; retirar las que tuvieron un rendimiento inferior a su tesis durante dos trimestres consecutivos. Este bucle es lo que convierte el trading automático de "una apuesta" en "una operación". ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — el contexto más amplio. - backtesting-explained — por qué ningún backtest captura el panorama completo de riesgo. - exchange-api-key-security — el riesgo a nivel de credenciales que subyace a todos estos y no está valorado en ningún otro lugar. ### es/kb/signal-trading-bots.md Source: https://pulsar.ink/es/kb/signal-trading-bots.html # Bots de trading por señales Un **bot de trading por señales** recibe una señal de una fuente externa y actúa sobre ella enviando una orden contra la cuenta del exchange del operador. El operador elige la fuente de señal; el bot es el ejecutor disciplinado que no cuestiona la señal. Este es el pariente más cercano al copy trading (véase copy-trading-explained), pero la fuente de señal suele ser un conjunto de reglas, un feed o un webhook en lugar de la cuenta en vivo de otro trader. ## Taxonomía de señales | Tipo de señal | Ejemplo | ¿Auditable? | Cadencia típica | |-------------------------|--------------------------------------------------------|-------------|-------------------| | Indicador técnico | RSI cruzando 30, giro del histograma MACD | Sí | Segundos a horas | | Regla de price-action | Cierre por encima del máximo de 20 días (ruptura Donchian) | Sí | Diaria | | Webhook de TradingView | Cualquier script personalizado que emite alertas via HTTPS | A veces | Variable | | Canal de Telegram | Analista humano publica "BUY BTC 50000 SL 48000" | No | Irregular | | Modelo propio | Tu propio script Python que emite señales JSON | Sí | Completamente variable | | API de terceros | Endpoint de proveedor que devuelve compra/venta en horario | Raramente | Dependiente del proveedor | Pulsar.INK puede consumir señales de las primeras cinco vía endpoint webhook o chat integrado con Telegram. El operador decide en qué categoría de fuente confiar, y la decisión de confianza es una preocupación de riesgo de primer orden — véase más adelante. ## La política de ejecución importa tanto como la señal Una señal dice "COMPRA". El bot tiene que decidir: - **Método de entrada.** ¿Orden de mercado, límite al precio de señal, límite con X pbs de slippage, TWAP durante Y minutos? - **Tamaño de posición.** ¿Nominal fijo, porcentaje del capital, normalizado por volatilidad, fracción de Kelly? - **Colocación del stop-loss.** ¿Usar el SL de la señal (si lo hay)? ¿Usar un múltiplo de ATR? ¿Un porcentaje fijo? - **Colocación del take-profit.** La misma pregunta, en la dirección contraria. - **Manejo de señales duplicadas.** Si la misma señal se vuelve a emitir durante una posición abierta, ¿se amplía, ignora o se cierra y revierte? Dos operadores usando la misma fuente de señal pueden producir PnL radicalmente diferentes simplemente eligiendo diferentes políticas de ejecución. Esta es la parte que la mayoría de los consumidores de señales subestiman. Una buena línea base: - Órdenes límite al precio de señal con un slippage máximo de 15 pbs - Sizing de porcentaje fijo del capital (p.ej. 2% por señal) - SL a 1,5× ATR(14) o el SL explícito de la señal, el que sea más ajustado - TP a 1,0× ATR(14) trailing, o ninguno (dejar que la fuente de señal emita la salida) - Ignorar señales duplicadas mientras una posición está abierta ## La trampa del sesgo de supervivencia Las fuentes de señal públicas son un ranking de supervivientes. Los proveedores de señales que produjeron pérdidas se callaron; los restantes produjeron ganancias. El backtest en su sitio web comienza desde el día en que su estrategia empezó a funcionar, no desde el día en que iniciaron el proyecto. Antes de suscribirse a cualquier fuente de señal externa, un operador debería: 1. Pedir un registro completo de señales con marca de tiempo que cubra ≥12 meses, idealmente ≥24, incluyendo señales que no produjeron ganadores. 2. Calcular el PnL de ese registro usando la propia política de ejecución del operador, no la del proveedor. 3. Verificar que el proveedor no eliminó perdedores del registro (las brechas de tiempo son una pista). 4. Simular un **modelo de slippage pesimista**: en mercados líquidos, bid en vez de mid; en ilíquidos, bid menos X pbs. Si el proveedor no puede proporcionar el registro, la fuente de señal es una apuesta no auditada a la reputación. Eso puede seguir siendo una apuesta válida; simplemente no es una basada en datos. Véase backtesting-explained para el patrón general de supervivencia y por qué el sesgo de look-ahead es la trampa hermana estrechamente relacionada. ## Por qué el ejecutor NO debe razonar sobre la señal Una vez que un operador ha elegido confiar en una fuente de señal, los únicos trabajos del ejecutor son: - **Recibir la señal con prontitud.** El presupuesto de latencia para una buena captura de señal es típicamente de 100–500 ms. - **Aplicar la política de ejecución de forma determinista.** Sin anulación "creo que esta está equivocada". - **Registrar el resultado.** Cada señal, cada ejecución, cada slip — porque ese registro es la entrada al siguiente ciclo de revisión. Un ejecutor que "mejora" señales con su propia discreción combina la incertidumbre del proveedor de señales con las anulaciones emocionales del operador. Así muere el trading de señales minorista. La disciplina es: elige la fuente, elige la política, ejecuta mecánicamente, revisa en una cadencia, cambia fuentes o políticas en la revisión — no durante las operaciones. ## Relación con el copy trading El copy trading (véase copy-trading-explained) es un caso degenerado del trading de señales donde la "señal" es "lo que hizo esta cuenta líder". Todo lo anterior sigue aplicando — política de ejecución, sesgo de supervivencia, registro de auditoría — pero la observabilidad de la señal es peor, porque el líder puede cambiar de estrategia de la noche a la mañana y el seguidor no puede ver el razonamiento. El trading de señales con un conjunto de reglas auditable es estrictamente más transparente que el copy trading, por eso es la mejor opción por defecto para los operadores que quieren entender lo que están haciendo. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — la categoría más amplia. - copy-trading-explained — la variante basada en identidad. - risk-management-automated-trading — los límites que acotan la capacidad de cualquier fuente de señal para dañar la cuenta. - backtesting-explained — la disciplina de supervivencia / look-ahead / período de muestra necesaria para auditar cualquier fuente. ### es/kb/telegram-native-trading-ux.md Source: https://pulsar.ink/es/kb/telegram-native-trading-ux.html # UX de trading nativa en Telegram Pulsar.INK está diseñado alrededor de una interfaz **nativa en Telegram**: el operador no crea una contraseña, no instala una aplicación separada y no necesita una pantalla de trading dedicada. Todo lo que la plataforma puede hacer — conectar exchanges, habilitar estrategias, ajustar parámetros, pausar, revisar el PnL — ocurre dentro de una conversación de Telegram. Esta página explica por qué se tomó esa decisión y cuáles son las implicaciones de diseño. ## Por qué Telegram Los usuarios de cripto ya viven en Telegram. La comunidad, las señales, el soporte y las actualizaciones fluyen a través de la misma aplicación, por lo que una interfaz de trading que comparte la superficie elimina un cambio de contexto. Más concretamente: - **Ubicua, multiplataforma.** Funciona de forma idéntica en iOS, Android, macOS, Windows, Linux y web. Sin dependencia de aprobación de tienda de aplicaciones y sin riesgo de exclusión regional de App Store. - **Notificaciones push nativas.** Cada alerta que emite la plataforma llega al operador en todos los dispositivos en los que usa Telegram, sin un canal de notificación separado. - **El registro de chat es el registro de auditoría.** Cada comando, cada cambio de parámetro, cada notificación está permanentemente en el historial de conversación. El operador no necesita mantener un registro separado. - **El modelo de autenticación está prestado.** La seguridad de la propia cuenta de Telegram (2FA, contraseña en la nube, confirmación a nivel de dispositivo) se convierte en el perímetro de seguridad de la plataforma — no lo reconstruimos. ## Superficie de autenticación El flujo de autenticación es el inicio de sesión de la **Mini App** de Telegram: 1. El operador abre la plataforma en Telegram. 2. Telegram emite un payload `initData` firmado que identifica el ID de usuario de Telegram del operador, la sesión y el dispositivo. 3. El servidor de la plataforma verifica la firma usando el secreto del bot y trata el ID de usuario de Telegram como la identidad de la plataforma. 4. Todas las acciones subsiguientes ocurren en el contexto de esa identidad. **No hay contraseña del lado de la plataforma**, y por tanto no hay contraseña del lado de la plataforma que robar, restablecer o phishear. Existe una compensación: si la cuenta de Telegram del operador se ve comprometida, el atacante hereda la sesión de la plataforma. Las mitigaciones viven en la capa de Telegram (2FA, contraseña en la nube, auditoría de dispositivos recientes) y en la capa del exchange (exchange-api-key-security mantiene el retiro desactivado, por lo que lo peor que puede hacer un atacante es cruzar operaciones en la cuenta en lugar de vaciarla). Véase también risk-management-automated-trading para diseños de kill-switch que no dependen de que Telegram sea accesible — la plataforma debe seguir siendo detenible si el operador pierde acceso a su teléfono. ## UX ordenada por mensajes Una interfaz chat-primero ordena las acciones por tiempo, no por navegación. El operador ve lo último que ocurrió en la parte inferior de la pantalla, con el historial completo arriba. Específicamente para trading: - Los mensajes de **cambio de estrategia** incluyen el diff de parámetros (antiguo → nuevo) para que el operador pueda desplazarse hacia atrás y entender qué cambió. - Los mensajes de **ejecución** incluyen precio, tamaño, comisiones y un delta de PnL desde el último mensaje. - Los mensajes de **alerta** están marcados por severidad (info / aviso / crítico) y las alertas críticas se vuelven a fijar automáticamente. La disciplina de UX aquí es mantener los mensajes **autodescriptivos** — un usuario debería poder entender una alerta de un mes de antigüedad sin abrir ninguna otra pantalla. Una plataforma de trading que hace que el usuario excave es una plataforma de trading que pierde alertas. ## Presupuesto de notificaciones Un bot de trading con muchas notificaciones entrena a los operadores a ignorar las notificaciones. El objetivo de diseño de Pulsar.INK es aproximadamente: | Clase de evento | Cadencia de notificación | |----------------------------------------------|-----------------------------------| | Cada ejecución individual | Desactivado por defecto; opt-in | | Resumen de PnL acumulado | Resumen diario, opcional | | Umbral de caída próximo | Inmediato, no suprimible | | Límite de caída activado / estrategia pausada | Inmediato, no suprimible | | Clave API a punto de expirar | 72h de antelación, luego 24h | | Interrupción del exchange detectada | Inmediato | | Evento de seguridad (IP inusual, rotación de clave) | Inmediato, no suprimible | El principio es: **los eventos rutinarios se consultan, los eventos críticos se envían**. Una revisión diaria es elección del operador; una alerta de límite de caída activado no lo es. ## ¿Por qué no un panel web? Pulsar.INK sí expone un panel web de solo lectura para revisiones más profundas (historial largo de PnL, comparación multi-estrategia, exportación). Pero la **superficie de control** vive en Telegram, porque una superficie de control que requiere que el operador inicie sesión en otro lugar es una superficie de control que se usa menos. Menos uso de la superficie de control significa reacciones más lentas a los problemas, lo que significa pérdidas realizadas mayores. ## Compensaciones de la interfaz nativa en Telegram El diseño no está libre de desventajas: - **Acceso regional.** Telegram está bloqueado o limitado en algunas jurisdicciones. Los operadores en esas regiones necesitan una VPN además de los propios mecanismos anti-bloqueo de Telegram. - **Interrupciones de Telegram.** Cuando Telegram está caído, la superficie de control se degrada. La propia infraestructura de kill-switch de la plataforma sigue operando (véase risk-management-automated-trading), pero el operador no puede ajustar estrategias durante la interrupción. - **Recuperación de cuenta de Telegram.** Si el operador pierde su cuenta de Telegram, la recuperación es un proceso del lado de Telegram, no de Pulsar.INK. La plataforma no puede restaurar el acceso a alguien que no puede demostrar que es el mismo usuario de Telegram. Cada una de estas es aceptable dados los objetivos de diseño; los operadores deben conocerlas de antemano en lugar de encontrarlas en medio de una crisis. ## Lectura adicional en esta base de conocimientos - what-is-automated-crypto-trading — la función principal de la plataforma. - exchange-api-key-security — la defensa en profundidad a nivel de credenciales. - risk-management-automated-trading — la pila de kill-switch que funciona cuando Telegram no lo hace. ### es/kb/what-is-automated-crypto-trading.md Source: https://pulsar.ink/es/kb/what-is-automated-crypto-trading.html # ¿Qué es el trading automático de criptomonedas? **El trading automático de criptomonedas** es la práctica de ejecutar órdenes de compra y venta en un exchange de criptomonedas mediante software que sigue un conjunto de reglas predeclaradas, en lugar de hacerlo mediante la discreción humana en el momento. El conjunto de reglas —normalmente denominado **estrategia** o **bot**— funciona continuamente, recibe datos de mercado como entrada y emite órdenes como salida. El operador (usted) decide tres cosas de antemano: 1. **Qué mercado** operará el bot (por ejemplo, `BTC/USDT` en un exchange específico, o una cesta de activos en varias plataformas). 2. **Qué reglas** seguirá el bot (cuadrícula, DCA, señal de momentum, arbitraje, copia, reequilibrio — consulte los nodos específicos de estrategia en grid-trading-strategy, dca-bot-strategy, copy-trading-explained, arbitrage-bots). 3. **Qué límites de riesgo** detienen el bot (máxima caída, tamaño máximo de posición, pausas por hora del día — véase risk-management-automated-trading). Una vez declarados estos tres aspectos, el bot opera sin que usted esté en línea. ## Cómo se diferencia del trading manual | Dimensión | Trading manual | Trading automático | |---------------------|-----------------------------------------------|----------------------------------------------------------| | Latencia decisional | Segundos a minutos (reacción humana) | Milisegundos (ida y vuelta del API) | | Consistencia | El estado de ánimo, el cansancio y el sueño afectan los resultados | Idéntico a la regla cada tick, para bien o para mal | | Cobertura | Las horas en que usted está despierto frente a una pantalla | 24/7, en decenas de mercados en paralelo | | Anulación emocional | Frecuente; a menudo la mayor fuente de pérdidas | Imposible salvo intervención del operador | | Modo de fallo | Generalmente pequeño y recuperable | Potencialmente grande y rápido si los límites de riesgo están mal configurados | La consistencia opera en ambos sentidos. La automatización elimina la principal fuente de pérdidas minoristas (venta por pánico, operación vengativa). También elimina el mecanismo de recuperación: si la regla es incorrecta, el bot seguirá aplicándola a velocidad de máquina hasta que se active un límite de riesgo. Por eso risk-management-automated-trading no es una nota al pie: es la estrategia en sí. ## Las tres clases de riesgo Un modelo mental útil es que todo operador de trading automático asume tres riesgos simultáneos: 1. **Riesgo de mercado** — el activo se mueve en contra de la tesis de la estrategia. Este es el riesgo que usted tiene la intención de asumir, y para el que se construye la estrategia. 2. **Riesgo de infraestructura** — el bot no puede conectarse al exchange (su VPS está caído, el API tiene límite de velocidad, un certificado ha expirado). Las órdenes no se ejecutan, o se ejecutan dos veces. Pensó que estaba fuera del mercado; sigue dentro. 3. **Riesgo de credenciales** — la clave API que usa el bot ha sido robada, mal utilizada o tiene permisos incorrectos. La mejor estrategia del mundo no vale nada si la clave permite retirar fondos. El tratamiento de este riesgo es el tema de exchange-api-key-security. Una plataforma le quita parte de este peso de encima: | Clase de riesgo | Lo que gestiona el operador | De lo que se encarga Pulsar.INK | |------------------|---------------------------------------|--------------------------------------------------| | Mercado | Elección de estrategia + parámetros | Motor de ejecución, normalización de flujo de datos | | Infraestructura | Disponibilidad de cuenta Telegram (mínima) | VPS, conmutación por error, conciliación de órdenes, reintentos | | Credenciales | Configuración de permisos del API en el exchange | Cifrado en tránsito, sin uso de permiso de retiro | ## Dónde encaja Pulsar.INK Pulsar.INK es la **capa de ejecución**. No custodia sus monedas — estas permanecen en su exchange. Tiene una clave API con permisos de **solo trading** (véase exchange-api-key-security para la lista de permisos obligatorios) y ejecuta las estrategias que usted ha habilitado contra esa clave. El inicio de sesión es nativo de Telegram (véase telegram-native-trading-ux): el operador conecta su cuenta de Telegram, vincula una o más cuentas de exchange mediante clave API, elige una plantilla de estrategia, ajusta los parámetros y la activa. El trabajo de la plataforma es hacer que cada estrategia sea observable e interrumpible desde un teléfono, porque los mercados de criptomonedas no respetan los horarios de oficina. ## Lo que "automático" *no* significa No significa "ingreso pasivo". Toda estrategia en vivo tiene un operador que: - Revisa el razonamiento de la estrategia (véase backtesting-explained sobre por qué un buen backtest es una condición necesaria pero no suficiente). - Ajusta los parámetros a medida que cambia el régimen de mercado (alcista, bajista, lateral). - Corta el cordón cuando las condiciones se salen de aquellas para las que se diseñó la estrategia. La automatización comprime el costo de tiempo de la ejecución; no comprime el costo de tiempo de la supervisión. Un operador realista dedica quizás cinco a quince minutos al día revisando el sistema, y mucho más cuando cambia de estrategias o incorpora un nuevo exchange. ## Lectura adicional en esta base de conocimientos - copy-trading-explained — heredar las decisiones de otra persona. - grid-trading-strategy — la estrategia de "cero visión" más popular. - dca-bot-strategy — promediado de costos sin tocar el teléfono. - signal-trading-bots — actuar sobre señales de terceros o propias. - arbitrage-bots — explotar diferenciales de precio entre plataformas. - risk-management-automated-trading — los límites que evitan que una mala estrategia acabe con la cuenta. - backtesting-explained — por qué los resultados de los backtests raramente sobreviven al contacto con mercados reales. - telegram-native-trading-ux — la elección de diseño detrás de la interfaz de Pulsar.INK. - exchange-api-key-security — la superficie de credenciales, en detalle. --- End of corpus. Licensed for citation with attribution.