Channel
@PASACREW
On this record: Growth · Engagement · Reactions · Posts · Citations · Cite this entry
6,995subscribers
+8 since we began measuring on 6 August 2026
Risers and fallers across the register · movement among entries of 3,162–10,000.
| Telegram ID | -1001680904256 |
|---|---|
| Type | Channel |
| Username | @PASACREW |
| Created | 29 October 2021 — measured — cross-checked against a third-party dataset (ext.tg_channel) |
| First recorded | 6 August 2026 |
| Last confirmed live | 12 August 2026 |
| Measurements held | 5 |
| Confirmed unchanged | 1 time, most recently 12 August 2026 |
| On Telegram | t.me/PASACREW |
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 12 Aug 2026, 08:43 | 6,995 | -16 |
| 9 Aug 2026, 11:32 | 7,011 | -1 |
| 6 Aug 2026, 12:20 | 7,012 | +25 |
| 6 Aug 2026, 03:17 | 6,987 | no change |
| 6 Aug 2026, 02:03 | 6,987 | first reading |
92 posts held, back to 5 August 2026 — the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 10 pagesof Telegram’s post history, 20 posts per page.
ERR is average views per post over the last 30 days divided by subscribers, the definition TGStat uses, so this figure is comparable with the one you will see elsewhere. It falls structurally as a channel grows: a high ERR on a small channel and a low one on a large channel describe reach mathematics, not quality. We publish the figure and the sample it came from and pass no verdict on it.
ER is defined industry-wide as (forwards + reactions + comments) ÷ views— note the denominator is views, not subscribers. Telegram’s public web preview carries views and reactions but not forward or comment counts, so the reaction rate above is the reactions term only and is therefore a floor: the true ER for this channel is higher by an amount we have not measured and will not estimate.
| Window | Rolling 30 days · latest post in window 12 August 2026 |
|---|---|
| Posts held | 92 (5 August 2026 – 12 August 2026) |
| Views total | 17,209 |
| Reactions total | 1,232 |
| Forwards / comments | not exposed by the public surface — not measured, not estimated |
| Readings taken | 12 Aug 2026, 02:30 UTC |
Views are a single reading per post, taken at the time above. A post published in the last day or two is still accumulating views, which pulls the 30-day average down slightly. That is a property of the standard definition rather than a fault in it, so we keep the definition rather than “correcting” the number into something nobody can reproduce.
Precision. Telegram publishes view counts on its public widget in short form — 8.12K, 3.7M — so any reading at or above 1,000 reaches us rounded to three significant figures, and only counts below 1,000 are exact. Averages and rates derived from them are shown to the same precision rather than to the unit: a figure like 3,701,250 would assert digits nobody measured.
Reaction counts are published per emoji and rounded the same way, so a total below 1,000 is exact and a larger one is a sum that may carry a rounded component from each emoji above 1,000. Because it is a sum, it does not look rounded — read a large reaction total as three significant figures per contributing emoji rather than as the figure it prints.
1,084 reactions across 72 posts, in 6 distinct kinds. The most used accounts for 76.9% of them.
| Reaction | Count | Share | Share, drawn |
|---|---|---|---|
| ❤ | 834 | 76.9% | |
| 👍 | 200 | 18.5% | |
| ⚡ | 30 | 2.77% | |
| 🤬 | 11 | 1.01% | |
| 😢 | 7 | 0.646% | |
| 🤣 | 2 | 0.185% |
No sentiment is inferred, and none should be read in. This table is ordered by count and by nothing else. Emoji do not carry stable meaning across languages or communities — 🙏 is thanks in one channel and mourning in another — so we publish which ones were pressed and how often, and pass no judgement on what an audience meant by them.
Precision. Telegram publishes reaction counts per emoji and short-forms each one — 4.34K, 1.2M — so any single kind at or above 1,000 reaches us at three significant figures, and only counts below 1,000 are exact. The shares above are ratios of those figures and carry the same error. This is also why the total here can differ slightly from a reaction total printed elsewhere on the page: both are sums of the same rounded parts, taken over samples with different edges.
Coverage. Reactions were read on 92 of the 92 sampled posts in this sample. Summed by Telegram’s own count on each post — not by adding up the per-emoji breakdown above — those same posts carry 1,232reactions in total: the kind of figure the paragraph above means by “a reaction total printed elsewhere on the page”.
Measured over the 92 most recent posts we hold, published 5 August 2026 to 12 August 2026, using the newest reading held for each. Telegram Stars are excluded: they are a payment, not a reaction, and they have their own section.
dappOS의 xBubble이 묶는 크립토 루틴 크립토를 다루다 보면 일은 늘 같은 모양으로 돌아온다. 오늘은 어떤 체인을 볼지, 어떤 알림을 먼저 볼지, 또 언제 다시 확인할지 챙겨야 한다. 버튼은 몇 번 안 되는데도 머릿속에는 메모가 여러 장 쌓여 간다. 수수료 준비와 지갑 연결과 결과 확인이 겹치면, 정작 보려던 정보는 뒤로 밀리고 판단의 시작이 더 늦어진다. 이런 흐름이 쌓이면 한 번의 거래보다 확인 순서가 더 큰 피로가 된다. 처음에는 작은 차이처럼 보여도, 며칠만 지나면 같은 질문이 계속 돌아와 손이 느려진다. xBubble은 그 메모를 짧은 요청으로 바꾸는 쪽에 가깝다. 원하는 결과를 적으면 시스템이 필요한 절차를 이어 붙인다. 사이트에 보이는 일정 작업, 최적화 요청, 경로 선택은 같은 생각 위에 있다. 사용자는 여러 도구를…
❤9👍1
dappOS가 줄이는 것은 이동보다 앞선 망설임 주말에 남겨 둔 스테이블코인을 수익 풀로 옮기려는 순간, 사용자는 먼저 체인을 확인하고 브리지를 거치고 가스비로 쓸 토큰을 챙기고 예치할 계약 주소가 맞는지 다시 봐야 합니다. 수익을 찾기 전에 승인과 전송과 확인이 이어지니, 자산을 굴리는 일은 금액보다 절차를 먼저 기억하는 일처럼 느껴집니다. 한 단계만 놓쳐도 같은 일을 다시 시작해야 해서, 작은 실수가 곧 망설임으로 바뀝니다. 결국 진입을 막는 것은 수익률이 아니라, 시작 전에 쌓이는 확인의 피로입니다. dappOS는 이 흐름을 intent, 즉 사용자가 원하는 결과부터 받는 방식으로 풀어냅니다. dappOS는 의도를 먼저 읽고 실행 순서를 한데 묶습니다. 사용자가 넣는 것은 복잡한 절차가 아니라 목적이고, 시스템은 그 목적에 맞는 실행…
❤11
손이 아니라 문장이 먼저 새로운 체인의 DEX에서 토큰을 사려는 순간, 대부분의 사용자는 거래보다 준비를 먼저 하게 된다. 지갑을 열고 체인을 바꾸고 가스를 챙기고 브리지로 넘어간 뒤에야 원하는 행동이 시작된다. dappOS가 겨냥하는 지점은 바로 이 앞부분이다. 무엇을 할지 먼저 말하면, 뒤의 순서를 시스템이 맞춘다. 사용자는 화면마다 조건을 해석하지 않고 결과만 고른다. 그래서 시작 화면은 전송 버튼이 아니라 의도에 가까워진다. 손은 거래 단계를 쪼개지 않고 목적을 고르는 데 닿는다. intent는 원하는 결과를 먼저 적는 방식이다. 사용자가 경로를 설계하지 않아도 dappOS의 의도 실행망이 경로를 찾고, 자산과 수수료와 연결 순서를 묶어 실행한다. dappOS가 말하는 Web3 AI 운영체제도 이 구분 위에서 작동한다. 사람은 직접…
❤14
사용자 앞에서 사라지는 Web3의 실행층 Web3가 낯설게 느껴지는 지점은 자산보다 절차다. 어떤 체인을 고를지, 가스비 같은 거래 수수료를 어떻게 준비할지, 브리지를 거칠지, 승인 순서를 어떻게 맞출지부터 따져야 하니, 초보자에게는 결과보다 경로가 먼저 보인다. dappOS는 바로 그 과정을 사용자 앞이 아니라 뒤에서 처리해야 할 일로 본다. 화면에서 보이는 선택보다 그 뒤의 연결이 더 중요하다는 뜻이다. 그래야 쓰는 사람은 기술을 외우지 않아도 되고, 설명도 덜 필요하다. 사용자가 먼저 배워야 하는 것은 기능 이름이 아니라 결과의 흐름이다. dappOS는 Web3 AI 운영체제를 표방하며, 연구와 계획, 실행을 하나의 흐름으로 묶는다. 사용자가 의도를 말하면 실행층이 그에 맞는 경로를 찾고, 바로 쓸 수 있는 웹3 앱과 공유된 실행 계…
❤13
어라랏 DappOS 에어드랍 2차 지금 바로 열림 https://dappos.com/airdrop 2차물량은 $DOS 270개 NFT로 50만원에 이어 현재가치 15.57만원정도 더 주네...
❤13
앞단을 비우는 dappOS 왜 Web3에서는 앱을 고르기 전에 체인과 토큰과 수수료를 먼저 맞춰야 할까? 화면은 단순해 보여도 실제로는 보이지 않는 준비가 먼저 따라붙고, 그 순서를 모르면 시작하기도 전에 멈춘다. 지갑을 열고 네트워크를 확인하고 필요한 자산을 챙기는 사이, 쓰고 싶은 기능은 뒤로 밀린다. 초보자에게는 기능보다 절차가 더 큰 장벽이다. 그래서 첫 사용에서 먼저 마주치는 것은 편의가 아니라 확인 작업이다. 한 번에 끝날 일을 여러 번의 판단으로 쪼개 놓은 셈이다. dappOS는 그 틈을 파고드는 프로젝트로 보인다. dappOS는 그 부담을 앞에서 설명하지 않고 뒤에서 처리하는 쪽이다. 사용자의 목적을 먼저 받고, 체인 선택과 자산 연결, 승인 순서를 실행 계층이 이어 붙인다. 한 번의 요청처럼 보여도 안쪽에서는 여러 단계가 …
❤13👍1
코인 콘텐츠를 한 줄로 여는 xBubble 코인 관련 콘텐츠를 만들 때 가장 번거로운 건 도구가 아니라 순서다. 이미지, 영상, 아바타, 슬라이드를 따로 열고 각각에 맞는 말을 다시 맞춰야 해서, 간단한 공지 하나도 작업대 위에 흩어진 공구를 다시 찾는 일처럼 느껴진다. 무엇을 만들지보다 어떤 형식으로 시작할지 먼저 정해야 하니, 처음 들어오는 사람일수록 손이 느려지고 판단이 자주 끊긴다. 그래서 초보자는 기능을 모르는 게 아니라 시작점을 고르지 못해 멈춘다. 같은 목적이어도 준비 방식이 다르면 다시 처음으로 돌아가게 된다. xBubble은 그 막힘을 짧은 지시만으로 풀어내려는 AI 운영 체제다. xBubble 안에는 이미지, 영상, 아바타, 그 밖의 작업이 있고, 실제로는 이미지 생성, 영상 생성, 슬라이드, 말하는 아바타 같은 기능으로…
❤14
dappOS의 xBubble이 묶는 크립토 루틴 크립토를 다루다 보면 일은 늘 같은 모양으로 돌아온다. 오늘은 어떤 체인을 볼지, 어떤 알림을 먼저 볼지, 또 언제 다시 확인할지 챙겨야 한다. 버튼은 몇 번 안 되는데도 머릿속에는 메모가 여러 장 쌓여 간다. 수수료 준비와 지갑 연결과 결과 확인이 겹치면, 정작 보려던 정보는 뒤로 밀리고 판단의 시작이 더 늦어진다. 이런 흐름이 쌓이면 한 번의 거래보다 확인 순서가 더 큰 피로가 된다. 처음에는 작은 차이처럼 보여도, 며칠만 지나면 같은 질문이 계속 돌아와 손이 느려진다. xBubble은 그 메모를 짧은 요청으로 바꾸는 쪽에 가깝다. 원하는 결과를 적으면 시스템이 필요한 절차를 이어 붙인다. 사이트에 보이는 일정 작업, 최적화 요청, 경로 선택은 같은 생각 위에 있다. 사용자는 여러 도구를…
❤17👍5😢2
짧은 입력이 정리하는 암호화폐 일과 암호화폐 일을 시작할 때 막히는 지점은 정보가 아니라 순서다. 책상 위에 시세표와 메모와 알림이 겹쳐 있으면, 정작 무엇을 확인하려 했는지 흐려진다. 새 공지를 봐도 다시 지갑을 열고, 다시 기록을 찾고, 다시 알림을 맞춰야 하니 판단은 늦고 메모만 늘어난다. 처음 접하는 사람일수록 이 순서가 더 큰 장벽이 된다. 질문을 다시 쓰지 않아도 되는 점이 부담을 더 줄인다. xBubble은 이 앞단의 부담을 줄이려는 쪽에 서 있다. 짧은 지시만 남겨도 다음 일을 바로 열 수 있게 만든다. 사이트가 보여 주는 xBubble의 핵심은 낮은 입력으로 여러 일을 이어 붙이는 구조다. Bubble Up은 반복 작업을 다듬는 요청을 받고, 예약 작업은 매일 해야 할 일을 대신 기억한다. 연결된 기기와 개인 모드는 같은 …
❤17👍2
의도 한 줄을 실행으로 옮기는 dappOS 한 체인에서 산 자산을 다른 체인의 앱에 쓰려는 순간, 전통적인 Web3는 목적보다 절차를 먼저 드러냅니다. 어느 체인을 쓸지, 이동 경로는 무엇인지, 수수료는 어떤 자산으로 낼지, 승인 순서는 어떻게 맞출지까지 사용자가 직접 풀어야 합니다. 화면에 보이는 건 단순한 실행 버튼이지만, 뒤에서는 결정해야 할 항목이 계속 늘어납니다. 처음 쓰는 사람일수록 기능보다 준비물 목록이 먼저 보이고, 같은 결과를 원해도 출발 전에 생각이 길어집니다. 결국 사용자는 결과보다 경로를 먼저 외우게 됩니다. dappOS는 이 부담을 거래가 아니라 의도로 받습니다. 사용자는 무엇을 하고 싶은지만 적어 서명하면, 네트워크 안의 실행자들이 최적의 경로를 찾고 결과를 검증합니다. 구조는 의도 실행 네트워크에 가깝고, 실제 …
❤16
의도와 거래의 순서를 바꾸는 dappOS Web3의 진입 장벽은 버튼 수보다 순서에 있다. 사용자는 무엇을 할지 정하기 전에 체인, 지갑, 토큰, 수수료를 먼저 맞춰야 하고, 한 단계만 어긋나도 다시 출발선으로 돌아간다. 택시 앱에서 목적지를 넣는 대신 차량 종류와 결제 방식과 경로 규칙을 먼저 고르는 셈이다. dappOS는 이런 거래 중심 흐름을 그대로 두지 않고, 처음 질문을 의도 쪽으로 옮긴다. 그래서 초보자에게는 기능보다 준비 항목이 먼저 보이고, 규칙을 배우는 부담이 먼저 온다. 사용자가 처음부터 학습해야 하는 것은 기능이 아니라 절차라는 점이 문제다. 여기서 인텐트는 사용자가 얻고 싶은 결과를 뜻한다. dappOS는 이 결과를 하나의 작업으로 묶고, 그 작업에 맞는 실행 경로를 뒤에서 조합하는 구조로 읽힌다. 사용자가 매번 네트…
❤16
거래를 조립하지 않는 dappOS Web3를 처음 만나는 사람은 배달 앱이 아니라 주방에 들어간 사람처럼 움직인다. 무엇을 얻을지보다 어느 체인을 쓸지, 자산을 어디에 두고 수수료를 어떻게 맞출지부터 계산해야 해서다. 체인을 바꾸는 순간 승인과 확인이 다시 따라붙기 때문에, 거래는 기능보다 흐름에서 먼저 복잡해진다. dappOS가 건드리는 지점은 이 앞단이다. 결과를 정하기 전에 절차를 외우게 만드는 방식이 부담을 키운다. 익숙한 서비스와는 출발선이 다르다. 사용법보다 판단이 먼저다. 서비스 이름보다 먼저 챙길 것들이 보인다. 여기서 intent는 원하는 결과를 뜻한다. 사용자가 남기는 것은 세부 단계가 아니라 목적과 허용 범위다. 그러면 매칭자가 맞는 상대를 찾고, 실행자가 실제 일을 맡고, 검증자가 끝난 결과를 확인한다. 핵심은 과정을…
👍15❤5
Showing the 12 most recent of 92 posts we hold for @PASACREW. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked ≈ was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.
Citation-graph rank — 81,153 of 1,151,006entries in the measured graph. A weighted position computed from the forward and mention edges below — republished posts weigh more than named mentions — and recomputed periodically, over the whole graph. Published only as this ordinal position, never as a score: a position is a fact, and a score printed beside one channel’s name would read as a verdict this register does not make. The two counts beneath stay separate for the same reason mentions are never summed with forwards anywhere else on this page — a named-by count costs nothing to manufacture. The top 100 by this measure, or how it is computed.
Republished by
Channels on the register that have forwarded this channel's posts into their own feed.
Republishes
Channels on the register whose posts this channel has forwarded.
Built only from forwarded posts we have actually read, on both sides. Coverage is early and deliberately incomplete: a missing link means we have not read the post that would prove it, never that the relationship does not exist. Counts are distinct forwarded posts observed, so they only ever go up as we read more.
Named by 3 registered channels — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.
Named by
Channels on the register whose posts name this channel's handle.
A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.
A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 12 August 2026 — this entry's latest reading, not the date you are reading this.
“PASA 공지방” (@PASACREW), 6,995 subscribers as measured 12 August 2026. Telegram Register, tgregister.com/channel/PASACREW.
Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.