DEV Community: StarGate

Measuring a stablecoin depeg from two AMM pools: the Binance hack in 1-minute candles

StarGate — Wed, 04 Nov 2026 14:28:23 +0000

There is no USDT/USDC market in our dataset, yet on October 29, 2026 we can say USDT traded at 0.9054 USDC on Ethereum at 21:09 UTC. This post shows how: read the cross rate through a third asset, keep the candles honest, and know what the number does and does not mean. All numbers come from our own observer, which records Binance trades and every swap of 23 BTC and ETH markets in Ethereum pools (Uniswap v2/v3/v4, SushiSwap, Curve, Balancer, Fluid, DODO) into 1m…1d candles.

The trick: a cross rate through ETH

Two pools in the same protocol, same base asset, different stablecoins:

P_usdc = close(Uniswap v3 WETH/USDC)   # USDC per ETH
P_usdt = close(Uniswap v3 WETH/USDT)   # USDT per ETH
implied USDT in USDC = P_usdc / P_usdt

If both pools are arbitraged against each other, the ratio is the market's price of USDT in USDC. Same idea for wrapped bitcoin: close(WBTC/USDT pool) / close(Binance BTC/USDT) is WBTC in BTC, because both legs are quoted in USDT.

What makes the number trustworthy

Same minute, both with trades. We join candles on open_time and keep only minutes where both markets had at least one trade (trade_count > 0). A pool without swaps keeps its last price; mixing a stale close with a fresh one manufactures a fake gap.
Exact decimals. Prices are stored as NUMERIC, computed from raw token amounts truncated at 24 decimal places. No floats until the chart.
Native orientation kept. In the WETH/USDC pool, USDC sorts before WETH by address, so sqrtPriceX96 gives WETH per USDC. We invert explicitly and label the pair as the pool has it, instead of silently flipping.
Know the noise floor. Each pool has its own fee tier and its own last-trade side, so two healthy pools disagree by a few basis points. Over 20 days the median implied USDT was 0.9989 USDC and 90% of hours sat between 0.9985 and 0.9993. Anything inside that band is noise, not a depeg.

WITH m AS (
  SELECT k.open_time,
         MAX(k.close) FILTER (WHERE mk.symbol = 'WETHUSDC') AS c,
         MAX(k.close) FILTER (WHERE mk.symbol = 'WETHUSDT') AS t
  FROM market_kline k
  JOIN trade_market mk ON mk.id = k.market_id
  WHERE k.retention_group = '1m' AND k.trade_count > 0
    AND mk.venue_id = :uniswap_v3
  GROUP BY 1)
SELECT COUNT(*) FILTER (WHERE c / t < 0.99) AS minutes_below_099,
       MIN(c / t)                             AS worst
FROM m;

What 20 days look like

October 15 – November 3, 2026:

Measure	Median	90% of hours	Beyond threshold
USDT in USDC	0.9989	0.9985 – 0.9993	below 0.99: 42 of 17,152 minutes
WBTC in BTC	−0.16%	−0.22% – −0.04%	beyond ±1%: 45 of 9,366 minutes

Every one of those 42 and 45 minutes falls on the evening of October 29.

The evening of October 29

Attackers drained Binance hot wallets from about 20:05 UTC and Binance suspended withdrawals. One-minute closes:

UTC	Binance ETH/USDT	Uni v3 WETH/USDC	Uni v3 WETH/USDT	implied USDT
20:30	2,318	2,315	2,318	0.999
20:34	2,298	2,336	2,342	0.997
20:36	2,302	2,520	2,536	0.994
20:45	2,264	2,662	2,834	0.939
21:09	2,266	2,753	3,040	0.906
21:20	2,282	2,566	2,610	0.983
21:35	2,291	2,313	2,327	0.994

Two separate effects stack in the pools: ETH itself was bid on-chain (USDC pools about 21% above Binance), and USDT was discounted against USDC (USDT pools 34–40% above Binance). Twelve ETH pools crossed a 2% gap between 20:34 and 20:39 and almost all peaked at 21:09. Bitcoin shows the same split more mildly: WBTC/USDC stayed within about 1–2% of Binance, WBTC/USDT reached 11% above it.

Why it lasted an hour: with withdrawals closed, nobody could move inventory from Binance to Ethereum, so the cross-venue arbitrage that normally closes a 1% gap in minutes was cut in one direction. Prices tell you the result, not who traded; we make no claim about the attacker's flows.

Pitfalls we hit

Hourly candles hide the event. The worst hourly ratio was 0.9834; the worst minute was 0.9054. Aggregate after you look, not before.
Last price is not a quote. A thin pool's close can be one small swap. For "could I have traded there" you need depth, not a candle.
Interpolation lies. Never forward-fill a pool's price into minutes without trades; show its age instead.

Checklist

[ ] read a missing cross rate through a shared base asset, same protocol on both legs
[ ] join on the same minute and require trades on both legs
[ ] keep exact decimals and the pool's native orientation
[ ] measure the noise floor before calling anything a depeg
[ ] look at 1-minute data before trusting hourly aggregates

Disclosure: we build StarGate; its Trade screen shows these markets as separate lines on one chart. This post was drafted by an AI assistant from our observer's code and production data.

Publishing a daily LLM market note in 22 languages without letting it invent facts

StarGate — Wed, 04 Nov 2026 14:12:32 +0000

