Posts on demand, follower lists, and contract-address cards
These three live only on a follow tracker’s rich card. Each is reached by pressing a button on a card the bot already sent — none has a Telegram command.
Posts on demand — Fetch 5 most recent posts
This fetches the newest 5 posts of the followed account (not the tracking account), rendered as graphics and attached to the same card.
The fetch for these five starts the moment the account is followed, alongside the announce itself. They are shown — by one edit — only once the card already carries a contract address; otherwise they sit already fetched and rendered, behind the button, until it is pressed.
One model, by press
| Press | What happens |
|---|---|
| First press, within 5 minutes of the follow | Serves the five as already fetched — no request. A press that lands while that render is still in flight waits for it. |
| First press, later than 5 minutes | One profile request checks whether the post count has moved; if not, the same five are served. |
| Every later press | Reads up to 4 further timeline pages (20 posts per page), newest unseen first then older, always skipping what the card already shows. |
Total shown caps at 40 posts per card — under Telegram’s own 50-media ceiling alongside the graphic. Post text on the card is trimmed to 220 characters.
The button reads “Fetch 5 most recent posts” before the first press and “Fetch 5 more posts” after. It disappears only once a press returns nothing new. Every press edits the card in place — no new message is ever sent for this.
What the presser sees
| Situation | Toast |
|---|---|
| Posts added | +N posts |
| Button exhausted / nothing returned | No more posts |
| The bot no longer holds this card | This card has expired |
| A press lands while another is running | (no toast) |
| The fetch failed | Couldn't fetch more right now — the card stays armed |
Card context — which posts are already shown, the resolved contract-address tokens, and so on — is kept per card, for the most recent 30 cards an entry has sent, and survives a re-arm or a bot restart. Only a card the bot delivered as a rich message carries this context: a card that fell back to a photo caption or plain text never grew these buttons in the first place.
Follower lists — Fetch <name> Followers
This posts the complete follower list of the followed account into the entry’s group (its lists topic, if one is set) — pressed via the second, blue button row present on every follow card.
The harvest runs through the box’s own paced proxy and is cached for 120 seconds; the harvest request itself is allowed up to 240 seconds.
Rows are most-followed first, one account per line: Name, a check mark when the account is verified, @handle, follower / following / post counts, the month and year it joined, and a 🔒 when the account is protected — each field separated by ·.
Every part opens with a header: the followed account’s name, handle and follower count, plus a suspended/unavailable count when the harvest total is higher than the rows actually returned, plus “top N, full list attached” on the JSON path, plus “part K/T” once the list needs more than one message.
Follower-list limits
| Limit | Value |
|---|---|
| Characters per part | 3800, whichever comes first against the row cap |
| Rows per part | 45 |
| Name length | 28 characters |
| Pacing between parts | 0.4 seconds |
| Flood-wait honoured | up to 300 seconds, 6 attempts per part |
| JSON-document threshold | over 200 followers |
Over 200 followers, the bot posts only the top 20 as a message and attaches the complete list as a JSON document instead, named <handle>-followers-<count>.json. At 200 or fewer, every row goes out as plain messages (so at most about 5 messages at 45 rows each).
An empty list renders as “No followers to list.”
Acks and failures
| Situation | What the user sees |
|---|---|
| Press accepted | Toast: Fetching @<handle>'s followers… |
| A second press while running | Toast: Already fetching this list |
| Card no longer held | Toast: This card has expired |
| Harvest failed | A message in the group: Couldn't fetch @<handle>'s followers right now. |
Note
The group always sees that one failure message, regardless of the underlying cause — a bad handle, an account that no longer exists, and a private account all collapse into the same line. Only the bot’s own log keeps the specific reason.
The button stays after use, for later presses. The entry keeps the time, handle and count of its last list fetch.
Contract-address cards
When the followed account is tied to a token, the follow card grows a contract-address block. Every discovery edits that same card — nothing about it is ever posted as a second message.
The four discovery triggers
- Profile scan — the account’s bio, its link-in-bio, and any other links in the bio, read the moment the card announces.
- Post search — one search at announce time, two query shapes merged: the account’s posts matching a CA/contract/dexscreener/dextools/pump/launch/token/0x/mint keyword set, plus its plain newest posts.
- Every posts-on-demand page — each batch the “Fetch 5…” button pulls (2.7 above) is scanned the same way.
- The platform-admin discovery hook — an internal route that attaches a find to a card directly. Not reachable by a bot owner.
The announce waits at most 1.5 seconds (the graphic render counts against that budget) for the profile scan to resolve, and never waits for the search — a find from the search lands by one edit within 20 seconds of the announce.
Up to 3 tokens are shown per card. The most recent 60 already-seen candidates are remembered per card so they are not re-resolved. The block stays on the card after the posts-on-demand button runs out.