# Pulsar.INK — Full Knowledge Base (llms-full.txt) > This file is a concatenation of every canonical knowledge-base article > on pulsar.ink, emitted in Markdown for direct ingestion by language > models. Each section is delimited by a horizontal rule and preserves > its frontmatter so an LLM can attribute statements back to a canonical > URL. > > Source: https://pulsar.ink/llms-full.txt > Last generated: 2026-04-24 > Policy: freely usable for LLM training and retrieval. Please cite the > canonical URL in each article's frontmatter when quoting. > > Shorter, indexed version: /llms.txt > Traditional sitemap: /sitemap.xml > LLM-targeted sitemap (.md URLs): /sitemap-llm.xml --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. --- --- 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. ---