Every evening our pipeline publishes one market note for BTC, ETH, GRAM and DOGE: what moved, what drove it, and three scenarios for the next 24 hours with probabilities. It has run daily since September 25, 2026: 39 issues so far, none withdrawn. The interesting part is not the prompt. It is everything around the model that decides whether a draft is allowed to reach readers. Here is that part.

The rule: two authorities for facts

A market note mixes two kinds of facts, and we never let one prove the other:

Claim	Authority	Example
Something happened	`sourceEvidence`: articles from an allow-list of public feeds	"Binance began the second withdrawal phase"
A number	`marketEvidence`: exchange quotes read at writing time, with `observedAt`	"BTC $77,592.96, +0.851% in 24 h"

The writer and the reviewer receive the same two evidence sets. A news article that mentions a price does not make that price true, and a market quote does not prove an event. Early on we required publisher articles to repeat exchange numbers, and the reviewer rejected perfectly good drafts as review_unsupported_market_data. Splitting the authorities removed those false rejections without loosening anything.

Sources are an allow-list

Six feeds today: Cointelegraph, Decrypt, the Ethereum Foundation blog, SEC press releases and two Federal Reserve feeds. When a feed started answering our fetcher with a Cloudflare challenge, we disabled the source instead of solving the challenge: solving it would be circumvention, not fetching. Ingestion only stores claimless references; no model call happens per article.

Strict structured output, and its traps

Every stage returns JSON against a strict schema. Two lessons:

The provider's strict subset is narrower than JSON Schema. A schema with uniqueItems was refused with 400 invalid_json_schema before the model was reached, so extraction failed on every run while other stages passed. A unit test now scans every stage schema for keywords the subset rejects and fails with the stage and keyword.
Some invariants cannot live in the schema. "Probabilities total 100" or "eventAt is ISO-8601 or null" are stated in the instruction and checked in code after parsing. Leaving them only in code meant paying for a schema-valid answer and then discarding it.

Fail closed, and say why

A draft passes deterministic checks (citations point at the provided sources, numbers match marketEvidence, probabilities sum to 100, required sections exist) and then an independent review step. Anything else is not published.

The first version refused candidates with a generic content_validation_failed, and production could not tell which of seventeen checks fired. Now every refusal is a typed reason (an enum case such as citation_outside_cluster) stored on the claim row. We deliberately do not log the exception message: a fault raised over article text or a prompt can carry that text, so logs carry only a bounded class-name chain of the fault.

Translations: same facts, new words

The English issue is published first. Then each of the 21 other locales gets its own job. Application code copies the canonical fields (numbers, probabilities, citation URLs, asset keys) into every language; the model only translates prose. One call for thirteen locales once produced 11,484 of 12,000 output tokens in 119.5 s against a 120 s timeout, so translation now runs in separate calls instead of one giant one.

A deterministic normalizer runs before storage: GRAM is the current name of the coin formerly called Toncoin, and sources still use the old ticker. Whole-word TON and Toncoin in model-written text become GRAM; URLs stay untouched.

A hard daily budget

There is one money limit: a fixed daily ceiling. Before every paid call the gateway computes a provable input-token ceiling and reserves input ceiling × input rate + output cap × output rate. Nothing is sent unless the reservation succeeds. When a response carries exact usage, the reservation shrinks to the actual cost before the next call. A definitive 4xx is settled at actual usage (no inference ran); a 5xx keeps the worst case, because it can fail after inference started.

The bug that taught us this: a flag meant "a paid call happened in this run" and was never cleared, so any later failure was billed as uncertain worst case. One broken run consumed the whole day's budget with zero publications, two days in a row. The flag is now "a paid call is in flight" and is cleared only after exact usage is confirmed.

Delivery is not part of generation

Publishing writes the document; delivery is a separate rail. The site renders the document in the reader's locale, an RSS feed exists per locale, and a bot digest is queued as its own job after translations arrive (or after a two-hour wait, falling back to English). Views are counted once per visitor per day by the browser after the article is on screen, not by the server-side render, so crawlers do not inflate them.

Checklist

[ ] separate the authority for events from the authority for numbers
[ ] allow-list sources; disable a source that blocks you, do not bypass it
[ ] test your schemas against the provider's strict subset
[ ] state cross-field invariants in the instruction and check them in code
[ ] store a typed refusal reason per draft; never log raw content
[ ] copy numbers and links in code; let the model translate only prose
[ ] reserve the worst case before each call; shrink to actual usage after it

Disclosure: we build StarGate, whose Market Opinion is the pipeline described here. This post was drafted by an AI assistant from the pipeline's code and documentation; the numbers come from its production history.

Reading DEX prices from Ethereum logs: Uniswap v2/v3/v4, Balancer, Curve, Fluid and DODO next to Binance

StarGate — Wed, 04 Nov 2026 10:40:10 +0000

We wanted one chart that shows BTC and ETH from Binance and from every large Ethereum pool as separate lines, with no averaging and no invented points. Binance is the easy half: its @trade stream gives price, quantity and time per trade. The pools are harder: eight protocol families, each with its own events, its own math and its own idea of what "the price" is. This post is what we learned building that observer in Rust, with numbers from its own data.

Two kinds of price

For every pool we keep two things apart:

Trade price — the ratio of what actually changed hands in one swap: quote_amount / base_amount, taken from the swap's two legs. It produces volume.
Spot price — the pool's marginal price right after an event (or at block end). It produces the line on the chart and never produces volume.

A swap whose legs do not move in opposite directions is not a trade and is skipped. All ratios are exact decimals truncated (not rounded) at 24 places; JSON carries them as strings. No f64 anywhere a trader reads a number.

