Crypto onboarding, anti-scam and airdrop guides in English: compliant fiat on/off-ramps, wallet security, token approval management, and choosing platforms — every claim cites sources and data dates.https://szb123.com/en/enhttps://szb123.com/en/articles/muse-gcp-signup-guide/https://szb123.com/en/articles/muse-gcp-signup-guide/Unlike a traditional step-by-step tutorial, this one has Muse do the Google Cloud sign-up for you, which makes the whole process much simpler.Fri, 09 Oct 2026 00:00:00 GMTFirst, a heads-up: this is long — about 5 minutes of reading (<strong>the core content takes 1 minute</strong>). Unlike a traditional step-by-step tutorial, this one has Muse assist with the Google Cloud sign-up, so the overall flow is much simpler. Learning AI starts with claiming freebies. Google Cloud Platform (GCP) offers a free server. Compared with Oracle Cloud servers (<a href="https://x.com/yedabinbinah/status/2107821765938512173">see the Oracle tutorial here (in Chinese)</a>), it's the number-two choice — still a very good free server resource. (An Amazon free-server tutorial is coming soon.) <strong>The free Google Cloud server can host a VPN for your own use, so you never need to buy VPN software or subscribe to proxy nodes again❗ Nothing of the kind — and your traffic stays very, very safe.</strong> <strong>❗ The Muse skill prompt for installing the HY2 VPN software is pending an update (bookmark and subscribe; it will be updated in a few days)</strong> <strong>What to prepare:</strong> 1. Any China-issued bank card, debit card, or Visa card works. I recommend the China Merchants Bank Mastercard debit card — for freebie-hunting, a debit card is the safest option, because if there's no balance in it, nothing can be charged. Case in point: someone on X bought Grok Heavy with a 3-month trial for $30; when it expired, he renewed without reading carefully — it was apparently $3,000 a year. He thought "$3,000 a year" was a bargain, didn't look closely, and bought it outright. The money still hasn't been refunded, two-plus months later. (See <a href="https://x.com/yedabinbinah/status/2096871142917349731">four foreign-currency debit cards available in China (in Chinese)</a>.) 2. A Google account — old or new both work, with a difference: old accounts need a $50 deposit, new accounts $1–10. (With a debit card you need to purchase $50 of foreign currency; with a credit card you don't. This $50 is the threshold — it works like a deposit: with the deposit in place you can use Google Cloud, and if the deposit is refunded, GCP shuts down automatically.) 3. If you are a Gemini Pro user, you can claim $10 of credit for free every month: visit the <a href="https://developers.google.com/profile/benefits">Google Developer Program</a>. <strong>The hands-on prompt (copy it into the AI chat box):</strong> Based on this file, <a href="https://szb123.com/files/gcp-free-vps-skill.md">https://szb123.com/files/gcp-free-vps-skill.md</a>, help me register for Google Cloud Platform. Use the cloud browser, and follow the tutorial to operate the GCP server for me.  *Muse and Cue registering Google GCP — screenshot proof* <strong>Supported AIs:</strong> Grok's Bot ChatGPT's Dot Meta's Muse <strong><a href="https://x.com/yedabinbinah/status/2108085710872023090">Manus's Cue</a> <a href="https://x.com/yedabinbinah/status/2104572811180408928">Tencent's LightVela</a></strong> Google's Spark <strong><a href="https://x.com/yedabinbinah/status/2106986848124116998">Hark</a> All the AIs above support this prompt — copy it and paste it into the AI chat box to run.</strong> ## <strong>❗❗ The detailed walkthrough below is just for reference — it has already been baked into the skill prompt</strong> <strong>Google Cloud Platform permanently free VPS setup tutorial (beginner-friendly, with screenshots)</strong> **Free allowance at a glance (the free instance created by the script):** | Item | Allowance | Note | |---|---|---| | Specs | 1 vCPU / 1 GB RAM / 30 GB disk | Can stay on long-term | | Inbound traffic | Unlimited | Only egress is counted | | Outbound traffic | 200 GB/month (standard tier) | Traffic to the Akamai / Cloudflare / Fastly CDNs is not free | | Public IP | Dynamic IP, free | Changes on every reboot; only static/reserved IPs cost money — don't upgrade by accident | ## 1. Preparation before signing up 1. What you need - ✅ A <strong>Google account</strong> - ✅ A <strong>credit card / virtual card / debit card</strong> that passes verification (⚠️ strongly recommend a virtual card or debit card — don't bind your main credit card) - ✅ A network environment that can reach Google normally 2. Card verification (success rate varies) GCP sign-up requires a payment method; the verification charge <strong>varies by account</strong>: | Account status | Verification | Result | |---|---|---| | Trusted old account | Verification only, no charge — bind and go | Least hassle | | Newer account | Pre-charge of $2 / $10 / $50, varies | Money goes to account balance (not really spent) | Since 2026, most new accounts are charged for verification after the tightening. ⚠️ **Google tightened risk controls because the $300 GCP credit was abused** > 💡 <strong>Field-tested notes:</strong> the <strong>Fiat2</strong>4 virtual card works, but in China it currently requires passport registration (the ID-card channel is closed). The <strong>CMB Mastercard debit card and CITIC Visa debit card</strong> have both passed verification (Japan region, with an 8000 JPY pre-auth). The charged amount <strong>goes into your GCP balance rather than being spent</strong>; you can request a refund, but after refunding, GCP becomes unusable — treat it as a threshold fee. 3. New users: don't forget the $300 trial credit First-time GCP users usually get a <strong>$300 / 90-day</strong> trial credit. During the trial you can spin up premium-network machines in Taiwan or Hong Kong to your heart's content; <strong>once it's used up or expired, come back and set up the permanently free machine with this tutorial</strong>. 4. What can you actually do with GCP? Host a free personal blog, or run VPN software — in my view those are the two most common uses. ## 2. Understand the core logic of "permanently free" <strong>In one sentence</strong>: after opening a paid Google account, you use the <strong>free service limits (Free Tier)</strong> Google provides to use it for free. But remember: > ⚠️ GCP's billing system is "price first, discount later" — the system first calculates what you used (hours run, traffic consumed) at list price, then <strong>offsets</strong> it against the free tier. Once something is misconfigured or you exceed the free allowance, real charges appear. That's what people call getting "clawed back".   Gemini's plain-language explanation:  The official Google rule, in short: within the <a href="https://docs.cloud.google.com/free/docs/free-cloud-features?hl=zh-cn#free-tier">monthly Free Tier usage limits</a>, usage of specific products is free — <strong>you only pay for the part that exceeds the limits</strong>. > 📌 <strong>Traffic-tier explainer</strong> (a common misconception in the comments): the claim that "free traffic is down to 1 GB" is a rumor. The 1 GB figure refers to the premium network tier; the standard tier is 200 GB/month, and the script in this guide creates a standard-tier instance. Whether something is charged follows the <a href="https://cloud.google.com/skus">official SKU page</a>. ## 3. Set up budget alerts (anti-clawback step one) Before deploying anything, do this first: 1. In the console, go to <strong>Billing → Budgets & alerts</strong> 2. Create a budget with a monthly amount (say $1) 3. Check <strong>email alert at threshold</strong> 4. Advanced: enable alerts that <strong>include credits</strong> — you'll also be notified when trial credits are nearly exhausted > 💡 <strong>Set it with confidence:</strong> budget alerts don't count the free allowance as spend. It's a pure safety fuse and costs nothing. The moment any unexpected billing shows up, you get an email. Freebie bonus: Google Developer membership gives $10/month Join the <a href="https://developers.google.com/profile/benefits">Google Developer Program</a> (requires membership eligibility) to <strong>claim $10 of credit per month</strong> attached to your billing account: - With that $10, even paid-CDN traffic is covered — <strong>you may skip the CDN firewall block entirely</strong> - But <strong>keep the 200 GB traffic monitor on anyway</strong> — if you really get hit with a traffic spike, $10 won't cover it ## 4. One-click deployment via Cloud Shell 1. Activate Cloud Shell Open the <a href="https://console.cloud.google.com/">Google Cloud console</a>, click the <strong>Activate Cloud Shell</strong> icon in the top-right corner, and you'll get a web-based terminal:  2. Run the automation script This guide deploys with the community open-source script <strong><a href="https://github.com/fatekey/gcp_free">fatekey/gcp_free</a></strong>. In Cloud Shell, enter: ```bash # First run git clone https://github.com/fatekey/gcp_free && cd gcp_free && bash start.sh # Subsequent runs cd ~/gcp_free && bash start.sh ``` > ⚠️ The script requires GCP to be in a <strong>trial-credit or paid state</strong>. If it errors with "no available billing account", your account is neither in trial nor paid — finish binding a card first. 3. Common error: project not set If you see: ``` The required property [project] is not currently set ``` it means Cloud Shell isn't attached to a specific GCP project. <strong>Fix</strong>: Open the project selector at the top of the console and find your project ID:  Then run: ```bash gcloud config set project your-Project-ID cd ~/gcp_free && bash start.sh ``` ## 5. Walking through the script options (with real pitfalls) > 📋 Script main menu: 1 create instance · 3 reroll AMD · 4 firewall rules · 5 Debian mirror swap · 6 install dae · 7 configure dae · 8 traffic monitor · 9 delete resources Option 1: create the free instance For the region, <strong>Oregon, US West</strong> is recommended (low latency):  ``` --- Choose a deployment region --- [1] Oregon [recommended] [2] Iowa [3] South Carolina Enter a number (1-3): 1 ``` Then pick a zone (any of us-west1-a / b / c; the default is usually fine). > 💡 <strong>OS choice:</strong> the script supports Ubuntu and Debian, <strong>but the mirror swap (option 5) and traffic monitor (option 8) are only adapted for Debian</strong> — just pick <strong>Debian</strong> without thinking. Option 3: reroll for an AMD CPU (tested — not recommended) - The CPU is randomly assigned Intel or AMD on each boot; AMD is less than 10% faster, and you must power off and reboot to "reroll" - Field test: <strong>in US West you basically can't get AMD anymore</strong>; the script author's own words — "rerolling not advised" - Play it safe: just use the <strong>default Intel machine</strong> ✅ Option 4: firewall rules (⚠️ the heart of anti-clawback) Free egress traffic <strong>does not include the three paid CDNs — Akamai, Cloudflare, Fastly</strong>. Visiting sites behind those CDNs (ChatGPT, GitHub, DockerHub, etc.) generates a few cents per month in charges. The script creates two rules: - ✅ <strong>Allow all inbound</strong> - ✅ <strong>Block the outbound IP ranges of the three paid CDNs (Akamai / Cloudflare / Fastly)</strong> (generated from official geoip data) > 💡 If you have credits (like the $10 developer membership), you can skip the block — the few cents are covered directly. Option 5: Debian mirror swap (twinned with the firewall) <strong>The causal chain</strong>: Debian's default software mirrors sit behind a CDN → once the firewall blocks the CDN, apt can't connect → every later install (unzip, vnStat, etc.) fails. So: <strong>if you enabled the CDN block in option 4, you must run option 5 to switch to US mirrors that don't sit behind a CDN</strong>. The vnStat install failures in the comments were all traced to a missing mirror swap. Option 6: install dae (a pitfall minefield in practice) <strong>What dae is and why install it</strong>: after the firewall blocks the paid CDNs, sites behind those CDNs (ChatGPT, GitHub, DockerHub) become unreachable. dae is an eBPF proxy <strong>client</strong> (similar to clash on Linux) — its job is to <strong>route that blocked traffic out through a proxy</strong>. > ⚠️ <strong>Common beginner misconception:</strong> dae is for giving your little server a proxied connection out — it is not for running the server side. If you want to run a node (as a commercial proxy server), you can do that without dae — but this machine has mediocre routing and limited traffic, so it's <strong>better suited as an exit/backup box</strong>, not for serving the public. Pitfalls I actually hit (from the original post): <strong>Pitfall 1: apt fails to install unzip</strong> — <a href="https://deb.debian.org">deb.debian.org</a> unreachable: IPv6 first reports "Network is unreachable", falling back to IPv4 then times out. Cause: no mirror swap (see option 5).  <strong>Pitfall 2: the version string comes back empty</strong> — the script prints "Installing dae version ..." followed by nothing, the download URL gets a double slash .../download//dae-linux-x86_64.zip, and it finally errors "The checksum of the downloaded file does not match!". Cause: what got downloaded was actually GitHub's 404 page — checksumming a web page obviously fails. > 🔧 <strong>Later fixed:</strong> the script author confirmed the dae official install script had broken and <strong>fixed it in March 2026</strong> — just follow the script now. If it still misbehaves, jump to section 6 and install manually.  <strong>Pitfall 3 (advanced)</strong>: the newer dae 2.0 occasionally fails to reach the network after starting on GCP's Debian image kernel (a userspace forwarding compatibility issue); the case in the comments was solved by downgrading to dae 1.1. If you hit it, install a pinned version manually — don't fight it. Option 7: configure dae The script uploads your edited local config.dae (the cloned template) to the server at /usr/local/etc/dae/config.dae and starts dae. All you do beforehand is edit that file <strong>locally</strong> (in Cloud Shell) and fill in your proxy node (see section 6, step 5). Option 8: traffic monitor (⚠️ must enable) Total free traffic is <strong>200 GB/month</strong>; the script auto-limits at <strong>180 GB</strong>, with two schemes: - <strong>Scheme 1</strong>: auto <strong>power off</strong> at the cap; manually power back on on the 1st of next month (a reboot resets the traffic counter) - <strong>Scheme 2</strong>: auto <strong>block all inbound traffic except SSH</strong> at the cap; auto-resets on the 1st of next month Option 9: delete resources Not happy with the free machine's configuration? Delete it in one click and recreate in another region. ## 6. Manual dae install and configuration (fallback if the script fails) 1. SSH into the VM From Cloud Shell (swap in your own machine name and region; defaults shown for this guide's flow): ```bash gcloud compute ssh free-tier-vm --zone=us-west1-a ``` > 💡 On first connect, GCP generates an SSH keypair automatically (private key stored in Cloud Shell at ~/.ssh/google_compute_engine). Just press Enter — no password needed. 2. Install dae itself Following the <a href="https://github.com/daeuniverse/dae/blob/main/docs/en/README.md">official dae README</a>, copy-paste: ```bash # Download and install (v1.0.0 shown; switch versions if you hit compatibility issues) cd /tmp wget https://github.com/daeuniverse/dae/releases/download/v1.0.0/dae-linux-x86_64.zip unzip dae-linux-x86_64.zip sudo mv dae-linux-x86_64 /usr/local/bin/dae sudo chmod +x /usr/local/bin/dae sudo ln -sf /usr/local/bin/dae /usr/bin/dae # Verify the install dae --version ``` 3. Download the geodata routing databases ```bash sudo mkdir -p /etc/dae cd /etc/dae sudo wget -O geoip.dat https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/geoip.dat sudo wget -O geosite.dat https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/geosite.dat ``` 4. Create the systemd service ```bash sudo tee /etc/systemd/system/dae.service > /dev/null <<EOF [Unit] Description=dae Service Documentation=https://github.com/daeuniverse/dae After=network-online.target docker.service systemd-sysctl.service Wants=network-online.target [Service] Type=notify User=root LimitNPROC=512 LimitNOFILE=infinity ExecStartPre=/usr/bin/dae validate -c /etc/dae/config.dae ExecStart=/usr/bin/dae run --disable-timestamp -c /etc/dae/config.dae ExecReload=/usr/bin/dae reload -c /etc/dae/config.dae Restart=on-abnormal [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload ``` 5. Write the configuration file ```bash # Copy from the example config (well-commented — recommended) sudo mkdir -p /etc/dae sudo cp /tmp/example.dae /etc/dae/config.dae sudo chmod 0600 /etc/dae/config.dae sudo nano /etc/dae/config.dae ``` <strong>Single-node users can copy this homework directly</strong> (VLESS + TLS shown). Core ideas: - node block: keep only your node, delete the rest - routing block: domestic traffic direct; common foreign services through the proxy ``` global { tproxy_port: 12345 tproxy_port_protect: true pprof_port: 0 so_mark_from_dae: 0 log_level: warn disable_waiting_network: false enable_local_tcp_fast_redirect: false wan_interface: auto auto_config_kernel_parameter: true tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111' tcp_check_http_method: HEAD udp_check_dns: 'dns.google:53,8.8.8.8,2001:4860:4860::8888' check_interval: 120s check_tolerance: 50ms dial_mode: domain allow_insecure: false sniffing_timeout: 100ms tls_implementation: utls utls_imitate: chrome_auto mptcp: false bandwidth_max_tx: '500 mbps' bandwidth_max_rx: '1 gbps' } node { my_hub: 'your-vless://subscription-link' } dns { upstream { googledns: 'tcp+udp://dns.google:53' cloudflareDns: 'tcp+udp://1.1.1.1:53' alidns: 'udp://dns.alidns.com:53' } routing { request { qname(geosite:cn) -> alidns qname(geosite:google) -> googledns fallback: cloudflareDns } } } group { proxy { filter: name(my_hub) policy: fixed(0) } } routing { pname(NetworkManager) -> direct dip(224.0.0.0/3, 'ff00::/8') -> direct dip(geoip:private) -> direct l4proto(udp) && dport(443) -> block dip(geoip:cn) -> direct domain(geosite:cn) -> direct domain(geosite:google) -> proxy domain(geosite:github) -> proxy domain(geosite:telegram) -> proxy dip(geoip:telegram) -> proxy domain(geosite:netflix) -> proxy domain(geosite:youtube) -> proxy domain(geosite:spotify) -> proxy domain(geosite:openai) -> proxy fallback: proxy } ``` > 💡 <strong>For a single-node setup, mind just two things:</strong> 1. In the node block add: my_hub: "your-subscription-link" 2. In the group block add: filter: name(my_hub). No proxy of your own? See the FAQ at the end. 6. Start and verify ```bash # Validate the config sudo dae validate -c /etc/dae/config.dae # Start and enable on boot sudo systemctl enable --now dae # Check status systemctl status dae --no-pager # Check logs and confirm the node reports ALIVE sudo journalctl -u dae -n 50 --no-pager | grep -E "ALIVE|node list" ``` ## 7. Test the node + finish anti-clawback housekeeping 1. Connectivity test ```bash # The returned IP should be your proxy node server's IP curl -L ip.sb # Check dae logs for anything unusual sudo journalctl -u dae -n 20 --no-pager ``` 2. Firewall + traffic monitor (back to script options 4 and 8) If you skipped them during deployment, come back and finish: - <strong>Option 4 firewall</strong>: allow all inbound + block the three paid CDNs outbound — the core of anti-clawback - <strong>Option 8 traffic monitor</strong>: auto-limit at 180 GB so a traffic flood can't burn you 3. Learn to read the bill (panic relief) Don't panic when you see numbers on the bill — <strong>gross cost ≠ actual charge</strong>: - Look at the rightmost column for the <strong>amount after adjustments</strong> — anything offset by the free allowance shows as 0 - In the billing report, distinguish two kinds of "savings": <strong>"from credits"</strong> (trial credit offsets; gone when used up) and <strong>"spend-based discounts"</strong> (the permanent free tier; always in effect) - What actually deserves vigilance are <strong>small charge items that can't be offset</strong> (like a few dozen cents for a static IP or snapshots) — turn them off when spotted > 📖 <strong>A real case:</strong> a reader was scared by "being charged $6–7/month" on the free machine and asked for help. Digging in, almost all of it was gross cost that would be offset. The real problem was a hidden <strong>$0.49/month</strong> charged item (an unpaid component left on) — turning it off brought it to zero. 4. Install a monitoring probe (optional) Finally, install a <a href="https://github.com/komari-monitor">komari</a> probe, and watch it light up:   > <strong>Security reminder:</strong> some users had miners planted through probe (e.g. Nezha) vulnerabilities, getting the machine banned by GCP with difficult appeals. <strong>Always disable "run command"-style permissions on probes</strong> — or don't install one at all if unsure. ## ❓ FAQ (high-frequency questions from the comments) <strong>Q1: docker pull fails — what now?</strong> DockerHub sits behind Cloudflare and got blocked. Switch the registry mirror to <a href="http://mirror.gcr.io">http://mirror.gcr.io</a>, or let dae proxy it through. Bridges created by Compose (br-xxx) must be added to dae's lan_interface to go through the proxy. <strong>Q2: What is this free machine good for?</strong> ✅ Good for: a backup box, exit routing, small self-hosted projects (password managers, memos notes, personal services). GCP's IPs are cleaner than most cheap VPS providers', the IP stays stable if you never power off, and risk controls are light. ❌ Not good for: serving proxy nodes or hosting sites for the public — mediocre routing, limited traffic; one DDoS and the 200 GB is gone. <strong>Q3: I want my site faster — how?</strong> You can't sit behind the three blocked CDNs, but you can use the free CDN tiers of <strong>Tencent / Alibaba / AWS CloudFront</strong> (field reports say EdgeOne also doesn't get charged). <strong>Q4: Will the IP change? Does it cost anything?</strong> The dynamic IP is <strong>free</strong> and re-randomizes on reboot; it stays the same as long as you don't power off. <strong>Never upgrade the IP to static/reserved in the console</strong> — that one is billed hourly. <strong>Q5: Can I run a hysteria2 / hy2 node?</strong> ⚠️ Not recommended. Users report hy2's aggressive packet sending <strong>tripped GCP risk controls and got machines banned</strong> (appeals work but it's a hassle); ss/snell have also had bans. Plain VLESS/Trojan runs fine long-term. ## 8. Timeliness and risk notes (compiled October 2026) | Risk point | Current state | Advice | |---|---|---| | Tightened sign-up charges | Due to $300-credit abuse, Google tightened verification; most new accounts get a pre-charge ($2/$10/$50 — goes to balance, refundable, but refund = unusable) | Set expectations; don't bind your main credit card | | Traffic-tier rumor | "Free traffic down to 1 GB" is a rumor: 1 GB = premium tier; the script's standard tier = 200 GB | Follow the official SKU page | | IP billing | Dynamic IP free; static/reserved IP charged (about $3–4/month) | Don't upgrade to a static IP | | Paid CDNs | Akamai / Cloudflare / Fastly egress isn't free; other providers fine | Enable the firewall block | | Protocol risk control | hy2's aggressive packets can get machines banned | Use conventional protocols like VLESS/Trojan | | Mining intrusions | Probe vulnerabilities led to miners → bans hard to appeal | Disable command permissions on probes, or skip them | | Verification charges vary | $2 / $10 / $50 all seen; depends on the account's "mood" — normal; money goes to balance | | <strong>The safest principle:</strong> bind a virtual/debit card → set budget alerts → enable firewall + traffic monitor → glance at the "after adjustment" bill once a month. <strong>❗ The Muse skill prompt for installing the HY2 VPN software is pending an update (bookmark and subscribe; it will be updated in a few days)</strong>MuseGoogle CloudGCPFree ServersAI Agenthttps://szb123.com/en/articles/nvidia-macos-driver/https://szb123.com/en/articles/nvidia-macos-driver/An open-source project brings RTX Metal drivers to the Hackintosh: supported cards, three install methods, the security price, and how to uninstall.Thu, 08 Oct 2026 00:00:00 GMT## What This Project Does NVIDIA GPU users have been stuck in an awkward spot in the macOS world for years: Apple long ago stopped providing official drivers for new generations of NVIDIA cards, so Hackintosh users who install an RTX card can only use it to light up the display — Metal acceleration, games, Core ML, everything a GPU is actually for is out of reach. The open-source project [nullmoth/nvidia-macos-driver](https://github.com/nullmoth/nvidia-macos-driver) exists to fill this gap: it provides a **Metal driver** under macOS 15 Sequoia for NVIDIA cards of the Turing architecture and newer (GTX 16 series, RTX 20/30/40/50 series, TITAN RTX, and some Quadro/RTX workstation cards). The goal is to make these cards work normally on a Hackintosh, just like officially supported Apple GPUs — driving the desktop, running Metal apps, playing games, and even supporting compute workloads such as Core ML/MPS and OpenCL. If you want to read the source code or follow the progress, go straight to the repository home page: **[github.com/nullmoth/nvidia-macos-driver](https://github.com/nullmoth/nvidia-macos-driver)** (as of 2026-10-08, the repository page shows 442 stars and 45 forks, with the README and Issues both actively updated). ## How It Pulls It Off The project's technical route is quite interesting: rather than building a wheel from scratch, it wires several existing open-source building blocks together. The shader code emitted by Metal applications (Apple AIR format) is first translated into SPIR-V, then handed to NVK — the mature NVIDIA Vulkan backend inside the Mesa project — which finally drives the hardware through NVIDIA's own open-source GPU kernel modules (the r610 series) and an unmodified GSP firmware. Display output, the accelerator, and other pieces are filled in by a few kernel extensions bundled with the project. For ordinary users, this chain means two things. One: it stands on top of Mesa/NVK, code the Linux world has stress-tested over and over — this is not a toy project. Two: it depends on NVIDIA's open-source kernel modules, so only newer Turing-and-later cards are supported; older cards (the GTX 10 series, for instance) are out of scope. On the feature front, the support list in the README includes most of Metal 3 (argument buffers tier 2, ray tracing, mesh shaders, MetalFX), OpenGL, OpenCL, Core Image, and Core ML. For anyone who wants to run some AI inference workloads on a Hackintosh, Core ML/MPS getting GPU acceleration is a more practical benefit than “being able to play games.” ## Before You Install, Think Through Three Things **First: the security price.** Installing this driver requires allowing unsigned kernel extensions to load, turning off Apple's Secure Boot, and adjusting AMFI-related parameters — these are real security downgrades; you are opening a hole in the system. Before installing, be clear with yourself: is there any data on this machine that cannot take the risk? Are you willing to accept this price for a graphics card? **Second: maturity.** The project says it plainly itself: “the driver is new, and it may not work on every computer.” The README's device compatibility table is broad, but **the only card actually verified on real hardware is a single RTX 5060**; after installation, the first boot may pause at “PCI configuration end” for up to a minute, which is normal behavior. Only start if you enjoy tinkering and can accept failure and rollback. **Third: the license.** The driver's main components use PolyForm Noncommercial 1.0.0 — personal use, research, and education are all fine, but **commercial use is explicitly prohibited**. Thinking of using it to speed up the company's Hackintosh work machine? Drop that idea. ## Three Ways to Install ### Option 1: the 1401 app (most recommended) Download the DMG from the project's [Releases page](https://github.com/nullmoth/nvidia-macos-driver/releases) and run the 1401 app inside. It automatically finds your OpenCore config, backs it up first, and then completes the driver installation; uninstalling is one click from the launcher — the friendliest flow for beginners, and you have a backup to fall back on if anything goes wrong. ### Option 2: precompiled package + install script Also download the tar.gz archive from Releases, **first verify the SHA256 checksum provided in the README** (don't skip this step — kernel extensions are files that go deep into the system), extract it, and run `sudo ./install.sh`. The script automatically rebuilds the Auxiliary Kernel Collection; after rebooting, allow the extension in System Settings. ### Option 3: manual integration into OpenCore (for veterans) Users who maintain their own OpenCore configuration can wire the driver components in manually. The key points listed in the README include: setting csr-active-config, adding specific boot-args, ResizeGpuBars=13, excluding IONDRVSupport, and disabling SecureBootModel; on the BIOS side you need Above 4G Decoding enabled and CSM off, and the SMBIOS should imitate iMacPro1,1. This route assumes you have a basic grasp of Hackintosh boot mechanics — if you have no idea at all, first go study the [Dortania OpenCore guide](https://dortania.github.io/OpenCore-Install-Guide/) and then come back to it. ## Uninstall and Rollback If you installed with the 1401 app, choose uninstall from the launcher; if you installed with the script, run `sudo ./uninstall.sh` and then reboot. Both methods restore the system to its pre-install state — which is why I recommend confirming your OpenCore config is backed up before you start: if the driver fails to light up on your configuration, rolling back is a single command away. ## Final Thoughts For Hackintosh users, this project fills a gap that has hung open for years; for general readers, it shows how the open-source community assembles building blocks like Mesa/NVK and NVIDIA's open-source kernel modules into something new. But remember its own positioning: very new, strongly experimental, and verified on exactly one card. If you want a taste, try it on a machine that doesn't matter; for your main machine, wait until it matures a little. Everything about the project is governed by the current notes on the repository page — the access date for this article's figures and conclusions is 2026-10-08.NVIDIAmacOSHackintoshOpen SourceGPUhttps://szb123.com/en/articles/oracle-cloud-signup-guide/https://szb123.com/en/articles/oracle-cloud-signup-guide/A 10-step field record to the console: 2026 A1 hours are metered monthly, avoid Seoul and Tokyo as home region, card verification charges nothing.Wed, 07 Oct 2026 00:00:00 GMT## Why this article Oracle Cloud's Always Free tier is one of the few big-vendor plans that still gives individuals genuinely permanently-free virtual machines: the Arm-based Ampere A1 instance quota is enough to run a blog, a proxy, or a small service day to day. But it has two old problems: the sign-up flow is long, and the numbers in older Chinese-language tutorials are outdated. This article is the working manuscript from turning that sign-up flow into an AI registration-wizard skill and walking readers through it step by step: every screenshot comes from my own October 2026 registration, and every policy number was checked against Oracle's official pages (sources at the end, accessed 2026-10-07). First, the most important changes. ## Read the 2026 free allowance carefully first The sign-up entry is at [oracle.com/cloud/free](https://www.oracle.com/cloud/free/). The free tier has two layers:  - **Trial layer**: new users get $300 of cloud credit, valid for 30 days, usable on almost all OCI services. - **Always Free layer**: after 30 days, without upgrading to paid, the account automatically moves to the permanently-free state, with the resources below available indefinitely. The key change concerns Arm compute (Ampere A1). Oracle's current documentation puts it as: per tenant, the **first 1,500 OCPU hours + 9,000 memory GB hours each month** are free. Translated into plain terms: **2 OCPU / 12 GB can run 24/7 for the entire month**; you can also configure 4 OCPUs / 24 GB, but only for about half a month — beyond the free hours, the instance gets stopped.  The "4 cores / 24 GB permanently free" in many old tutorials online reflects an earlier policy — running 4/24 for a full month takes about 3,000 OCPU hours, already beyond today's 1,500. Launch an instance on the old numbers and it will shut down mid-month; that's not a fault, the allowance ran out. Other Always Free resources include two AMD micro instances (1/8 OCPU + 1 GB RAM each) and 200 GB of block storage in total; the docs also note each instance's boot volume must be at least 47 GB, so two instances eat nearly 100 GB — the 200 GB disk is not roomy, so plan headroom. ## Before you start: three eligibility checks 1. **An email address that actually receives mail.** It becomes your login account, and one email address can register only one account. 2. **A real credit card.** Visa / Mastercard / Amex; debit cards carrying a card-network logo that work without a PIN also qualify. Oracle's official FAQ says it explicitly: PIN-debit cards and virtual, one-time, and prepaid cards are not accepted. This is the only hard requirement in the whole flow — no workarounds. The risk section at the end expands on this. 3. **Decide your home region.** Step 5 of sign-up asks for the "Home Region", which decides the data center where your account and all resources live, and **it can never be changed after registration**. If you want A1 instances, steer clear of Seoul and Tokyo — the sign-up page itself pops a warning about high A1 demand in those two regions, and the official FAQ confirms the "out of host capacity" error means the home region temporarily lacks free capacity. Nearby alternatives include Osaka, Chuncheon, Singapore, Sydney, and Melbourne; the rule of thumb is: close to you. ## The 10-step sign-up flow All screenshots below come from my October 2026 registration, with all demo information redacted. ### Step 1: open the sign-up entry Go to [oracle.com/cloud/free](https://www.oracle.com/cloud/free/) and click **Start for free**; you'll land on the signup.cloud.oracle.com page. When you see the "Account Information" form, you're in place.  ### Step 2: fill in account information Three fields: country/region (pick truthfully), name in pinyin, and email. The page explicitly requires truthful, valid details — beyond compliance, the official FAQ also states each person is allowed one free account, and creating or attempting to create multiple free accounts gets you banned. If you've registered before, your details cannot be reused.  ### Step 3: CAPTCHA + email verification Check the hCaptcha box (it may ask you to pick images twice — normal), click "Verify my email", then go to your inbox **immediately** for the message titled "Verify your email address" and click the button inside. Note: in my test this verification link is **valid for only 30 minutes** — the most common place beginners get stuck. If it doesn't arrive, check spam first; if it's not there, go back to the sign-up page and resend once (each resend invalidates the old link).  ### Step 4: set password and customer type Passwords must be 8–40 characters, mixing upper- and lower-case letters, digits, and special characters, and cannot contain your username, name, or email — the page gives live feedback on whether you qualify. For Customer type, choose **Individual**. Leave the Cloud account name at its default: it is your future "tenant name", needed to sign in to the console — **write it down**.  ### Step 5: choose the home region (the most critical step of all) Once more: **after choosing, it can never be changed**. My field-test choice was Melbourne (Australia Southeast). Tick "I confirm my home region cannot be changed later" and continue. The red box in the screenshot below is the official warning about Seoul/Tokyo capacity.  ### Step 6: fill in address and phone Enter your mailing address and mobile number truthfully. Format the phone per the page: if you picked +61, enter the mobile number directly without adding the domestic long-distance prefix 0. The page notes that SMS-only numbers aren't accepted — if anything goes wrong, Oracle may call you, so keep it real.  ### Step 7: card verification (no charge) First, the official page's own words: the free tier charges nothing; the small temporary hold that may appear on your payment method is only for verification and will be removed automatically; **Oracle does not accept any virtual, prepaid, or one-time cards**.  Click "Add payment verification method" → pick the card type → enter card number, expiry, CVN → click Finish and wait for the green checkmark. Oracle's documentation is explicit: a small temporary charge (a pre-authorization) may appear during verification and will be removed automatically, and **as long as you never actively upgrade the plan, the credit card will never actually be charged**; the official FAQ adds that banks reverse the pre-authorization within 3–5 days.  ### Step 8: submit the application Agree to the terms, click "Start my free trial". The page says account creation can take up to 15 minutes, and you'll get an email when it's done. While waiting, do a final self-check: is the card real? Are your details different from any old account? Did you avoid Seoul/Tokyo for the home region?   ### Step 9: first sign-in + two-factor Click Sign in from the activation email, and sign in with "Cloud account name + username + password". The first sign-in forces you to set up 2FA: install **Oracle Mobile Authenticator** from your phone's app store (look for the red ORACLE icon), then scan the QR code to bind.  ### Step 10: into the console If the account info at the top-left shows Free Tier, you're done. Two suggestions: **do not click upgrade** (after upgrading, usage beyond the free allowance is billed); and switch the console language to whatever you're comfortable with.  ## Send the skill to your AI and let it walk you through The complete "AI registration wizard" skill behind this tutorial is hosted openly. Just send this URL to whatever AI Agent you have at hand (Muse, Manus, Grok's Bot, anything that can read web pages): **https://szb123.com/files/oracle-cloud-signup/SKILL.md** No need to craft a prompt — send this sentence: > Based on this skill: https://szb123.com/files/oracle-cloud-signup/SKILL.md, help me register an Oracle Cloud server (free tier). The value of AI-assisted registration is direct: the whole flow is broken into one step at a time, each step with a screenshot to compare against and a clear completion criterion. The most common failure points — the 30-minute email link expiry, the unchangeable home region, card rejection — are all flagged in advance by the wizard and troubleshot the moment you get stuck. Compared with fumbling through outdated tutorials on your own, it's far more efficient, and far fewer registrations die from avoidable mistakes. That's why I turned the entire registration flow into a wizard skill: let the AI lead, and turn your first registration from "rolling the dice" into "following a checklist". It works exactly as the skill designs it: one step at a time, each step paired with a screenshot, moving on only after you reply with the result, and checking the troubleshooting manual before answering when errors appear. The division of labor matches this article — the AI guides and troubleshoots; the card number, password, and verification codes are always typed in by your own hands. To use it offline or plug it into your own agent's skill directory, grab the complete package: [oracle-cloud-signup-skill.zip](/files/oracle-cloud-signup-skill.zip) (all step-by-step scripts, the troubleshooting manual, and screenshots). ## Quick reference for common sticking points - **Verification email never arrives**: check spam and the "Promotions" tab (especially Gmail users), wait 2–3 minutes, then resend from the sign-up page; corporate and self-hosted domain mailboxes may reject Oracle wholesale — re-register with Gmail. - **Card rejected**: troubleshoot by likelihood — unsupported card type (virtual/prepaid) → insufficient balance or international online payments not enabled → billing address mismatch with bank records → issuing bank blocking → network risk control. Don't retry repeatedly after failures — it deepens risk control; try again the next day. - **Instance creation reports out of host capacity**: per the official FAQ, the home region temporarily has no free capacity. Drop to 2 OCPU / 12 GB or lower and retry at different hours; the home region cannot be changed. - **Account disabled**: usually 30 consecutive days idle (official FAQ: accounts idle over 30 days may be deemed abandoned and enter suspension or termination), or untruthful details, or an account shared by several people. Appeal following the email instructions; if it can't be saved, the only path is a fresh registration with entirely new details. ## Five things to do after registration 1. **Write down three things**: login email, password, and the Cloud account name (tenant name). 2. **Don't delete Oracle Mobile Authenticator** from your phone — every login needs it. 3. **Don't upgrade the plan.** That's the precondition for "permanently free"; the official docs say it bluntly: without an active upgrade, the credit card is never charged. 4. **Configure A1 within 2 OCPU / 12 GB**; if capacity won't come, lower the config and try different hours. 5. **Log in once a week.** Thirty idle days in a row may get the account reclaimed — don't let a hard-won registration go to waste. ## Finally, the risks, plainly Every rule of this free tier is written down officially: one account per person, truthful details, a real card for verification, idle reclaim. The "multiple accounts", "virtual cards pass verification", and "shared card binding services" circulating online don't just violate the terms and get accounts banned — the card-binding services in particular are a hotbed of black-market fraud: hand over your card number and CVV, and the loss comes out of your own pocket. This article covers only the official flow from start to finish: fill in your real details, use your own card, don't upgrade and you won't be charged. It's free — follow the rules, and it stays free.AI AgentOracle CloudFree ServersHands-on Tutorialhttps://szb123.com/en/articles/muse-apple-id-guide/https://szb123.com/en/articles/muse-apple-id-guide/A hands-on record of registering a US Apple ID with an AI Agent: the exact prompt, how to age the account through the 48-hour risk-control window.Tue, 06 Oct 2026 00:00:00 GMT## Why You Might Need a Foreign-Region Apple ID In the Chinese App Store, quite a few overseas AI apps are impossible to search for or download — to use them, you need a US (or other country/region) Apple ID. On top of that, App Store subscription prices differ from region to region: some overseas AI subscriptions are cheaper in foreign stores. For example, buying ChatGPT Plus on the App Store with a Turkey-region Apple account works out to a much better monthly price than going through mainland-China channels. So whether you want to download an AI app that is only listed in the US store, or subscribe to AI services at a lower cost, a foreign-region Apple ID is the unavoidable first step. This tutorial records my complete hands-on process of using Muse as an agent to register a US Apple ID — the entire flow never asks you to manually fill in a single registration form. ## Before You Start: Get Your Details Ready An AI Agent can run the flow for you, but the personal details have to come from you. Have these items ready at hand before registering: - **Email**: an email address that can receive verification messages (the key to a successful registration) - **Name in pinyin**: your passport spelling or your usual romanization is fine - **Age and phone number**: for account information and SMS verification - **Password**: set it yourself, keep it to yourself - **Payment method**: choose None — no card needs to be attached at the sign-up stage Security reminder: submit these details only to an AI Agent session that you yourself are using. Anyone asking you to send your password to a “registration service” is dangerous — in this tutorial the entire registration happens inside your own AI session, and the credentials never leave your device. ## Hands-On: One Prompt Completes the Registration Open Muse and send it the registration task together with your details in one go. A sample template (I redacted the sensitive fields — fill in your own information): ```text Help me register a US-region Apple ID account. My details: Email: your email Name in pinyin: your name in pinyin Age: your age Phone: +86 your phone number Password: a password you set yourself Payment method: choose None ``` After you send the prompt, Muse starts executing the registration flow step by step. **The first time it runs, it will request permission to access the network — choose “Always Allow”** — that way the whole registration never needs repeated confirmations from you, and the Agent can run to the end in one go. ## What a Successful Registration Looks Like When the run finishes, Muse hands you a complete account receipt: the Apple ID email, name, region (United States), verification status (both email and SMS passed), and payment method (none attached, and no marketing subscriptions checked). Below is the actual receipt from my run (sensitive information redacted):  Once you have the receipt, log in with the new account in the App Store on your iPhone or iPad and you can download free US apps right away. Later, when you want to buy paid apps, handle it with US-region gift cards or by attaching a US payment method — just tell your AI Agent when the time comes. ## Three Key Precautions **First, choose Always Allow for network permission.** After you enter the prompt, Muse requests network access. Choose Always Allow, and the rest of the flow needs no manual clicks from you — the registration won't be interrupted. **Second, and most critical: let the new ID age for 48 hours.** After registering a US ID or a Turkey ID, do not immediately order paid subscriptions — first download a few free apps, use them normally for about 48 hours, and only then pay for and subscribe to paid apps. Ordering a paid subscription immediately after registration easily trips Apple's risk control, and getting a restricted account sorted out again is a huge hassle. Slower is steadier. **Third, Muse is not the only one that can do this.** Other mainstream AI Agents support the same flow, for example Grok's Bot, ChatGPT's Dot, Meta's Muse, Manus's Cue, Tencent's LightVela, and Google's Spark — the flow is identical and the prompt transfers directly. ## A Word from the Site Owner AI Agents will be a hot topic in Q4 2026 and an important direction in how AI iterates and upgrades. I come from a science background and worked as a programmer — no deep theory here. In my spare time I watch stand-up comedy and tell jokes. On this site I share hands-on AI Agent experience, and everyone is welcome to swap tips on using AI to earn a little money on the internet — every flow shared here was run through by my own hands; just follow along. > Note: this article is the site owner's first-hand practice record; all personal details were redacted when compiling it. Apple's registration flow and risk-control policies may change over time — when you operate, defer to Apple's official pages and to your AI Agent's actual feedback. This tutorial has nothing to do with crypto assets and is not investment advice.AI AgentApple IDMuseHands-on Tutorialhttps://szb123.com/en/articles/muse-model-safety/https://szb123.com/en/articles/muse-model-safety/Muse's timidity isn't a capability gap: how system prompts like AGENTS.md constrain models, what jailbreak and prompt injection mean, and why to steer clear.Tue, 06 Oct 2026 00:00:00 GMT## The Loudest Complaint in the Community: Muse Is Too Timid Judging by recent community feedback, the most common gripe about Muse isn't that it's dumb — it's that it's “timid.” Ask it to do a check-in or claim some points for you, and it will often flat-out refuse, or ask you to confirm again and again until you run out of patience. Friends who compare it with other models find it even more infuriating — hand the same task to another Agent and it takes the job without fuss, while Muse drags its feet. Conclusion up front: this is not Muse lacking ability. Every large model leaves the factory with a “code of conduct” attached, and Muse's copy is written exceptionally strictly. ## Not a Capability Problem — It Was Boxed In at the Factory Here's an analogy: RAM sticks also come in different grades of silicon. A good kit overclocks to 5000 or 6000 and runs rock solid; a mediocre one crashes the moment you push it. You wouldn't call the mediocre stick “bad RAM” — it was simply designed to work within that headroom. A large model's safety mechanisms work the same way, except this isn't a hardware quirk — it's a set of **rules deliberately written in**. The carrier of those rules is what you may have heard of as AGENTS.md or the System Prompt: before the model answers any question of yours, it reads this manual first — what it may do, what it may not do, which kinds of requests it must refuse, and which operations require confirmation before executing. Muse's manual is clearly more conservative than everyone else's, which is why, for requests like check-ins that “simulate a human operating on a platform,” it would rather not do them at all. The strength and the weakness of this manual are the same thing: it blocks abuse, and it also blocks some harmless automation. ## Jailbreaking, Prompt Injection, Taming: Stop Mixing Up These Three Terms When the AI crowd talks about making a model “fully obedient,” they are actually blending three different concepts: - **Jailbreaking**: the user deliberately crafts prompts to lure the model into ignoring its code of conduct and doing things it was forbidden to do. - **Prompt injection**: qualitatively nastier — malicious instructions are hidden inside external content the model will read (web pages, documents, emails) so that it executes them without knowing. OWASP ranks it **#1** among the top ten risks in LLM applications. - **Taming**: a colloquial saying, generally meaning gradually loosening the model's boundaries over multiple rounds of dialogue — a gray zone between legitimate steering and jailbreaking. Vendors and security researchers are remarkably aligned on this: it is an ongoing cat-and-mouse contest. Every model update patches the known jailbreak tricks, which is why the “universal prompts” circulating online usually stop working after a few months — and also the reason jailbreak-collection repositories have to keep updating their files. ## Why Ordinary Users Shouldn't Touch Any of This First, **the one who pays is your account**. Jailbreaking violates the terms of service of every mainstream AI provider, and their detection of such behavior keeps maturing. At the mild end you get throttled or “dumbed down”; at the serious end your account is banned — your top-ups, your accumulated conversations, and your configuration all live inside that account. Second, **“fully obedient” is precisely the most dangerous state**. The whole value of an AI Agent is that it can perform real operations on your behalf (registrations, orders, messages). An Agent with all limits removed executes with your account's privileges, while its output is no longer bound by any safety rules — and the content those safety mechanisms intercept already includes plenty of genuinely harmful things. Third, **the ceiling for legitimate use is already high**. In my previous tutorial, Muse, playing entirely by the book, registered a US-region Apple ID for me — understand a model's capability boundaries and design the task into something it is willing to do and can do well. That is the right posture for hands-on AI Agent work. ## A Word from the Site Owner AI Agents are a hot topic in Q4 2026 and an important direction in how AI iterates and upgrades. My view has always been simple: the people who are good at this study the mechanisms — not how to circumvent them. Get a clear feel for the model's temperament, break your tasks into jobs it will accept, and you are already ahead of the 90% who only know how to chat. I come from a science background and worked as a programmer — no deep theory here. In my spare time I watch stand-up comedy and tell jokes, and on this site I keep sharing hands-on AI Agent experience. > Note: this article is a safety-mechanism explainer based on public sources and community observation. It contains no reproducible jailbreak prompts. Each model's safety policies keep changing — refer to the official documentation.AI AgentMuseAI SafetyPromptshttps://szb123.com/en/articles/read-token-data-guide/https://szb123.com/en/articles/read-token-data-guide/Why market cap beats unit price, FDV and unlock sell pressure, circulating supply methodology, and tokenomics: four core concepts for reading token data.Mon, 05 Oct 2026 00:00:00 GMTOne of the questions beginners ask most often: "This token is only $3 and that one is $2,000, so the cheap one will rise faster, right?" The answer: unit price by itself means absolutely nothing. All it takes to understand why is one formula. ## 1. The Formula and the Intuition **Market cap = current price × circulating supply.** Example: token A trades at $0.01 with a circulating supply of 100 billion, for a market cap of $1 billion; token B trades at $50 with a circulating supply of 10 million, for a market cap of only $500 million. Which one is the large cap? A, even though its unit price is just one five-thousandth of B's. Once you separate "price" from "size," you will no longer be led astray by pitches like "this coin costs only a few cents, so getting to $1 means a 3x." Getting to $1 means the market cap has to triple, which takes real, incremental money flowing in. It has nothing to do with how high or low the unit price is. ## 2. Market Cap Tiers: Budgeting Psychologically for Volatility - **Large cap (tens of billions of dollars):** ETH, SOL, BNB, and the like. Deep liquidity on every major platform worldwide, relatively the least volatile, though the absolute swings are still sizable. - **Mid cap (billions to tens of billions):** sector leaders such as LINK, UNI, and AAVE. Real businesses and real depth, but single-day moves on the order of 10% are common. - **Micro cap (under a billion):** the vast majority of altcoins. Thin liquidity, easy to manipulate, and a genuine risk of going to zero. This is not an investment grading but **expectation management**: for a micro cap, doubling or halving in a day is normal. Your position sizing and your emotions should be calibrated to that volatility in advance. ## 3. Three Small Traps in Market Cap 1. **Inconsistent circulating supply definitions:** platforms may define "circulating" differently (whether staked tokens or unvested team tokens are included), so the same project can show different market caps on different platforms. 2. **Market cap is not realizable value:** for a thin-liquidity micro cap, the market cap on paper can be far from the money you could actually get out. 3. **Market cap excludes future supply:** reading market cap without FDV understates the sell pressure from unlocks. That is the next lesson. ## 4. Hands-On Practice Ten minutes of practice beats reading ten concept articles. ## Why It Matters More Than Unit Price An example of how unit price misleads: a token priced at $0.01 may have a market cap of $1 billion (circulating supply of 100 billion), while a token priced at $100 may have a market cap of only $10 million (circulating supply of 100,000). The absolute unit price carries no value information at all; market cap is what says "how much the whole network is being priced at." This is also one of the most common beginner misconceptions, that "cheap altcoins rise faster." Upside and downside have nothing to do with unit price; they have to do with the market cap base, the supply structure, and the strength of the narrative. ## How the Tiers Are Drawn and What They Mean Market cap tiers (large cap / mid cap / small cap / micro cap) are an editorial convention: the tiers roughly track a gradient of liquidity, volatility, and institutional attention. The typical risks of micro-cap tokens: shallow pools (a large order in or out crashes the price), manipulation (low-cost pump and dump), and delisting (the trading pair gets taken down). ## Market Cap's "Denominator Trap" When you compare the market caps of two projects, the biggest trap is the **circulating supply definition**: project A has 80% circulating (FDV close to market cap), project B has 20% circulating (FDV is 5x market cap). At the same $500 million market cap, the two differ by 25x in "fully diluted size." That is why, in a mature research workflow, market cap never appears on its own; it always appears together with FDV and the circulating percentage (see [FDV](/en/articles/read-token-data-guide/) on this site). The second trap is **cross-chain accounting**: a token deployed on multiple chains (bridged copies) may be counted into the circulating supply more than once. On-chain verification is the arbiter. ## Three Advanced Questions About Reading Market Cap Advanced question one: **Can market cap be "manufactured"?** A new token with a low float and a high unit price can push the market cap reading up with very little money. Market cap is the arithmetic of price × circulating supply, not proof of "real demand." Advanced question two: **Is cross-chain market cap double-counted?** Under some definitions, bridged copies of a token get counted into the circulating supply more than once. On-chain verification is the arbiter. Advanced question three: **How does market cap relate to "network value"?** For a functional protocol, market cap only means something when compared against the business it carries (TVL, fees). Market cap on its own supports no conclusion. **Q: Is there any basis for the claim that small caps "rise faster"?** A: There is a structural basis (price elasticity on a low base with thin liquidity), but that has nothing to do with being "worth buying": the same elasticity works downward too. Elasticity is a two-way amplifier, and this site offers no advice in either direction. If market cap tells you "how big the pie is right now," FDV tells you "how big the pie will stretch once all the tokens are out." This lesson is the core of reading an altcoin's supply structure. ## 1. Definition: Counting What Has Not Come Out Yet **FDV (Fully Diluted Valuation) = current price × total supply**, including every token already circulating, still locked, or not yet minted. Example: project X trades at $1 with 100 million tokens circulating out of a total of 1 billion. Market cap: $100 million; FDV: $1 billion. These numbers tell you that another 900 million tokens are "coming out sooner or later." ## 2. The FDV/Market Cap Ratio: An Early-Warning Line for Sell Pressure Divide FDV by market cap and you get an intuitive ratio: - **Close to 1:** the overwhelming majority of tokens are already circulating (old assets like ETH); future new supply comes mainly from issuance, a simple structure. - **2-3x:** a considerable share is still waiting to unlock; you need to read the unlock schedule carefully. - **5-10x or more:** the vast majority of tokens are not circulating yet. Every large unlock is a supply shock and demands an extremely cautious assessment. Note that this is a **description of risk structure, not a value judgment**: a high ratio does not mean a project cannot exist; it means demand growth must outrun the release of supply, which has rarely happened when you benchmark against history. ## 3. The Complete Read, Combined with Market Cap My habitual three steps: (1) look at market cap first to place the project in a size tier; (2) then look at the FDV/market cap ratio to grade its supply risk; (3) finally use an unlock calendar (tools like tokenomist.ai) to confirm when the next large unlock is and how big it is. After those three steps, the picture of "who is selling over the next two years" is basically clear. ## 4. Traps Within FDV Itself - **The max supply can be changed by governance:** FDV's denominator can move; a hard cap is not forever. - **Burns and issuance coexist:** net supply has to be computed dynamically. - **FDV is not a real valuation:** it is a hypothetical "if everything were priced at today's price" number, and for small, thin-liquidity tokens FDV is especially inflated. ## How FDV Is Calculated and What It Means FDV (Fully Diluted Valuation) = current price × max supply (max_supply; for uncapped tokens, the "total that will ever exist" under the currently accepted tokenomics convention). The question it answers is: **if every token were circulating, how much would this network be priced at?** The gap between FDV and market cap (price × circulating supply) is exactly the part not yet circulating: locked team allocations, investor allocations, community reserves. ## The FDV/Market Cap Ratio: Watching Unlock Sell Pressure The higher the ratio, the larger the relative size of future new circulating supply: a token whose FDV is 10x its market cap means 90% of the supply has not unlocked yet, and every unlock (a cliff expiring, a linear release) is potential sell pressure. The general reminder about token unlocks in educational material like ethereum.org's applies here: the unlock schedule is the first part of tokenomics to look at (see [token unlocks](/en/articles/read-token-data-guide/) on this site). Note: FDV is an observational indicator, not a forecasting tool. A high ratio does not necessarily mean a fall; a low ratio does not necessarily mean safety. ## Methodology Traps When Reading the Number For uncapped tokens (ETH, for example), the max supply field is empty (max_supply is unset), so FDV has to use a "conventional future total" or be treated as not comparable. Aggregator platforms handle FDV for uncapped tokens in different ways (in the CoinGecko API, ETH's max_supply indeed comes back empty). ## Three Common Misreadings of FDV **Misreading one: FDV = future market cap.** FDV is only the arithmetic of "if everything circulated at today's price." Future prices will change, and unlocks will dynamically affect the float; FDV is not a prediction. **Misreading two: a high FDV/market cap ratio = trash.** A high ratio does signal unlock sell pressure, but a mature project's large community reserve (an ecosystem fund, for example) does not necessarily turn into immediate sell pressure. Read the ratio together with the unlock schedule (see [token unlocks](/en/articles/read-token-data-guide/) on this site). **Misreading three: FDV can be compared across categories.** Projects with different tokenomics (with or without max_supply, different inflation models) compute FDV on different bases. Check the basis before comparing (ETH's empty max supply field in the CoinGecko API is one example). ## Reading FDV Together with the Unlock Schedule FDV tells you "how big the total pie is," and the unlock schedule tells you "how the pie gets bigger." Only together do they give the complete sell-pressure picture. In practice: read the FDV/market cap ratio first to pin down the "dilution multiple," then go to the unlock schedule to find the "time distribution of the dilution" (cliff-heavy periods versus steady-release periods). This site is not investment advice; the value of this way of reading is that it turns "unlock panic" from an emotion into a calendar. Circulating supply is the multiplier in the market cap formula, and it is also the most inconsistently defined of the three supply metrics. This lesson teaches you to read it accurately. ## 1. It Sits in the Middle of the Three Numbers Total supply > circulating supply > burned. Circulating supply is the part of the total "already on the market." The relationships among the three settle two things: total supply minus circulating supply = supply that exists but is locked; max supply minus total supply = room for future issuance. ## 2. Why the Platforms Disagree Three common points of divergence: whether **staked tokens** count as circulating (technically redeemable, but not sellable in the short term); whether **foundation/treasury holdings** count (already in existence, but controlled by an entity); how **cross-chain versions** are counted (a bridged version on another chain may be counted twice). Any one of these can produce a definitional gap of several percent or more. ## 3. Why Definitional Gaps Are Dangerous Circulating supply enters the market cap calculation directly. **The smaller the reported circulating supply, the smaller the market cap looks, and the more attractive the "so much room left to rise" pitch sounds.** This is a classic data-grooming move by some project teams. In the other direction, a sudden upward revision of circulating supply (a methodology correction) can inflate market cap in an instant and strip historical charts of comparability. My checking method: pick two mainstream data platforms and cross-reference them. A difference within 1-2% counts as normal noise; a systematic gap beyond 5%, and I go to the project's official documentation for its own supply statement. If it does not reconcile, put it on the risk list. ## 4. Free Float and What Can Actually Be Sold There is one more hidden concept: **what can actually be sold**. The circulating supply may include tokens still inside a staking lock period, market makers' inventories, and long-term holders' positions. They circulate on paper but will not actually reach the market in the short term. That is why "100% circulating" does not equal "no sell pressure": real sell pressure is about the unlock schedule and holder behavior, not this static number. ## Methodology Differences in Circulating Supply "Circulating supply" is not as objective as it sounds: the same project can show a different circulating supply on different data platforms. The differences come from the judgment of "which tokens count as circulating" (do locked tokens count, do staked tokens count, unvested team tokens obviously do not). The CoinGecko API's field design (the three-way split of circulating_supply / total_supply / max_supply) is exactly a formalization of this scheme: circulating, total, and max are three independent numbers. Whenever you read supply data on any platform, read its methodology note first. ## The Relationship with Market Cap Market cap = price × circulating supply, so definitional differences in circulating supply pass straight through into market cap differences. This is also the main reason "market caps don't match across platforms." ## Common Forms of Manipulation Circulating supply can be "managed": a claimed circulating supply higher than what can actually be traded (locked tokens counted as circulating), a team disguising a low float by holding across many addresses, or manufacturing the appearance of slowing supply growth right before an unlock. The verification path leads back on-chain: the distribution of balances in the contract and the holding records of lock-up contracts. On-chain data is the final arbiter of circulating supply disputes. ## How the Three Supply Figures Move Together Circulating / total / max form a "supply pipeline": max is the theoretical ceiling (set in the contract), total is what has been minted, circulating is what has been unlocked and tradable. Cross-checks to run while reading: **total far below max** means large amounts remain unminted (room for issuance); **circulating close to total** means unlocking is nearly complete, and future sell pressure depends mainly on max; **circulating > total** (an anomaly) means a definitional conflict, and the data's credibility is in question. ## Reading Circulating Supply Together with "Dilution Speed" The absolute value of circulating supply is less informative than its "speed of change": for a project whose circulating supply grows slowly, the sell pressure from unlocks and issuance is gradual; a sudden jump in circulating supply (a large cliff expiring) is a concentrated event. Laying the month-over-month rate of change in circulating supply against the unlock calendar is a standard move in supply-side research (see [token unlocks](/en/articles/read-token-data-guide/) on this site). Unlock data is where the gap between beginners and veterans is widest: everyone can read a price chart, but "who will be selling over the next two years" hides in the unlock schedule. ## 1. The Two Rhythms of Unlocking **Cliff**: a stage of complete lock-up, during which an investor cannot move a single token. **Linear release**: after the cliff ends, tokens unlock in monthly or quarterly batches. A common structure is "1-year cliff + 3-year linear," which means zero supply in year one, then a fixed share entering circulation every month for the following 36 months. The two risk shapes differ accordingly: an expiring cliff is a one-time shock; linear release is a steady, continuous drip of sell pressure. When you read a schedule, distinguish which of the two you are facing. ## 2. Reading an Unlock Schedule in Three Steps 1. **Size it up**: what percentage of the current circulating supply is the next large unlock? Anything above 5% is an event that clearly warrants caution. 2. **Check who**: whose tokens are unlocking? Investors usually have a stronger urge to cash out than foundations or market makers, which need their long-term reputations. 3. **Gauge absorption**: compare the unlock size against average daily trading volume. If one month's unlock needs 30 days of trading volume to be absorbed, the pressure structure is very plain. ## 3. How the Market Digests Unlocks Worth remembering: **unlock information is public.** That means expectations are often priced in ahead of time. Looking back after the fact, there are cases of both crashes and rallies on unlock days, and trading mechanically around unlock dates is unreliable. Its real value is helping you build expectations for a project's supply structure over the next two years, especially for projects with a very high FDV/market cap ratio (recap: the gap between FDV and market cap is exactly the portion not yet unlocked). ## How to Read an Unlock Schedule The two basic shapes of an unlock schedule: a **cliff** releases nothing at all during the lock period and everything at once on expiry; **linear** releases at a steady daily or monthly pace. Most projects are a mix of the two (cliff, then linear). Three actions when reading the table: how much is locked in total, whose portion unlocks first (the team/investors/community order), and the release rhythm (one large lump versus steady drips). zkSync's rules page offers an official point of comparison: unclaimed airdrop tokens are clawed back and redistributed. A clawback mechanism is also part of "circulating supply management." ## Unlocks and Price Unlock = potential sell pressure, and "potential" is the key word: whether the unlocked tokens get sold, and how many, depends on the holders' decisions. This site does not forecast price impact. The observable, objective facts are: the unlock calendar is public information (major cliff events are visible to everyone), and how fully the market digests it is a research question. There is only one discipline-minded piece of advice I can give: **read a token's unlock schedule before you hold it.** You cannot control the unlock, but you can choose whether to hold through an unlock-heavy period. ## Where Unlock Data Comes From Unlock schedules come from project official documentation and on-chain lock-up contracts (both checkable). The schedule data on aggregator platforms is second-hand compilation; check the original sources. ## The "Source Hierarchy" of an Unlock Schedule Information about unlock schedules comes in three layers: the **contract layer** (the lock-up contract's release conditions, the most verifiable), the **documentation layer** (the project's tokenomics chapter), and the **aggregation layer** (third-party unlock calendars' compilations). Reliability decreases in that order. The verification method: see "X tens of millions unlocking in month X" at the aggregation layer, go back to the documentation layer for the matching clause, and if necessary verify the lock-up parameters at the contract layer. Skipping between the three layers is the main way unlock information gets distorted. ## Unlocks Combined with "Clawback Mechanisms" Some projects have clawback mechanisms in addition to unlocks (zkSync's official rules: unclaimed airdrops are clawed back and redistributed, and the minimum claim amount was raised as a result). A clawback is a "negative unlock" that offsets part of the new supply. When reading an unlock schedule, dig out the clawback clauses too: net supply change = unlocks − clawbacks − burns. All three directions need watching. Tokenomics is a word worn out by overuse. It is not that "the token empowers the ecosystem" paragraph in the marketing material; it is a set of four facts you can check item by item. ## Element One: Total Supply and Issuance Is there a max supply? Is there ongoing issuance? Where does the issuance go? Three archetypes: the hard-cap model (BTC's 21 million), steady-state low inflation (fee burns offsetting issuance, as in PoS networks), and uncapped perpetual issuance (some meme tokens). None is better or worse, but you should know which one you are evaluating. ## Element Two: Allocation Ratios Regroup the allocation pie by "who can sell right now": community (already circulating), team (vesting), investors (vesting), foundation/ecosystem treasury (decided by governance). **In a model where team plus investors add up to more than 40-50%, retail holders are naturally on the other side of the table.** That judgment is not a moral evaluation; it is a description in arithmetic. ## Element Three: Release Schedule Allocation settles "who has it"; release settles "when they can sell." Key things to verify: how long the cliff is, how long the linear period is, and whether there is an unlock calendar tool to check. This part connects directly to the FDV lesson: FDV/market cap ratio × release schedule = the supply curve for the next two years. ## Element Four: Token Utility Read the whitepaper's utility statements one by one and label each with its transmission strength: **mandatory** (you cannot use the network without paying the token, e.g. gas) transmits most strongly; **incentive** (stake to earn issuance) comes next; **ornamental** (pure voting with single-digit participation) is weakest. If every entry in a model's utility column is ornamental, its demand side can essentially be counted as zero. ## Good Models and Bad Models Side by Side - **Relatively healthy structure**: a large community share that is mostly already circulating, a low team share locked up long-term, mandatory transmission among the utilities, and issuance offset by fee burns. - **Dangerous structure**: team plus investors over half, a concentrated unlock after 1 year, a utility column full of "empowering the ecosystem" rhetoric, and unhedged issuance. The same one-line summary: **good tokenomics guarantees nothing, but bad tokenomics almost inevitably hurts holders.** It is an elimination tool. ## The Four-Element Framework When reading any tokenomics, all four elements are indispensable: **total supply** (max_supply or the inflation model), **allocation** (how much each of team/investors/community/ecosystem holds; the zkSync case: within the 17.5% community share, users got 89% and contributors 11%), **release** (the unlock schedule, cliff and linear), and **utility** (governance/fees/staking/payments). All four elements live in the official documentation (zkSync's rules page and Uniswap's announcement are exemplars). Whatever the documentation does not spell out, treat as "unknown risk." ## The Visible Difference Between "Good Models and Bad Models" **Signs of a bad model**: an extremely high team-plus-investor share, unlocks concentrated early, no vesting terms, a vague community percentage. **Signs of a good model**: a clearly stated community share with a checkable unlock schedule, contributor lock-ups with linear release, clawback mechanisms (zkSync's clawback and redistribution of unclaimed tokens). The difference is not a question of morality; it is a structural question of **future sell pressure and incentive alignment**. This site passes judgment on no specific project; it only provides a way to read them. ## The Order for Reading Tokenomics Step one, read the **allocation table** (how the total is divided). Step two, read the **release table** (how much unlocks when; see [token unlocks](/en/articles/read-token-data-guide/) on this site). Step three, read the **utility mechanics** (what the token does in the protocol, and where the demand comes from). Step four, set it against **market cap and FDV** (see [FDV](/en/articles/read-token-data-guide/) on this site). Connect the conclusions of the four steps and the token's "supply story" is complete. ## Practicing the "Four-Element Read" on Real Cases Take two already-verified rules pages for a comparative exercise. **Uniswap** (allocation view): community 15% (user airdrop 10.06% + LPs 4.92% + SOCKS 0.022%) plus the team/investor portion; the total is uncapped but the initial allocation is fixed (CoinGecko convention: the max supply field is empty). **Arbitrum** (points-and-thresholds view): doubled before Nitro, starting at 3 points, capped at 12 points. There, "release" takes the form not of a schedule but of behavior thresholds. **zkSync** (clawback view): 17.5% community, unclaimed tokens clawed back and redistributed, with float management and incentive clawbacks written into the rules. Read through these three cases and the "four elements" turn from a concept into an operable analytical action. ## Risk Notice > [!WARN] Note: crypto assets are extremely volatile and can result in the total loss of your principal. Airdrop campaigns carry no promise of returns; this site does not forecast prices and does not recommend buying.Market CapFDVCirculating SupplyTokenomicsBeginnerhttps://szb123.com/en/articles/security-tools-list/https://szb123.com/en/articles/security-tools-list/Security tools for revoking approvals, verifying token contracts, and spotting phishing: each tool's purpose, limits, and official entry point, with sources.Sun, 04 Oct 2026 00:00:00 GMTOn-chain security tools solve three different problems: **managing the approvals you have already signed** (approval management), **verifying the contracts and addresses you are about to interact with** (verification), and **identifying the phishing currently aimed at you** (intelligence). This article lists every security tool this site covers with verified sources — for each one, its purpose, its limits, and its official entry point. Tools will not keep you from being scammed, but they can shrink the cost of "one mistake" from your entire portfolio down to something contained. ## Approval Management: Revoke.cash **Purpose**: after connecting your wallet, it lists all of your token approvals across chains (spender, allowance, time), with revocation one by one or in batch; it also provides an exploit checker (it checks whether you approved any known hacked contract) and a Signatures page (it attempts to cancel offline permissions you have already signed). **How it works**: once an ERC-20 approval takes effect it stays in force continuously — the contract "can, at any time, move" the tokens within the allowance you granted (as Revoke.cash's documentation points out). Revoking means approving the same spender back to 0. **Limits**: revocation is an on-chain transaction and costs gas; Permit-style offline signatures cannot be revoked from the approval panel before they hit the chain (the Signatures page's cancellation is usually too late anyway); the tool cannot see the content of the offline messages you have signed. **Official entry point**: revoke.cash (enter via bookmark and check the domain character by character — fake revoke pages are a phishing pattern that really exists). ## Contract and Address Verification: Block Explorers (Etherscan and each chain's equivalent) **Purpose**: check transaction status, whether a contract is open source and matches its source code, holder distribution, liquidity locks, and a token's approval records. Etherscan's Token Approvals page draws on the same data as revoke.cash. **Limits**: open source does not mean safe (malicious logic can be written out in the open); holder data can be diluted by spreading tokens across many addresses; each EVM chain needs its own explorer (BscScan, Optimistic Etherscan, and so on). **Official entry point**: etherscan.io and each chain's official explorer — enter via bookmark; the "Etherscan" result in a search engine may be a fake site. ## Token Safety Pre-Check: GoPlus Security **Purpose**: enter a token's contract address and quickly screen for honeypot traits, buy/sell tax rates, blacklists, mintability, and other risk items — a fast health check before trading. **Limits**: detection is based on known patterns — new types of honeypots and adversarial techniques can slip through; the results do not constitute an audit; coverage of brand-new unlisted contracts is limited. **Official entry point**: gopluslabs.io — treat the results as a reference signal, layered on top of contract verification. ## Phishing Intelligence: Scam Sniffer **Purpose**: the browser extension provides real-time alerts for phishing domains and malicious addresses; the official site and annual reports publish phishing loss statistics and technique analysis (about $494 million in 2024; in the 30 large cases above $1 million, Permit-type signatures accounted for about 56.7% of losses). **Limits**: field testing of EIP-712 numeric-address attacks shows that the alerts have blind spots (research Scam Sniffer itself published) — alerts only improve your odds, so reviewing the content of a signature before signing cannot be skipped. **Official entry point**: scamsniffer.io (research reports live on the drops.scamsniffer.io subdomain). ## Reporting and Lookups: Chainabuse and PhishTank **Chainabuse** (backed by TRM Labs): a community for filing categorized reports of crypto scams — investment fraud, phishing sites, fake giveaways, impersonation, and more; before transferring, you can check whether an address or domain has already been flagged. Its security support center warns explicitly that most companies promising to recover lost funds are themselves scams. **PhishTank** (operated by Cisco Talos): a community platform for submitting general-purpose phishing URLs and verifying them by vote, with a free open API — suited to reporting pure web phishing, complementary to the crypto-specific platforms. **Limits**: unflagged does not mean safe (a brand-new site has simply never been reported); handling of reports (taking sites down) is delayed, even though the data enters the database immediately. ## Beyond Tools: Two Things Nothing Can Replace 1. **A quarantined wallet** — every tool only improves your odds; quarantine caps the maximum loss when identification fails; 2. **Signing discipline** — read the spender, read the amount, read the function name. In 2024, losses in the large phishing cases concentrated at the signing step; no tool can replace the ten seconds before you sign. ## Risk Notice This article is not investment advice, nor is it a recommendation or endorsement of any product. Tools' interfaces, chain coverage, and detection capability evolve with versions — defer to the latest documentation on each official site; save every official entry point as a bookmark and verify the domain character by character.Token ApprovalPhishinghttps://szb123.com/en/articles/address-poisoning-scam/https://szb123.com/en/articles/address-poisoning-scam/Zero-value transfers and fake tokens plant lookalike addresses in your transaction history — get addresses only from official channels, never from history.Fri, 02 Oct 2026 00:00:00 GMTAddress poisoning is not a hack of your wallet. It 'plants' a nearly identical fake address in your transfer history and waits for the day you copy an address out of that history and step right into the trap. Its raw material is public on-chain data, its cost is close to zero, and its entire bet rests on one everyday habit: when you copy a recipient address, you glance at the first and last few characters. ### What Is Address Poisoning Address poisoning is a scam in which the scammer sends token transfers to addresses that look similar to addresses you have interacted with in the past, aiming to make you accidentally send tokens to the wrong address in a later transfer. It exploits no software vulnerability — your wallet and your private key remain intact. What gets exploited is your trust in your own transaction record. ### The Two Poisoning Techniques The first is the fake token method. The scammer deploys a fake token contract with the same name as a popular stablecoin (such as USDC or USDT), monitors transfers of the real token, and then uses the fake token to 'simulate' a transfer record that appears to come from your address. When you scroll through your wallet history or a block explorer, you may mistake this fake transfer for real history and copy the scammer's address inside it — and what you send afterwards are real tokens. The second is the zero-value transfer method, which is stealthier. The scammer does not need to deploy any fake contract; instead, they use the `transferFrom` function of the real token contract directly to send a **zero-value** transfer from your address to a lookalike address that in fact belongs to the scammer. The reason it works: `transferFrom` only checks that the transfer amount does not exceed the approved allowance, and when the amount is 0, the transfer succeeds even if the allowance is also 0 — no approval from you is needed at any point. Because the real token contract is used, this record shows up in your wallet as 'a transfer of the real token sent from your address,' making it hard to distinguish from normal records. ### Where You Go Wrong The victim's path usually looks like this: the scammer first fabricates credible-looking records that resemble your past transactions. One day you need to repeat a transfer (say, depositing to an exchange), and you casually copy the address you used last time from your wallet history or a block explorer. Because the first and last few characters look the same, you copy the scammer's address. You confirm and send — and the real tokens land in the scammer's pocket. Not a single step in this chain looks 'abnormal': the history records genuinely exist (they are merely contaminated), the address looks correct (same first and last characters), and the transfer process is completely normal (you sign it yourself). By the time you notice the mistake, the transaction is already on-chain, and on-chain transfers are irreversible. ### Why 'Check the Head and Tail' Fails Many people know they should 'check the head and the tail' of an address, but scammers can generate vanity addresses whose first 4 and last 4 characters exactly match your usual address. Generating such addresses takes computing power, yet the cost is entirely acceptable to an attacker. This means the habit of checking only the first and last 4 characters is effectively useless against poisoning attacks — Revoke.cash's dedicated article on address poisoning explicitly recommends checking more characters. ### Where It Sits Among Other Scams Address poisoning differs mechanically from signature phishing: it needs no malicious signature from the victim — the transfer records come from ordinary transfers the victim initiates themselves (per Revoke.cash's address-poisoning article), which is exactly why it deserves its own article. ### How It Relates to 'Transferring to the Wrong Address' On-chain, a transfer caused by address poisoning looks exactly like 'the user transferred to the wrong address by themselves' — both are valid signatures on valid transactions. The difference is that an ordinary mistake is random (the address came from wherever), while poisoning is a guided mistake (the address came from a source that was contaminated, and it was still used casually). The practical meaning of this distinction: **the key to reviewing a wrong-transfer incident is not 'be more careful next time' but 'where the address came from'** — the defense against poisoning is not at the moment of the transfer; it is at the moment you build your address book or offline list. ### Hygiene Habits for Your Wallet History Poisoning attacks the habit of 'copying from history,' so hygiene habits should be built around the history itself: **regular cleanup** — hide spam tokens in your wallet and filter out dust transfers (a UX improvement that shrinks the surface for mistakes); **pin down frequently used addresses** — store high-frequency recipients (exchanges, your own wallets) in an address book and always select from it; **a process for new addresses** — for a new recipient address, the first transfer goes through a small test amount plus confirmation from the recipient. The combined effect of these habits: the action of 'copying from history' disappears from your workflow — and the attack surface disappears with it. ### 'Two-Person Verification' for Large Transfers The review process for large transfers can borrow from institutional practice: **two-person verification** — a second person (a family member or partner) independently checks the address before execution; **segment-by-segment checking** — split the address into 4 segments and compare segment by segment instead of comparing the whole string at once (when comparing whole strings, the brain 'auto-completes' similar ones); **time separation** — leave a few minutes between copying the address and confirming the send, so the illusion of similarity fades. Individual users can simply do multi-segment checking on their own; families or teams managing large sums should make two-person verification a formal rule. ## Common Mistakes - **Treating transaction history as a contact list**: this is the only premise on which poisoning works. Get exchange deposit addresses from the exchange's official website every time, and confirm with the recipient directly when transferring to a friend. - **Checking only the first and last few characters**: scammers can generate addresses matching your first and last 4 characters. Check more characters, or use an ENS name instead of a long address. - **Being complacent about zero-value transfers**: a zero-value or tiny unknown transfer appearing in your history is not a 'coincidence' — it is part of the poisoning itself. No need to panic, but never treat it as an address source. - **Skipping the second confirmation when transferring**: before a large transfer, compare the complete address segment by segment against the one obtained from an official channel, or send a small test amount first. ## Risk Notice On-chain transfers are irreversible. This article is not investment advice. Address poisoning is an operational risk of transferring funds and has nothing to do with market movements — no matter what the market does, the discipline of address sourcing cannot be skipped. If you have been hit, export the transaction hashes immediately and report through channels such as FBI IC3; the chance of recovery depends on law enforcement progress. Do not trust any private message claiming someone 'can help you recover the funds' (that is usually a second scam).TransferPhishinghttps://szb123.com/en/articles/airdrop-approval-aftermath/https://szb123.com/en/articles/airdrop-approval-aftermath/A campaign ending does not end your approvals: the approve/permit signatures you signed stay valid after the campaign closes.Fri, 02 Oct 2026 00:00:00 GMT"Only after signing did I realize something was off" — this article covers what to do after the signature. There is exactly one core idea: **the type of mistake you signed determines the response** — approval types (approve/Permit) can be revoked, transfer types are irreversible, and seed-phrase types must be migrated. ## Sort the Type First, Then Respond **Type one: token approval** (approve/increaseAllowance). The signature only granted an allowance; the tokens have not moved yet — revoking the approval on revoke.cash stops the loss (Revoke.cash documentation: revoking = approving the allowance back to 0). **Type two: Permit signature** (EIP-2612). The offline signature itself creates no on-chain state — it only takes effect once the scammer submits permit() to the token contract with your signature. If it has not taken effect: revoke.cash's Signatures page lets you attempt a cancellation (usually too late); if it has taken effect: handle it as type one (revoke the approval — the documentation states migration is generally unnecessary). **Type three: transfer/swap signature**. Assets have already moved according to the signature — irreversible; move into the evidence-gathering and reporting workflow. **Type four: seed phrase exposure**. Any "I gave away my seed phrase" belongs here — migrate immediately; revoking accomplishes nothing. ## Two "Don'ts" During the Response **Do not keep operating on the original wallet**: if you suspect the device or extension has been tampered with, do every subsequent step on a clean device. **Do not trust "recovery services" that come to you unbidden**: IC3 explicitly does not contact victims proactively; anyone claiming they can recover your funds is running a second scam. ## Rehearse the Response Flow (Walk Through It in Advance) The value of a response flow lies in familiarity — mid-panic is no time to read a tutorial. It is worth running a "zero-risk drill" in calm times: open revoke.cash, find an old approval, and walk through the revocation flow (at a small gas cost); open a block explorer, look up your own address's "signatures/transactions" history once, and practice telling the two kinds of records apart; on a fresh wallet, rehearse "a small test transfer + address verification" once. After three drills, your actions will deform far less when something actually goes wrong. ## How This Connects to the "Scammed Checklist" This article covers the actions "after the signature, before or during the loss"; if the loss is already an accomplished fact (a transfer-type signature, seed phrase exposure), switch immediately to the four-step flow (stop the loss → cut off → gather evidence → report). ## A "Field Quick Reference" for Signature Types The quick-reference card you need mid-panic (copy it into your notes): **approve/increaseAllowance + an amount** → approval type → revoke on revoke.cash → done; **permit + a deadline** → Permit type → check the Signatures page to attempt a cancellation (most likely too late) → then revoke as with the approval type; **transfer/swap + your own assets** → transfer type → irreversible → gather evidence and report; **you entered a seed phrase** → exposure type → migrate immediately; revoking accomplishes nothing. Four types, four actions — this card is the entire article, condensed. ## The Relationship to Insurance / Mutual-Aid Communities Some communities (security firms' Discords, a wallet's official support) can provide **confirmation and guidance** — but mind the boundary: any "help" that "operates for you" or "asks you to transfer funds first" is a second scam (IC3's line: legitimate institutions will never ask for money out of the blue). The right way to seek help: submit your issue through official support channels (without your private key), file an incident report through security firms' channels, and disclose no details outside official channels. ## Risk Notice This article is not investment advice. Judge signature types by what the wallet displays and by on-chain records; this article is not legal advice.AirdropsToken Approvalhttps://szb123.com/en/articles/airdrop-fake-claim-sites/https://szb123.com/en/articles/airdrop-fake-claim-sites/A pixel-perfect claim page can copy everything except the official domain, consistent announcements, and a sane process — five flaws you can actually verify.Fri, 02 Oct 2026 00:00:00 GMTFake claim sites are the standard form of airdrop phishing: a 'claim' page impersonating a project's official site, built to lure you into connecting your wallet and signing malicious transactions. Scam Sniffer's annual report lists them as the core customer-acquisition component of the drainer industry — of the roughly $494 million lost to phishing signatures in 2024, most incidents started with a fake page. ## How the Industry Chain Works Scam Sniffer's research breaks this industry chain down in fine detail: tool families (Angel, Pink, Inferno, and others) offer 'phishing as a service,' and in the first half of 2024 the three of them held roughly 42%, 28%, and 22% of the market respectively; traffic acquisition has dedicated operators — buying ads, riding trending topics, taking over expired Discord links; and cash-out is automated sweeping. For users, this means the attack does not hit at random: **the fake page you see was precisely delivered to you**. The dedicated MS Drainer study shows that the advertising channel alone brought in 63,210 victims in about 9 months. ## Three Technical Traits (per the verified report figures) **Hosting and disguise**: phishing sites are mostly deployed on Cloudflare/Vercel/IPFS, with a Cloudflare shield or a fake CAPTCHA page added to block scanners. **Signature disguise**: victims are induced to sign offline signatures such as Permit or setOwner — the EIP-712 numerical-address bypass research shows attackers can even make the signing interface display a string of unreadable digits to get past security plugins. **Ad cloaking**: ads are targeted by region, so reviewers and ordinary visitors see a normal page while only targeted users see the phishing page. ## Defense Checklist (editorial recommendations) 1. Verify the domain character by character — enter through bookmarks, not search ads; 2. Read the full content before signing: spender, amount, function name (see our **token approval phishing case**); 3. Interact with a quarantined wallet (see our **wallet separation guide**); 4. Already signed: act immediately with revoke.cash (see our **guide to revoking approvals**). ## Reconstructing Two Disclosed Cases **The ad-channel case**: the MS Drainer research documents fake Radiant pages run in Google search ads starting April 2023 (associated losses of about $4 million), followed by a shift to X feeds — the 'Ordinals Bubbles' series of phishing ads, of which 6 of a sampled 9 came from the same source. **The alert-bypass case**: the EIP-712 numerical-address attack jointly disclosed by Scam Sniffer and SlowMist — the contract address in the signature is passed in as a decimal number, the wallet normalizes it into the real address when encoding (so the signature is valid), but the UI shows a string of unreadable digits and the security plugin's alert fails; it was linked to Pink Drainer (which the research report says 'stole tens of millions of dollars over the past year'). Taken together, the two cases show: **every link in the chain, from traffic acquisition to signing, has dedicated engineering behind it**. ## If the Page Looks Too Real to Be Fake Three technical facts make 'looking real' worthless: the appearance can be cloned pixel by pixel (the toolkits are productized); a wallet's transaction-simulation result can be fooled (one of the techniques disclosed in Scam Sniffer's research); and a phishing site hosted on Cloudflare/Vercel shares the same CDN experience as the real one. That leaves only two anchors that do not depend on appearance: **the domain itself** (character by character, not 'similar') and **the signature content itself** (read the spender/amount/function). This principle is repeated in the conclusions of Scam Sniffer's reports: users must stay suspicious of any signing request. ## Common Mistakes - **Trusting the 'page experience' instead of the domain**: fast loading, a padlock icon, or a customer-service popup do not constitute trust; - **Guarding only the first connection**: approval is ongoing — clean at connect time does not mean clean at signing time; - **Treating security plugins as a get-out-of-jail-free card**: the numerical-address research tested multiple wallets and plugins in practice and found blind spots in all of their alerts. ## Practical Details of Domain Verification 'Character-by-character verification' is easy to say and has three practical points: **use bookmarks, not the keyboard** — once you have confirmed the domain from an official announcement, save it as a bookmark and only ever enter through that bookmark; **watch for lookalike characters** — 0/O, 1/l/I, rn/m, hyphens versus underscores: the substituted characters in phishing domains hide in exactly these positions; **archive official announcements for comparison** — screenshot the domain from the official X pinned post or announcement, and when a 'new entry point' appears, compare it against your archive. The domain is the one thing a fake claim page cannot clone perfectly — spend your verification effort where it counts. ## Risk Notice This article is not investment advice. Fake claim page tactics are updated with each reporting cycle; defer to the latest versions from security sources such as Scam Sniffer.AirdropsPhishinghttps://szb123.com/en/articles/approvals-and-signatures-guide/https://szb123.com/en/articles/approvals-and-signatures-guide/A complete guide to approvals and signatures: approve, unlimited approvals, Permit/Permit2, reading airdrop-claim signatures, and what to do after a theft.Fri, 02 Oct 2026 00:00:00 GMTToken approval is a core mechanism of the ERC-20 standard: you allow a contract (the spender) to move tokens out of your address, up to a limit you set. DEX swaps, staking, lending — nearly every DeFi operation is built on top of it. Permit-style offline signatures let an "approval" be signed without spending gas, yet with exactly the same force as an on-chain approval. Understanding approvals and signatures is the first lesson in understanding on-chain asset risk. ## What an Approval Is ### How the Mechanism Works Take a DEX swap as an example: you approve USDC to the DEX's router contract (with the limit set to this trade's amount), then initiate the swap — the contract calls transferFrom to pull the USDC out and push the new token in. Without the approval mechanism, every transfer would need you present to sign; with it, a contract can compose operations together (this is also the foundation of DeFi composability). The cost: **the approval's lifetime outlives the single transaction** — whatever part of the limit went unused stays in force until you revoke it or overwrite it with a new approval. ### A Comparison of the Three Approval Functions There are in fact three commonly used on-chain approval entry points, each behaving differently: **approve(spender, amount)** — the standard approval; it sets a limit and can be revoked at any time with approve(spender, 0); **increaseAllowance/decreaseAllowance** — a non-standard function (not part of the EIP-20 spec; removed from OpenZeppelin in v5), and Scam Sniffer's annual report lists increaseAllowance among phishing signature types; **permit() (EIP-2612)** — replaces the on-chain approve with an offline signature, with identical effect. What the three share: they all "authorize a spender to pull tokens"; they differ in entry point and revocation method. Phishing abuse concentrates in the signature types the annual report lists (Permit and increaseAllowance both appear in its statistics) — when identifying a malicious request, don't look at "which function" but at "who is being approved, and how much." ### The Approval Race Condition ERC-20's approve has a famous race condition: in the gap between approving A and changing the approval to B, A can still pull tokens under the old limit. The EIP-2612 document explicitly notes that the standard EIP-20 approval race condition (SWC-114) applies equally to permit. What this means for users: **when changing an approval, first reduce to 0 and then set the new value, or approve only the exact amount needed** — this compresses the race window to a minimum; the more practical version is the periodic checkup — stale old approvals are exactly what should be revoked anyway. ### The Two Faces of Approvals and DeFi Composability The approval mechanism is the bedrock of DeFi composability: a DEX aggregator can call multiple pools at once and a yield strategy can auto-compound, all because "a contract is authorized to act in your place." The other side of the same coin: **your funds are exposed to the combined risk of every contract you have ever approved** — if any single link fails (a contract bug, a governance takeover, a key compromise), the existing approvals are ready-made channels. Once you grasp this duality, "minimal approvals plus periodic cleanup" stops being a safety tip and becomes part of the basic cost structure of participating in DeFi. ## Unlimited Approvals An unlimited approval upgrades "I agree to this transaction" into "I agree to my entire balance being moved at any time." It is popular because it saves gas and hassle — no re-approval for each interaction. Its risk: once the approval takes effect it stays in effect, and the contract side (or whoever breaks into the contract) can pull your tokens at any moment. ### Three Sources of Risk **A malicious contract**: the contract you approved is itself malicious — the limit is your maximum loss. **A hacked contract**: the April 2023 SushiSwap incident — the router contract failed to validate an external parameter, and the attacker drained assets via users' existing approvals (BlockSec's post-incident analysis: users who approved the RouteProcessor2 contract lost their assets). **Residual approvals**: you no longer use the protocol, but the approval is still hanging there — "signed once and forgotten" is the most common source of exposure. What the three share: the loss happens after the approval, unrelated to what you were doing at that moment. Scam Sniffer's 2024 report puts phishing-signature losses at about $494 million for the year; in the 30 large cases above $1 million, Permit accounted for about 56.7% of losses and setOwner 31.9% — which is why approval risk management is the first lesson of on-chain security. ### A Worked Example of Approval Exposure Exposure = approval limit × remaining validity × counterparty risk. Example: you granted protocol A an unlimited USDC approval — your exposure equals all the USDC in your wallet, until you revoke; three months later protocol A is breached, and your loss equals all the USDC in your wallet at that moment. Compare minimal approval: the same interaction, with the limit set to this trade's amount — three months later protocol A is breached, and your loss is zero (the approval was consumed long before). The actionable takeaway from this example: **exposure is a variable you can actively manage through your choice of limit**, not fate. ### The Real-World Friction of Minimal Approvals To be honest, minimal approvals come with three real frictions: some frontends check the unlimited box by default (you have to change it manually); certain strategies (auto-compounding, limit orders) need a standing approval to work; re-approving costs gas. The response (editorial advice): change the frontend settings wherever they can be changed; for protocols that force unlimited approvals, judge whether the exposure is worth handing over (use a small test wallet); write the trade-off between gas cost and exposure cost into your cost ledger — in most scenarios, the gas for a few small approvals is far below the loss from one unlimited approval detonating. ### The Defense Stack 1. **Minimal approvals**: ethereum.org's security guide states it plainly — approve only the amount the trade needs, and refuse unlimited limits; 2. **Periodic checkups**: use revoke.cash to review your approval list, prioritizing three kinds — unlimited limits, old dates, and projects you don't recognize; 3. **Revocation**: re-approve the same spender with an amount of 0 (the ERC-20 mechanism), or use revoke.cash's one-click revoke; 4. **Architectural backstop**: concentrate approvals in your interaction wallet; the storage wallet carries zero approvals. ### Unlimited Approvals vs. Phishing Approvals: One Ledger The losses from unlimited approvals and from phishing approvals are often conflated, but their "timelines" differ. Phishing approval: the signature you were tricked into signing hands over the exposure outright — the loss follows the phishing immediately. Unlimited approval: a normal approval you signed voluntarily, whose exposure lies dormant until the day the contract goes wrong — the loss arrives months after the signature. This timeline difference shapes the defense design: phishing is fought with "recognition in the moment" (signature review), unlimited approvals with "periodic management" (regular checkups) — a user who only reviews signatures will still trip over an approval from three months ago. Neither mechanism can be dropped. ## Permit and Permit2 The Permit signature is an optional extension of ERC-20 (EIP-2612): it lets users sign an approval message offline, without sending an on-chain transaction. It solves a real experience problem (saving one gas payment) and creates an entirely new attack surface (a free, weakly-labeled phishing signature with the full force of an approval). ### The Standard's Design and Its Attack Surface EIP-2612's design is rigorous: the signature carries a deadline expiry field and an incrementing nonce to prevent replay; anyone may submit the transaction (a relayer model — originally intended to let users pay gas in tokens rather than ETH). But the same properties are a gift to scammers: the signature costs nothing, and there is no barrier to submitting it. Scam Sniffer's 2024 annual report recorded that, in the 30 large cases above $1 million, Permit accounted for about 56.7% of losses — first among signature types. ### Why Wallet Warnings Are Weak The reality Revoke.cash's documentation points out: where Permit is supported, wallets (such as MetaMask) usually do not pop the explicit on-chain approve-style warning — users may think they are merely "logging in to a website." This is tied to how EIP-712 is presented: the interface for structured messages varies from wallet to wallet, and the position of the spender/amount fields is not fixed. This pushes the entire duty of "reading the signature" onto the user's side — and makes "if you can't read it, don't sign" a reasonable default. Add two psychological mechanisms and the scam is complete: **authority** — the phishing page clones the real project, and the user is in a "doing legitimate business" mindset; **low vigilance** — no approval warning pops up and no gas is spent, so the user's defensive baseline drops to "logging in" level. The defense does not lie in recognizing the interface (interfaces can be faked); it lies in a **content obligation**: make "reading the spender and the value" an unskippable step — no matter what the popup looks like or how legitimate the page appears. This is the key shift of moving the line of defense from "spotting the fake interface" to "verifying the real content": the former is a cat-and-mouse game; the latter is a repeatable process. ### The Data: Where Permit Sits in the Phishing Statistics Scam Sniffer's 2024 annual report: in the 30 large cases above $1 million, Permit-type signatures accounted for roughly 56.7% of losses, first among signature types. Permit-style signatures are a **permanent mainstay** of phishing theft — the habit of reading signatures is not a one-time lesson but ongoing practice. ### Permit2 vs. Standard Permit Permit2 is an [approval system](https://developers.uniswap.org/docs/protocols/permit2/overview) introduced by Uniswap that generalizes "offline signature approvals" to all tokens — standard Permit (EIP-2612) requires the token contract itself to implement permit(), whereas Permit2 bypasses that limitation through a universal approval contract. For the user's risk model, the core of the two is identical: **an offline signature = an approval that can be executed later**. When you see the word Permit2, treat it as the same class of risk. ## How to Read Signatures When Claiming Airdrops Signature safety at the airdrop claim stage, in one sentence: **a signature is an approval, and a free signature is too**. EIP-2612's Permit mechanism makes "an offline signature carrying the force of an approval" a standard capability — it saves gas and feels smooth, and it also turns "just signing something" into the most dangerous sentence in crypto. ### Two Kinds of Actions at Claim Time **An on-chain claim transaction**: you initiate the transaction, pay gas, and the tokens arrive — the transaction's contents are readable in your wallet. **An offline signature**: the Permit type — the signature itself is free, but once submitted on-chain its effect is identical to an approve (setting an approval limit and emitting an Approval event). The safety difference between the two lies in warning strength: Revoke.cash's documentation notes that most wallets do not show the same explicit warning for Permit as they do for an on-chain approve, so users may think they are merely logging in. The risk exposure, however, is exactly the same — any tokens within the approval limit can be pulled. ### The Verification Method Before signing, read three fields of the EIP-712 structured message: **spender** (who is being approved — the protocol you are interacting with, or an unknown address); **amount** (how large the limit is — minimization principle, refuse unlimited limits); **function name** (what permit/approve/setApprovalForAll each implies). Add a domain check (enter through official channels), and these four things make up the complete check for a claim signature. In 2024's 30 large cases above $1 million, Permit-type signatures accounted for about 56.7% of losses (Scam Sniffer's figures). ### A Full Signature-Verification Drill Practice "reading signatures" on a testnet at nearly zero cost: find a testnet token that supports Permit, run one approval interaction, and in the EIP-712 message your wallet pops up, compare each field against the EIP-2612 text — owner (your address), spender (the approved party), value (the limit), deadline (the expiry time), nonce. Once you have practiced on a real message, the deviations in a phishing message (the spender is an unknown address, the value is abnormally large, the deadline is absurdly long) become obvious at a glance. Use an isolated wallet for the drill, and there is no real risk at any point. ### Quick Reference: Signature Types in Claim Scenarios The signatures/transactions you will meet during an airdrop claim, ordered by how often they appear: **an ordinary claim transaction** (on-chain mint/transfer, costs gas, contents readable); **a Permit signature** (a gas-free approval with the same force as approve); **a Permit2 signature** (the generalized approval system, same class of risk); **setApprovalForAll** (a full NFT approval — high danger the moment it appears); **a plain message signature** (login/proof of address ownership — it does not itself approve anything, but beware of the combo scam that dresses an approval signature up as a login screen). How to use this reference: when a popup appears, classify it first; each class has its own verification checklist — for plain messages check the domain, for approvals read the fields, for transactions read the contents. ### Three Hard Rules Bound to the Claim Scenario **One: claiming does not need an approval limit** — a legitimate claim transfers tokens directly to you; a "claim" that asks you to approve is either a precondition for some later step (read it carefully before deciding) or phishing. **Two: an offline signature = a future approval** — under EIP-2612, a free signature can just as well become a pass for moving your tokens. **Three: if you can't read it, you don't understand it** — for any EIP-712 field you cannot fully read, rather give up the claim (a genuine airdrop you missed can be reclaimed from the official entry; a malicious approval has no do-over). ## What to Do After a Theft ### First, Classify the Theft The first step in handling a theft is to determine "what exactly was lost." Revoke.cash's "You've Been Scammed, Now What?" lays out three scenarios, each with its own path: - **Multiple assets vanishing across multiple chains, or an incoming native token (such as ETH) being swept away immediately** — your seed phrase or private key has been compromised. There is nothing left to "re-lock"; the correct move is to abandon these addresses: first scan the computer you normally use for malware (reinstall the system if necessary) and change your important passwords; then create a new wallet (prefer a hardware wallet) and move any remaining assets into it. The transfer is a race — sweeper bots watch the compromised address and sweep away any newly arriving assets immediately; when the balance is large, Revoke.cash suggests contacting the Flashbots Whitehat Hotline for white-hat assistance. - **Multiple approved assets pulled away by the same contract** (such as OpenSea, Blur, or Permit2-related contracts) — a marketplace signature scam: the block explorer usually shows no direct transfer, only function calls like MatchOrders or BulkExecute. This is a one-off event; after revoking the relevant approvals, the wallet can continue in use. - **Only one specific asset being moved** — an approval was likely exercised: check the approval list first, and revoke any unfamiliar approval; if there is none, it may have been a direct transfer. ### Already Signed? Two Situations **The signature has not yet been activated on-chain**: you can try to cancel it on the Signatures tab of your revoke.cash account page. But be clear-eyed: scammers submit the signature on-chain as fast as they can, so this step is usually very difficult. Also, because signatures are offline, revoke.cash cannot know what you actually signed — the page shows only "potential signatures" — so act there only when you are quite sure you signed something malicious (needlessly canceling is not dangerous, just a waste of gas). **The signature has been activated on-chain**: the approval is now in force, and from here it is handled exactly like an ordinary approve — revoke it in the approvals panel. For approval- and signature-type scams, Revoke.cash's position is that revoking the relevant approvals is enough and a wallet migration is generally unnecessary — on the precondition that, per the previous section, you have first confirmed the seed phrase and private keys were not compromised. ### Recovery Expectations for Stolen Assets The expectation to establish: **stolen assets are almost never recoverable on-chain**, and anyone claiming they can "help you recover them" is most likely a scammer — "recovery services" are themselves a common entry point for a second scam. Filing a report still has value: you can submit records to local law enforcement and the exchanges involved, preserving a chain of evidence (the source page also mentions that a freeze is theoretically possible, but do not treat it as an expectation). ## Common Mistakes - **Treating "approved a well-known protocol" as a permanent exemption**: protocols get upgraded, get hacked, and get abandoned by you — the SushiSwap case of April 2023 shows that legitimate protocols can be breached too; approval exposure does not fully track protocol reputation; - **Not checking the chain on the approval confirmation screen**: in a multichain wallet you can approve on the wrong chain — the approval is recorded on that chain's ledger; - **Mistaking "the limit is used up" for "the approval has expired"**: the record of a fully-used approval remains — the next approval takes effect at its new limit, and the history is there to remind you that it exists; - **"I revoked and now I have to approve again — what a waste"**: the gas for revoke-plus-re-approve-on-demand is the insurance premium of exposure management — over a year it is far below one exposure incident; - **Managing ERC-20 approvals but not NFTs**: setApprovalForAll's full approval is the same kind of long-term exposure (per Revoke.cash's documentation: pass false to revoke); - **"Anything supporting Permit is a legitimate project"**: legitimate projects use Permit to improve the experience; phishing projects use it too — the mechanism is neutral; the person using it is not; - **Treating the deadline as a safety mechanism**: the deadline is only the signature's validity window — within it the approval can be activated at any time; expiry means "void," not "protection"; - **Guarding only against small signatures**: whenever you read an abnormally large limit, refuse to sign no matter how legitimate the page looks; - **Treating "no gas needed" as a safety signal**: Permit's entire risk is built precisely on being free — gas has nothing to do with risk; - **Reading only the popup title and not the message body**: the EIP-712 message body is the full content of the approval — the title can lie; the fields cannot; - **Relaxing for "well-known projects"**: phishing impersonates precisely the well-known projects — signature verification does not care how famous the project is; - **Signing halfway through because reading is a hassle**: a signature is consent in the legal sense — "if you can't read it, don't sign" is the option that is always valid. ## Risk Disclosure This article is not investment advice and does not point to any specific project. Approvals are an ERC-20 standard mechanism, and revocation operations cost gas; Permit support varies by token (most tokens do not implement it), and wallet presentation evolves with versions — defer to the standard's original text and the current interface of the wallet you use. The share and loss figures for signature phishing change with each year's statistical methodology; defer to the latest version of the source pages.Token ApprovalWallet SecurityPermithttps://szb123.com/en/articles/hot-vs-hardware-wallet/https://szb123.com/en/articles/hot-vs-hardware-wallet/How hot wallets (online) and hardware wallets (offline signing) differ in security model: wherever the private key lives, that's where the risk lives.Fri, 02 Oct 2026 00:00:00 GMTThe difference between a hot wallet (an internet-connected software wallet) and a hardware wallet (a dedicated device that keeps keys offline) comes down to one sentence: **where the private key is generated and stored**. A hot wallet's private key lives on an internet-connected device — convenient, but with a large exposure surface. A hardware wallet's private key stays inside a dedicated chip and never leaves the device — signing is completed inside the device, so even if your computer is compromised, the private key cannot be taken. This article compares the two and the scenarios each one fits. ## Where Hot Wallets Fit The value of hot wallets (MetaMask, Rabby, mobile wallets, and so on) is interaction efficiency: connecting to DApps, signing tasks, small everyday transfers. Their exposure surface: malware on the connected device, compromised browser extensions, clipboard hijacking — the ethereum.org security guide lists LavaMoat-style supply-chain defenses as a direction wallet vendors are working on, which tells you this attack surface is real and keeps evolving. Positioning advice: a hot wallet is your "cash clip" — it holds your daily spending allowance. ## Where Hardware Wallets Fit A hardware wallet isolates both private key generation and signing inside a dedicated device: the transaction is built on your computer, but the signature is completed inside the device — even if the computer is fully compromised, all the attacker obtains is a "signing request," not the private key. In the words of the ethereum.org security guide: private keys kept offline are difficult to steal even if your computer is hacked. Positioning advice: a hardware wallet is your "safe" for long-term assets, and you should buy only through official channels (second-hand hardware wallets are a classic trap). Pair it with interaction discipline: when the hardware wallet asks you to confirm a transaction, verify the details on the device's screen (the device screen is the only display a computer cannot hijack). ## A Selection Matrix (Match the Tool to the Use Case) Match the tool combination to your primary scenario. **Small-amount, high-frequency interactive users** — a hot wallet first, paired with device isolation and regular token approval checkups (the loss cap equals the hot wallet balance). **Large-amount, long-term storage users** — a hardware wallet first, with the hot wallet used only for watching balances (watching requires no private-key signing). **Hybrid users** (most people) — a hot wallet as the cash clip + a hardware wallet as the safe + separation discipline. The core of this matrix is not "which one is better" but "the size of your holdings and your interaction frequency determine the proportions of the mix." ## Additional Notes on Hardware Wallets The ethereum.org security guide mentions the hardware wallet support ecosystem (integrations from multiple vendors). Things to weigh when choosing one: purchase through official channels (firmware tampering on second-hand devices is a real risk), confirm the seed phrase backup process, and understand how the device confirms signatures (verifying what appears on the device screen is the core security action). Discipline while in use: firmware updates come only from official channels; when the device screen and the computer screen disagree, trust the device screen (the computer's display may have been hijacked). ## Thinking Quantitatively About "Going Hardware for Large Amounts" "How much counts as large?" can be answered with a self-questioning framework: **if this hot wallet were fully drained tonight, would it affect your life?** If the answer is yes, that balance is worth a hardware wallet. Another angle: a hot wallet's expected loss equals the probability of compromise times the balance — the larger the balance, the more a hardware wallet's fixed cost pays off. Turning security anxiety into an arithmetic problem is the method this article most wants to convey. ## Risk Disclaimer This article does not constitute investment advice and does not constitute a recommendation of any product. The technical implementations and security boundaries of both wallet types keep evolving; defer to the vendors' official documentation.Hot WalletHardware WalletWallet Securityhttps://szb123.com/en/articles/overseas-crypto-entry-guide/https://szb123.com/en/articles/overseas-crypto-entry-guide/Why banks block crypto transfers, a proven source-of-funds checklist, and a three-step appeal path after a freeze — US, Canada, EU, Australia, Singapore.Fri, 02 Oct 2026 00:00:00 GMTFor many in the global Chinese community, the first reaction is: "I buy and sell on a legitimate platform — on what grounds would a bank block me?" My experience: once you understand the bank's perspective, most blocks can be avoided in advance, and even after a block there is a proper process to follow. This article walks the whole chain, starting from "what the bank is thinking," moving on to supporting documents, and ending with appeals. ## 1. Why Banks Block: The Compliance Perspective The anti-money-laundering (AML) and know-your-customer (KYC) obligations banks are subject to boil down to one sentence: **for every unusual fund flow it handles, the bank must be able to explain it clearly to the regulator**. When you transact with an exchange, the bank's systems flag two kinds of signals: the counterparty is a "crypto-related industry account," and the amounts and frequency do not match your account's historical profile. A flag is not an accusation — it only means manual review is needed. What actually causes a long-term freeze is that, at review time, you **cannot give a consistent explanation**: you cannot say where the funds went, cannot produce statements, or your verbal account does not match the transaction records. Once you understand this, the strategy becomes clear: make every transaction "come with its own explanation." ## 2. Regional Channels and Regulatory Frameworks at a Glance | Region | Common channels | Key points of the regulatory framework | | --- | --- | --- | | United States | ACH and Wire | Trading platforms are subject to federal registration and state-level regulation; tax filing obligations are covered on the IRS's Digital Assets page | | Canada | Interac e-Transfer | Trading platforms must register with FINTRAC; e-Transfer is backed by the Interac system | | European Union | SEPA transfer (euro pricing parity across the EU) | MiCA (Markets in Crypto-Assets) sets unified licensing requirements | | Australia | PayID / OSKO (officially: typically under a minute, 24/7) | Exchanges register with AUSTRAC; banks and exchanges each fulfill their own AML obligations | | Singapore | Local bank transfers | For the regulatory framework, refer to the MAS website (the site was under maintenance when this was written, so no details are stated here) | There is only one principle for choosing a channel: **licensed beats cheap**. A licensed platform's counterparty information is identifiable within the banking system, and in a dispute there is a clear party to appeal to. ## 3. How to Prove Source of Funds: The Three-Piece Set Plus Consistency I recommend every reader keep a "source folder" on hand containing three things: 1. **Proof of income**: an employment contract or recent payslips, annual tax returns (for the self-employed, business income records and tax filings); 2. **Exchange statements**: complete trading and fiat on/off-ramp records exported from the platform (monthly or yearly); 3. **Asset disposal records**: if the principal came from selling property, securities, or the like, keep the settlement statements. The key is not how many documents you have, but that **the amounts and timing of the three can corroborate one another**. For example, if you withdraw $20,000, you can show when the bank asks: $15,000 came in from three months of salary accumulation (matching bank statements), a position appreciated in the meantime and was sold (matching trading records), and the difference is consistent with taxes and fees. With this package complete, your explanation during an inquiry is complete. Conversely, the most common failure mode is: saying verbally that you "made it trading crypto," but producing no statements and being unable to sketch even a rough timeline of buys and sells. ## 4. Account Frozen or Closed: Appeal Essentials If your account has already been restricted, follow this order: **Step one, communicate in writing.** Ask the bank to state the specific grounds for the restriction (which transaction, which kind of risk signal), and make clear that you will supply additional documents. Written correspondence is both good faith and evidence for any later complaint. **Step two, respond point by point.** For each questioned transaction the bank raises, provide the corresponding three-piece set (see the previous section). Do not write an emotional essay; respond as a checklist: transaction date → source of funds → document number. **Step three, platform-side cooperation.** If the bank needs the exchange to confirm your account status, request the needed documents through the platform's official support channels — what each platform can provide differs, and the official Help Center is the authority. **Step four, regulatory complaint.** When a bank drags its feet or closes an account without proper cause, each jurisdiction has a clear channel: in the United States you can complain to the [Consumer Financial Protection Bureau (CFPB)](https://www.consumerfinance.gov/complaint/), in the United Kingdom to the [Financial Ombudsman Service (FOS)](https://www.financial-ombudsman.org.uk/), in Australia to [AFCA](https://www.afca.org.au/). Before complaining, organize the written records of the first two steps — a regulator's involvement almost always requires that you first tried and failed to resolve things with the bank. ## 5. Daily Habits That Keep Explanation Costs to a Minimum - Use **only same-name bank accounts** for fiat on/off-ramps, and stick to one bank where possible so your transaction profile stays stable; - After opening a new banking relationship, proactively explain the purpose before the first crypto-related transfer; - Archive exchange statements once a quarter — do not wait for an inquiry to export them in a rush; - In years involving larger amounts, keep your tax filings and bank statements on the same set of numbers. > [!DANGER] Risk warning: this article is general compliance information, not legal or tax advice. Rules differ widely between countries and keep changing; for a specific case, consult a licensed professional in your country of residence. And block anyone who privately claims they can "handle the unfreezing for you" — that is the opening move of another scam. ## Account Hygiene Beyond Fiat On/Off-Ramps Beyond compliant fiat on/off-ramps, account hygiene is the global Chinese community's second daily routine: **one account, one platform, one password** (managed with a password manager, with an independent email and strong 2FA); **fixed fiat channels** (in your own real name, on the same bank card); **a paper-trail habit** (export and archive platform statements regularly — useful for both bank inquiries and tax filings). These actions cost a few minutes a month and cover the long-tail risks that sit beyond compliant fiat on/off-ramps. ## 6. Tax Filing Is Part of the Paper Trail (US) If you file taxes in the US, tax filing is itself a link in the funds chain. The IRS requires an answer to the digital-asset question on the federal tax return — even if all you did was buy and never sell, the official guidance is to answer "No" for that case (per the current year's form and instructions). If any disposition happened — a sale, a crypto-to-crypto exchange, or paying with crypto — the gain or loss must be reported through Form 8949 and Schedule D, and the reporting duty applies whether or not the transactions resulted in a taxable gain or loss. The filing record and your bank statements form one "explainable source of funds" evidence chain: when your tax reporting matches your fiat on/off-ramps, your explanation during a bank inquiry holds up.Fiat On/Off-RampComplianceSource of FundsAccount Appealhttps://szb123.com/en/articles/kraken-beginner-guide/https://szb123.com/en/articles/kraken-beginner-guide/The generic CEX onboarding flow: availability checks, tiered registration, authenticator-app 2FA, and small test withdrawals; fees defer to official docs.Thu, 01 Oct 2026 00:00:00 GMTThis is a generic exchange onboarding guide that uses Kraken as its narrative subject — every step is a generic centralized-exchange flow, and specific interfaces, fees, and regional availability defer to Kraken's official Help Center and fee page. This site does not constitute a recommendation of any platform; for the complete framework for choosing one, see this site's [platform guide](/en/platforms/). ## Step 1: Availability and Compliance Checks Any exchange's first gate is **regional availability** — regulatory frameworks differ from country to country, and the same platform serves different regions differently. How to verify: the availability pages in the official Help Center (Kraken's Help Center has per-region service descriptions). The second gate is **verifying the platform itself**: check the official domain character by character — counterfeit exchanges are a high-frequency zone for search-ad phishing. ## Step 2: Registration and Identity Tiers Mainstream exchanges use a tiered account system: higher tiers (higher limits, fiat channels) require more complete identity verification (KYC). The flow is standard: email registration → security setup → identity verification (ID documents plus proof of address) → tier unlocks. Two things to note: **identity information must be real and consistent** — using someone else's account for fiat on/off-ramps triggers compliance problems for both parties at once; and **keep records** — write down when verification passed and at which tier, because it is useful if a fiat on/off-ramp dispute ever arises. ## Step 3: Security Settings (the Most Critical Step) Per the official guidance of ethereum.org and the FTC: **use an authenticator app or a hardware key for 2FA, not SMS** — SMS codes cannot stop SIM swaps. The standard moves: bind an authenticator app, set an anti-phishing code (supported by some exchanges), enable a withdrawal whitelist (if supported), and give your email its own strong password and 2FA (the email is the pivot for every reset). This step costs ten minutes and covers most of the account-level risk. ## Step 4: Small Test Transactions and Withdrawal Discipline Make your first deposit under the "small amount" principle: use a payment channel registered under your own verified identity, and do not increase the amount until the verification flow has been walked through end to end. **Withdrawing to self-custody** is the key action: obtain the receiving address from your own self-custody wallet (record it offline, and do not copy it from your history — this is poisoning defense); do a small test withdrawal first, and confirm arrival before moving large amounts; the withdrawal network you choose must match the receiving wallet. Fees and rules at the transaction level defer to the official fee page — this article cites no specific numbers. ## A Checklist of Common Beginner Mistakes (Exchange Scenarios) 1. **Going live with SMS 2FA** — per the FTC, SMS cannot stop SIM swaps; the authenticator app should be set up before your first deposit; 2. **Copying withdrawal addresses from chat history** — the shared attack surface of address poisoning and clipboard hijacking (this site's [address poisoning case](/en/articles/address-poisoning-scam/)); 3. **Choosing the wrong withdrawal network** — the same token may be issued on multiple chains (for example, USDT's multi-chain versions); pick the wrong network and the funds may be unrecoverable; check that the "withdrawal network" matches the networks the receiving wallet supports; 4. **Forgetting the withdrawal whitelist** — if the exchange supports a withdrawal whitelist (withdrawals only to pre-set addresses), turn it on; 5. **Treating the exchange as a vault** — centralized custody carries structural risks — long-term assets belong in self-custody. ## The "Handover Ritual" from Exchange to Self-Custody Making your first withdrawal to a self-custody wallet is a process worth performing with ceremony. **Wallet side** — confirm the receiving address and network (after copying, compare it against what the wallet displays). **Exchange side** — add the address to the whitelist (there is usually a 24-hour activation period) and make a small test withdrawal. **Confirmation side** — check arrival on a block explorer and verify the balance inside the wallet. **Record side** — enter the address and time into your records. Only when this "handover ritual" is complete has your asset truly finished its transfer from custody to self-custody. ## Risk Disclaimer This article is a description of a generic process; it is not investment advice and does not constitute a recommendation of any platform. Platform rules, fees, and availability defer to the latest official documentation; platform risk (collapse, freezes) is a structural risk of centralized custody.KrakenAccount OpeningFiat On/Off-RampUSA