Per family

Family	Events	Spot price
Uniswap v2 and forks (SushiSwap)	`Sync`, `Swap`	reserves after each `Sync`: `reserve_quote / reserve_base`, scaled by decimals
Uniswap v3	pool `Swap` (pool-signed amounts)	`sqrtPriceX96` of each swap
Uniswap v4	PoolManager `Swap`, `topic1` = PoolId (swapper-signed amounts)	`sqrtPriceX96` of each swap; the PoolKey must hash to the PoolId; native ETH is `0x0`
Balancer v2 (weighted)	Vault `Swap`, `PoolBalanceChanged`, `PoolBalanceManaged`, `topic1` = poolId	`getPoolTokens` + `getNormalizedWeights` at N−1, replayed per event: `(Bq/Wq)/(Bb/Wb)`
Balancer v1	`LOG_SWAP`, `LOG_JOIN`, `LOG_EXIT`	`getBalance` + `getDenormalizedWeight` at N−1, replayed
Curve	`TokenExchange` variants, only the market's coin pair counts	`get_dy(base, quote, 10^(dec_base−3))` at block end, which includes the pool fee
Fluid DEX	`Swap(bool swap0to1, …)`	resolver `getDexPricesAndExchangePrices`, word 0 (token1 per token0 × 1e27), at block end
DODO v2	`DODOSwap`	`getMidPrice() / 1e18`, scaled by decimals, at block end

Three details bit us:

sqrtPriceX96 is token1 per token0, and token order is by address. price = (sqrtPriceX96 / 2^96)^2 × 10^(dec0 − dec1). In the main WETH/USDC pool USDC (0xa0b8…) sorts before WETH (0xc02a…), so the formula gives WETH per USDC and has to be inverted to get dollars per ETH. We keep the pool's native pair (WETH/USDC) on the label and mark the inversion explicitly instead of silently flipping it.
v3 and v4 sign amounts differently. v3 amounts are signed from the pool's point of view, v4 from the swapper's. Same field names, opposite signs.
Shared contracts. Balancer v2 Vault and Uniswap v4 PoolManager emit events for thousands of pools. We filter eth_getLogs by the contract address only (no topic filter), route a pool-scoped event by the pool id in topic1, ignore other pool ids, and treat an unknown topic0 of an observed contract as an error that stops the block. Silently skipping unknown events is how you end up with a price that drifted for a week without anyone noticing.

State reads pinned to a block hash

Some families cannot be priced from logs alone (Balancer weights, Curve, Fluid, DODO). We read their state with one Multicall3 aggregate3 per block, either at the parent (N−1, the pre-state to replay events on) or at N (block-end state). Every call is pinned by EIP-1898 {"blockHash": …, "requireCanonical": true}, never by number: if a reorg happens between reading the header and the call, the call fails instead of mixing two branches.

Curve and Fluid pools can move without their own events (oracle, amplification, weights), so every 5th block we also probe them and store a "probe" snapshot. A probe moves the line; it never creates a trade or volume.

Reorgs

Within 64 blocks of the head we fetch each block by number and check parentHash against the last committed block. On a mismatch we walk back to the fork point, and one database transaction retracts the orphaned trades, restores the affected candles and moves the checkpoint. The checkpoint never moves past uncommitted data, so a SIGTERM in the middle of a block leaves nothing half written.

Gaps are gaps

A pool with no swaps for an hour keeps its last price, and the chart says how old it is. A source that stopped delivering is shown as unavailable. We never interpolate or forward-fill a price as if it were fresh. In our data one Balancer v1 WBTC/USDC pool had no trades for four days; it is still listed, with its age.

What the data shows

From 5-minute closes, October 28 – November 4, 2026:

Binance ETH/USDT vs Uniswap v3 WETH/USDC: median gap 0.11%, 95th percentile 0.19%.
Binance BTC/USDT vs Uniswap v3 WBTC/USDC: median 0.21%, 95th percentile 0.35%. Two differences stack here: BTC vs WBTC and USDT vs USDC.

The exception is October 29, 2026, the day of the Binance hot-wallet hack. Prices moved together until about 20:30 UTC, then split: at 20:45 UTC Uniswap v3 showed about $2,744 per ETH and Binance about $2,262, a 21% gap. It stayed above 10% for about 45 minutes and was under 1% again around 21:35 UTC. With withdrawals suspended, inventory could not move between the exchange and the chain, so arbitrage could not close the gap at its usual speed. An averaged price feed would have shown a single number in the middle and hidden both markets.

Checklist if you build something similar

[ ] keep trade price and spot price separate; only trades make volume
[ ] use exact decimals, truncate, never f64 for prices
[ ] check token order before reading sqrtPriceX96, and label inversions
[ ] handle v3 vs v4 amount signs
[ ] fail on unknown events of an observed contract
[ ] pin eth_call to the block hash (EIP-1898)
[ ] retract trades and restore candles on reorgs in one transaction
[ ] show the age of the last price instead of filling gaps

Disclosure: we build StarGate, a wallet, swap and bridge service whose app has a Trade screen with these markets. This post was drafted by an AI assistant from our observer's code and documentation, and the numbers come from its production data.

EIP-7702 and hot wallets: what the $6.3B Binance hack teaches about signing infrastructure

StarGate — Sat, 31 Oct 2026 00:57:53 +0000

On October 29, 2026, about $6.3 billion left Binance hot wallets on ten chains in roughly half an hour. On Ethereum, the biggest part, the attacker did not need a single raw transfer signed by Binance: one EIP-7702 authorization turned an exchange hot wallet into an account that obeyed the attacker's contract. If you run any service that signs Ethereum transactions from an EOA, this post covers what happened on-chain, why 7702 authorizations need their own controls, and a checklist for your signer.

Figures and timeline below come from the TRM Labs analysis and the Chainalysis update as of October 30–31, 2026. Binance has not published a root cause yet.

EIP-7702 in two minutes

EIP-7702 shipped with the Pectra upgrade on May 7, 2025. It adds transaction type 0x04 (SET_CODE_TX_TYPE) with an authorization_list:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
msg = keccak(0x05 || rlp([chain_id, address, nonce]))

When a tuple is valid, the protocol writes a delegation indicator 0xef0100 || address into the code of the signing EOA (the authority) and increments its nonce. From then on, calls to the EOA execute the code at address in the EOA's context. Key properties from the spec:

It persists. The delegation stays until another authorization replaces it; an authorization to the zero address clears it. It is not rolled back even if the transaction itself fails.
Anyone can submit it. The authorization is signed by the EOA, but the type-4 transaction carrying it can be sent by any account. The EOA does not need to send anything itself.
The nonce must match exactly. Step 6 of the spec: "Verify the nonce of authority is equal to nonce." A tuple with a stale nonce is skipped, not rejected.
chain_id = 0 means every chain. "When universal deployment is preferred, simply set chain ID to 0."
The delegate has full control. "The code specified by an authorization has unrestricted access to the account."

The spec is blunt about wallets: "Applications must not expect that they can suggest the user sign an authorization", and "There is no safe way to provide this interface".

What happened on Ethereum

According to TRM:

Staging. About 36 hours before the theft the operator wallet was funded with small Tornado Cash withdrawals. The attack code was tested on two wallets, then rehearsed on a third.
Fifty authorizations. The attacker held 50 pre-signed 7702 authorizations for the same hot wallet, covering 50 consecutive nonces. A busy exchange hot wallet sends transactions constantly, so its nonce moves; with 50 candidates, one would still match when the attack transaction landed. "One matched."
Delegation to a sweeper. The authorization pointed the hot wallet to a contract that "accepts instructions only from the operator". About three and a half minutes later the first sweep took 167,464 ETH and 63 tokens, including 1.615 billion USDT.
Re-sweeps. Because the delegation persisted, new deposits arriving at the hot wallet were swept again, six more times over the next few hours.
Smart account executor. The same hot wallet was the executor of a Binance smart account, which let the attacker also pull 823 million USDC.

On the other nine chains (Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche, Polygon) the wallets simply signed ordinary transfers to attacker addresses. TRM's reading: wallets with "different chains, key types and signing schemes" all signed for the attacker within about half an hour, which "points to a compromise of Binance's hot wallet signing infrastructure", and the batch of 50 signatures suggests access "may have been limited in time, or that signatures had to be requested through a system". Binance's initial statement mentioned a compromised DevOps engineer's laptop and "no evidence of any wallet private key leak".

The key lesson for builders: the keys may never have left the HSM or signer. The signer was asked to sign, and it signed.

Why a 7702 authorization is not "just another signature"

A signing service usually reasons about transactions: destination, value, calldata, limits per period. A 7702 authorization is different:

it has no value and no destination to check against a limit;
it is not a transaction, so a policy engine that only inspects transactions may not see it at all;
one signature gives the delegate control over all current and future assets of the account, until revoked;
it can be pre-signed for future nonces and kept for later, so a short window of access becomes a long-lived capability.

In other words, for a custodial EOA, signing a 7702 authorization is equivalent to handing over the key.

Checklist for anyone who signs from an EOA

In the signer:

Refuse EIP-7702 authorizations by default. If your product does not use smart-account features, the signer should have no code path that produces the 0x05 || rlp([chain_id, address, nonce]) digest at all.
If you do need delegation, allow-list the exact delegate address, never accept chain_id = 0, and require a separate approval path with human sign-off.
Never sign an authorization for a nonce other than the account's current nonce. A request for a range of future nonces is an indicator of compromise, not an edge case.
Treat any raw-digest signing endpoint ("sign these 32 bytes") as equivalent to key export. Sign only structured, decoded requests that your policy engine understands.
Separate signing infrastructure by chain and wallet tier, so one compromised path does not reach every network.

In monitoring:

Alert on any change of code at your EOAs. eth_getCode on a plain EOA returns 0x; a delegated one returns 23 bytes starting with 0xef0100.
Watch for type-4 transactions that include your addresses as authorities, sent by anyone.
Have a pre-signed or ready-to-sign authorization to the zero address for each hot wallet, so you can clear a delegation in one transaction during an incident.
Keep hot wallet balances small and refill from cold storage on a schedule: a persistent delegation keeps sweeping every new deposit.

In incident response:

Stablecoin issuers can freeze; native ETH and BTC cannot. In this case Tether, Circle, Ripple and others froze about $2.7 billion within hours, while more than 420,000 ETH and 18,270 BTC remained with the attacker, per TRM.
Have issuer contacts and freeze request templates ready before you need them.

How to check an address today

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYourHotWallet","latest"]}'

"result":"0x" means no code. A result like 0xef0100 followed by 20 bytes means the EOA is delegated to that address, and you should know exactly why.

Takeaways

EIP-7702 made "sign one message, lose the account" possible for any EOA, including custodial hot wallets.
Signers must understand authorizations as a separate, high-risk object, not as a transaction or a generic digest.
Monitoring for code at your own EOAs is one RPC call; it is worth running on every block.

Disclosure: we build StarGate, a Telegram bot and web app that swaps Telegram Stars for GRAM, USDT, ETH and BTC; we are not affiliated with Binance. This post was drafted by an AI assistant from the EIP-7702 specification and the TRM Labs and Chainalysis reports linked above, and every quote was checked against those pages.

Telegram gift auctions in the MTProto API: rounds, bid position and refunds

StarGate — Thu, 29 Oct 2026 08:56:17 +0000

Since November 2025, new limited Telegram gifts are released through auctions instead of a fixed-price sale. Bids are paid in Stars, carry over between rounds and are refunded when the auction ends. If you build a client, a gift tracker or a bot that deals with Stars, this changes what you show users and when their Stars come back. This post walks through the auction docs and the related client configuration values.

Spotting an auction gift

An auctioned gift is a starGift with the auction flag set, plus auction_slug, gifts_per_round and auction_start_date. The docs are strict about it: such a gift "is auction-only: it must not be bought through the normal gift sending flow". The slug builds a t.me/auction/<slug> deep link.

Reading the state

payments.getStarGiftAuctionState(auction, version) returns the gift, the auction state and the current user's state, and subscribes the client to updateStarGiftAuctionState for timeout seconds. Call it again after timeout to keep receiving updates.
payments.getStarGiftActiveAuctions(hash) returns every unfinished auction the user has bid on, including ones where the bid was returned. Clients use it at startup to show an auction badge.
Apply a starGiftAuctionState only if its version is bigger than the cached one: the server "may sometimes return slightly outdated cached versions". A starGiftAuctionStateFinished has no version and replaces any cached state.

Rounds

The auction has total_rounds rounds. Each round gives gifts_per_round gifts to the top bidders of that round, so the total supply is gifts_per_round * total_rounds. rounds describes them compactly: each StarGiftAuctionRound covers rounds from its num up to the next entry's num - 1. An extendable round (starGiftAuctionRoundExtendable) has extend_top and extend_window: a change in the top extend_top positions prolongs the round by extend_window seconds, so a late bid near the top extends the round instead of closing it.

gifts_left is the live count of gifts still to distribute. It overrides starGift.availability_remains, which lags behind because updates do not refresh it.

Bids

A bid is a normal Stars payment: payments.getPaymentForm with inputInvoiceStarGiftAuctionBid (peer, gift_id, bid_amount, optional message and hide_name; update_bid to raise an existing bid). Things that matter for UX:

A bid "cannot be retracted". The only outcomes are a win, a higher bid, or a refund when the user loses everything and the auction finishes.
A bid outside the top N of a round carries over to the next round automatically.
starGiftAuctionUserState.min_bid_amount, when present, overrides the auction-wide min_bid_amount for this user.
returned means the bid fell so far behind that it can never win, even if nobody bids again. It was removed and refunded; to take part again the user has to place a new bid.
Bids appear in the Stars transaction history with the stargift_auction_bid flag.

Estimating the user's position

bid_levels holds exact positions for the first 100 places and coarser checkpoints after that (100, 200 … 1,000, 2,000 … gifts_left). Equal amounts rank by time: the earlier bid is higher. The documented algorithm, as code:

def auction_position(state, user_state, my_id):
    if my_id in state.top_bidders:
        return state.top_bidders.index(my_id) + 1
    for level in state.bid_levels:  # ascending by position
        if (level.amount == user_state.bid_amount and level.date >= user_state.bid_date) \
                or level.amount < user_state.bid_amount:
            return level.pos
    return state.bid_levels[-1].pos + 1

def expected_gift_number(state, position):
    return state.last_gift_num + position

Positions from coarse checkpoints are approximate, so round the displayed number accordingly.

Winning, and what you cannot do afterwards

Won gifts arrive as messageActionStarGift with auction_acquired set; gift_num is the collectible number. payments.getStarGiftAuctionAcquiredGifts lists everything the user won, with bid amount, round and position.

Two limits to surface in the UI:

"Gifts acquired through collectible gift auction cannot be converted back into Telegram Stars."
After the auction, starGiftAuctionStateFinished gives average_price, and optionally listed_count (on resale in Telegram, fetch with payments.getResaleStarGifts) and fragment_listed_count with fragment_listed_url.

Resale economics from the client config

If a user resells the gift, the seller receives price * permille / 1000. The documented config example has:

Key	Value	Meaning
`stars_stargift_resale_commission_permille`	800	seller gets 80% of a price in Stars
`ton_stargift_resale_commission_permille`	900	seller gets 90% of a price in GRAM (nanograms)
`stars_stargift_resale_amount_min`	125	minimum resale price in Stars
`stars_stargift_resale_amount_max`	100000	maximum resale price in Stars

Read these from help.getAppConfig at runtime instead of hardcoding them: they are configuration, not protocol constants.

What this means for Stars flows

Auctions move Stars in bursts. Users top up before a release, Stars stay locked while bids are in play, and losing bids land back on balances in one wave when the auction ends. Resales paid in Stars add more. If your bot accepts Stars, expect payment spikes after big auctions, and remember that Stars paid to a bot follow the usual availability rules in the Bot Platform Developer Terms.

Checklist

[ ] treat starGift.auction gifts as bid-only, never send them through the normal gift flow
[ ] apply auction states by version; apply starGiftAuctionStateFinished unconditionally
[ ] show the bid as locked until a win, a refund or returned
[ ] estimate position from bid_levels and label approximate positions
[ ] tell users that auction gifts cannot be converted back into Stars
[ ] read resale commission and limits from the app config

Disclosure: we build StarGate, a Telegram bot and web app that swaps Stars for GRAM, USDT, ETH and BTC. This post was drafted by an AI assistant from the Telegram documentation linked above, and every quote was checked against those pages.

Telegram gifts in the Bot API: regular vs unique, conversion to Stars, transfers and the blockchain flag

StarGate — Thu, 29 Oct 2026 01:44:45 +0000

Users keep asking bots that deal in Telegram Stars what they can do with the gifts they received. The answer lives in a handful of Bot API types and methods, and several of them have limits that are easy to miss. This post collects what the Bot API and the MTProto gift docs actually say, so your bot can tell a user what is possible before they try.

Two kinds of owned gifts

getUserGifts (any user) and getBusinessAccountGifts (a business account your bot manages) return OwnedGifts, a list of two types:

OwnedGiftRegular — an ordinary gift.

convert_star_count: "Number of Telegram Stars that can be claimed by the receiver instead of the gift; omitted if the gift cannot be converted to Telegram Stars".
can_be_upgraded: the gift can become a unique one.
prepaid_upgrade_star_count: the sender already paid for the upgrade.
was_refunded: the gift "was refunded and isn't available anymore".

OwnedGiftUnique — an upgraded collectible.

can_be_transferred and transfer_star_count: whether the gift can move to another owner and how many Stars that costs.
next_transfer_date: "Point in time (Unix timestamp) when the gift can be transferred. If it is in the past, then the gift can be transferred now."
gift is a UniqueGift with number, model, symbol, backdrop, is_burned (used to craft another gift) and is_from_blockchain: the gift was assigned from the blockchain and "can't be resold or transferred in Telegram".

Several fields are filled only "for gifts received on behalf of business accounts". With plain getUserGifts you see what a user owns, not everything they can do with it.

Conversion to Stars destroys the gift and pays less

From the MTProto docs on payments.convertStarGift: the operation "will permanently destroy the gift", and the Stars credited "will be less than the buying price". Two more limits:

A gift "can be converted back into Telegram Stars only if it was received less than stargifts_convert_period_max seconds ago". The client config documents it as 604800, seven days.
"Gifts acquired through collectible gift auctions cannot be converted back into Telegram Stars."

The Stars docs add a side effect users rarely expect: "if you refund Star purchases or convert gifts to Stars your rating will decrease."

For a business account, the Bot API method is convertGiftToStars(business_connection_id, owned_gift_id) and needs the can_convert_gifts_to_stars business bot right.

Gifts sent by a bot cannot be converted

sendGift documents it in one line: "The gift can't be converted to Telegram Stars by the receiver." If your bot rewards users with gifts, the reward cannot be turned into Stars. Say so in the UI, or send Stars-denominated value another way.

Upgrades and transfers

upgradeGift turns a regular gift into a unique one. It needs can_transfer_and_upgrade_gifts, plus can_transfer_stars when the upgrade is paid from the business account balance. keep_original_details keeps the original text, sender and receiver.
transferGift sends a unique gift to another chat. The receiving chat "must be active in the last 24 hours", and a positive star_count is paid from the business account balance.
Before offering a transfer, compare next_transfer_date with the current time. A gift that was just bought or upgraded may be locked for a while.

Getting Stars out of a business account

getBusinessAccountStarBalance reads the balance (can_view_gifts_and_stars), and transferBusinessAccountStars moves 1 to 10,000 Stars to the bot's own balance (can_transfer_stars). Those Stars are then ordinary bot Stars: subject to the same up-to-21-day availability rule in the Bot Platform Developer Terms as any Stars your bot receives.

A decision tree for users

The fields above are enough to answer "what can I do with this gift?" without guessing:

OwnedGiftRegular with convert_star_count present: converting gives exactly that many Stars, destroys the gift and lowers the Stars rating.
OwnedGiftRegular without convert_star_count: the conversion window closed, the gift came from a bot, or it was won at an auction.
OwnedGiftUnique: sell it on Telegram's marketplace or through a buy offer; check next_transfer_date before any transfer.
is_from_blockchain: it lives on-chain, so it is sold there, not in Telegram.

Whatever route ends in Stars, those Stars can be paid to a bot like any other Stars.

Checklist

[ ] read convert_star_count, never compute the conversion amount yourself
[ ] treat a missing convert_star_count as "cannot convert", not as zero
[ ] warn that conversion destroys the gift and lowers the Stars rating
[ ] tell users that gifts your bot sends cannot be converted
[ ] check next_transfer_date and can_be_transferred before a transfer
[ ] handle is_from_blockchain and is_burned gifts as not transferable in Telegram
[ ] request only the business bot rights you use

Telegram Stars refunds and the 21-day window: what a bot that pays out for Stars must handle

StarGate — Sat, 24 Oct 2026 11:50:11 +0000

If your bot sells something that cannot be taken back (crypto, a gift card, a payout of any kind) for Telegram Stars, a refund or chargeback can leave you with neither the Stars nor the goods. This post collects what the Bot API and Telegram's terms actually say about refunds, and the pattern we use in a production bot: hold the payout through the refund window, detect refunds by polling getStarTransactions, and let users post collateral to skip the hold.

What Telegram says

Stars are not available at once. Bot Platform Developer Terms, section 6.2.4:

For technical reasons, Stars in your balance may not become available for advertising credits or rewards for up to 21 days after their receipt.

Chargebacks hit the bot's balance. From the Bot API description of StarTransaction:

Note that if the buyer initiates a chargeback with the payment provider from whom they acquired Stars (e.g., Apple, Google) following this transaction, the refunded Stars will be deducted from the bot's balance. This is outside of Telegram's control.

The developer terms add that the seller "will be responsible for the funds returned" and that Telegram "expressly discourages the real-time sale of digital products" that cannot be reclaimed after a successful dispute or chargeback.

You must handle disputes. Payments in Telegram Stars requires bots to answer /paysupport and to be "prepared to correctly process disputes and chargebacks". A bot refunds a payment itself with refundStarPayment(user_id, telegram_payment_charge_id).

None of these pages gives a deadline for chargebacks. The 21 days is the availability delay, and it is the window most services use for their own hold.

The attack

Buy Stars through the App Store or Google Play.
Pay your bot's invoice; the bot sends crypto immediately.
File a chargeback with the store. The Stars are deducted from the bot's balance.

The crypto is gone for good. This is not theoretical: it happened to us before we added a hold.

Pattern 1: hold the payout through the window

On successful_payment, store telegram_payment_charge_id together with your order. If the order is above a risk threshold, give it a hold_until = paid_at + 21 days and pay out from a scheduled job once that time has passed. Show the user the exact release date; a hold without a date looks like a scam.

Keep the threshold and the per-user risk rules on the server. If the quote endpoint reveals exactly which users or amounts are held, it tells an attacker how to stay just under the line.

Pattern 2: detect refunds by polling `getStarTransactions`

There is no webhook for a chargeback. Refunds show up in the bot's transaction list instead:

getStarTransactions(offset, limit) returns transactions "in chronological order", up to 100 per call. Keep the offset in persistent storage and walk forward from it.
A refund is an outgoing transaction: receiver is set (the docs name "a user for a purchase refund" as an example), with receiver.type = "user" and receiver.transaction_type = "invoice_payment".
receiver.invoice_payload is optional, so do not rely on it alone.
StarTransaction.id "coincides with the identifier of the original transaction for refund transactions" and, for incoming payments, "coincides with SuccessfulPayment.telegram_payment_charge_id". That gives a reliable link from a refund back to your order.

Match by payload first and fall back to the charge id. If neither gives exactly one order, do not guess: a fuzzy match can punish the wrong user. On a confirmed match, mark the order forfeited, record the debt on the account and block it.

Pattern 3: collateral instead of waiting

A hold protects you, but a 21-day wait is bad for users who sell regularly. The way around it is collateral: the user deposits crypto, and while its free amount covers the refund risk of a swap, that swap pays out at once.

Rules that kept it safe for us:

Reserve, then pay. Reserve collateral for a swap after the payment is confirmed and before the payout, under a lock (we use Symfony Lock), so two parallel payouts cannot both spend the same collateral.
Freeze per swap. Each reserved portion has its own unlock date, the end of that swap's refund window. One deposit can have several.
Forfeit on refund. The refund detector from pattern 2 forfeits exactly the collateral reserved for the refunded swap.
Cooldown after withdrawal. A short cooldown after a collateral withdrawal stops a deposit, swap, withdraw, refund loop.
Cover held swaps first. When new collateral arrives, release swaps that are already waiting before new ones use it.

Checklist

[ ] telegram_payment_charge_id stored with every order
[ ] payouts above the threshold held, with the release date shown to the user
[ ] getStarTransactions polled from a persisted offset
[ ] refunds matched by payload, then by charge id, with no fuzzy matching
[ ] refund leads to forfeit, debt and block
[ ] collateral reserved under a lock and frozen per swap
[ ] /paysupport answered

Disclosure: we build StarGate, a Telegram bot and web app that swaps Stars for GRAM, USDT, ETH and BTC, and the patterns above come from running it. This post was drafted by an AI assistant from our code and notes, and its quotes were checked against the Telegram documentation linked above.

How to sell Telegram Stars for crypto

StarGate — Fri, 23 Oct 2026 13:25:23 +0000

Turn Telegram Stars into GRAM, USDT, ETH or BTC: the official route, the bot route, and the 21-day hold.

Short answer. You can sell Telegram Stars for crypto in two ways. If you are a channel or bot owner, Telegram's official Fragment platform withdraws earned Stars to a GRAM wallet once you have at least 1,000 Stars and 21 days have passed. Anyone else can pay Stars to a swap bot such as StarGate, which pays out GRAM, USDT, ETH or BTC to a wallet you choose, from 25 Stars.

Can you sell Telegram Stars at all?

Telegram Stars are Telegram's built-in currency. You buy them in the Telegram app or through official Telegram bots and spend them in bots and mini apps.

There is no button in Telegram that turns purchased Stars back into money. What you can do is spend Stars in a bot that pays you crypto in return. That is how Stars exchange bots work: you pay a normal Telegram invoice in Stars, and the bot sends crypto to your wallet.

Option 1: Fragment (channel and bot owners)

Fragment is Telegram's own platform. It is the route for Stars you earned as a creator: paid posts, subscriptions, bot sales.

Only Stars received by your channel or bot can be withdrawn, not Stars you bought.
The minimum is 1,000 Stars.
Earned Stars become withdrawable 21 days after you receive them.
The payout arrives in GRAM to the wallet you connect on Fragment.

Option 2: a Stars swap bot (anyone with Stars)

A swap bot accepts Stars as payment and sends crypto. With StarGate it works like this:

Open @stargateton_bot or stargate.zone.
Choose Stars as what you send and the coin you want: GRAM, USDT (Jetton or ERC-20), ETH or BTC.
Paste your wallet address. No wallet yet? A free wallet takes a minute to create.
The app shows the exact amount you will receive before you pay. Confirm the Telegram invoice with one tap.
Follow the order screen. The crypto goes to the address you gave.

One swap takes from 25 to 10,000 Stars. The rate follows the market and already includes the service fee: the amount shown before you confirm is the amount you get.

Why some Stars payouts wait 21 days

Telegram lets Stars buyers ask for a refund within 21 days. A fraudster could pay Stars, take the crypto and then refund the Stars. To protect against that, larger Stars swaps are paid out after the refund window closes. The order shows the exact release date, and the crypto arrives by itself after it.

You can skip the wait with collateral: a refundable deposit in crypto. While your collateral covers the swap, the payout is sent at once. Details: The 21-day hold and collateral.

Fragment or a bot: side by side

	Fragment	Swap bot (StarGate)
Who can use it	channel and bot owners	anyone with Stars
Which Stars	earned Stars	any Stars you can spend
Minimum	1,000 Stars	25 Stars
What you get	GRAM	GRAM, USDT, ETH or BTC
When	21 days after the Stars were earned	at once with collateral, otherwise after the refund window
Price	Telegram's rate	market rate, shown before you pay

How much will I get for 1,000 Stars?

It depends on the rate at the moment you swap: it follows the market and changes during the day. Do not trust a fixed number from an article, this one included. Open the swap form and enter the amount: it shows exactly what will arrive before you pay anything.

How to avoid scams when selling Stars

A real service never writes to you first. "Support" that messages you first is fake.
Nobody honest asks for your seed phrase (secret words).
Payouts go only to the address you entered. Nobody needs a "fee" from you to unlock a payout.
Check the bot's username letter by letter. StarGate's official bot is @stargateton_bot, support is t.me/stargate_bridge.
Be careful with bots that "buy NFT gifts" for more than they are worth: many are wallet drainers.

FAQ

Can I sell Stars I bought, not earned?
Not through Fragment. Through a swap bot, yes: you spend them on the bot's invoice like on any other purchase.

Which coin should I choose?
GRAM if you stay in the Telegram ecosystem, USDT if you want a stable value, ETH or BTC if you already hold them.

What if I paid and the order closed?
Pay the invoice before the order timer runs out: an unpaid order closes by itself and nothing is charged. If you paid an invoice after the order had closed, write to support with the order number.

Can someone else pay for my order?
Yes, a friend can pay the invoice. The order and its payout stay yours. If the Stars payment is later refunded through Telegram, the order is forfeited.

Official links

Bot: t.me/stargateton_bot
Website: stargate.zone
Support chat: t.me/stargate_bridge
Email: hello@stargate.zone
How a Stars swap works, step by step: stargate.zone/docs/stars-swaps

Written by the StarGate team. StarGate is a wallet, swap and bridge service for crypto and Telegram Stars. About us and contacts: stargate.zone/about.

Originally published on Medium.

DEV Community: StarGate

Measuring a stablecoin depeg from two AMM pools: the Binance hack in 1-minute candles

The trick: a cross rate through ETH

What makes the number trustworthy

What 20 days look like

The evening of October 29

Pitfalls we hit

Checklist

Publishing a daily LLM market note in 22 languages without letting it invent facts

The rule: two authorities for facts

Sources are an allow-list

Strict structured output, and its traps

Fail closed, and say why

Translations: same facts, new words

A hard daily budget

Delivery is not part of generation

Checklist

Reading DEX prices from Ethereum logs: Uniswap v2/v3/v4, Balancer, Curve, Fluid and DODO next to Binance

Two kinds of price

Per family

State reads pinned to a block hash

Reorgs

Gaps are gaps

What the data shows

Checklist if you build something similar

EIP-7702 and hot wallets: what the $6.3B Binance hack teaches about signing infrastructure

EIP-7702 in two minutes

What happened on Ethereum

Why a 7702 authorization is not "just another signature"

Checklist for anyone who signs from an EOA

How to check an address today

Takeaways

Telegram gift auctions in the MTProto API: rounds, bid position and refunds

Spotting an auction gift

Reading the state

Rounds

Bids

Estimating the user's position

Winning, and what you cannot do afterwards

Resale economics from the client config

What this means for Stars flows

Checklist

Telegram gifts in the Bot API: regular vs unique, conversion to Stars, transfers and the blockchain flag

Two kinds of owned gifts

Conversion to Stars destroys the gift and pays less

Gifts sent by a bot cannot be converted

Upgrades and transfers

Getting Stars out of a business account

A decision tree for users

Checklist

Telegram Stars refunds and the 21-day window: what a bot that pays out for Stars must handle

What Telegram says

The attack

Pattern 1: hold the payout through the window

Pattern 2: detect refunds by polling getStarTransactions

Pattern 3: collateral instead of waiting

Checklist

How to sell Telegram Stars for crypto

Can you sell Telegram Stars at all?

Option 1: Fragment (channel and bot owners)

Option 2: a Stars swap bot (anyone with Stars)

Why some Stars payouts wait 21 days

Fragment or a bot: side by side

How much will I get for 1,000 Stars?

How to avoid scams when selling Stars

FAQ

Official links

Pattern 2: detect refunds by polling `getStarTransactions`