# Don’t just focus on points: today, these 3 early projects are entering the verification window

Today, take a look at PinetSwap, Axis Robotics, and Asentum: one has open claiming, one has a task and a sales node that’s coming up, and one has just fixed a verifier scoring-chain issue.

What matters now isn’t continuing to pile up interactions, but confirming eligibility, signature status, and whether the testnet accounting is truly valid.

The biggest risks are that the rewards page impersonation, community snapshot information not confirmed by official sources, and nodes being online but not being properly scored.

## PinetSwap

**In one sentence: ** September 25 is not a day for new users to complete bonus tasks, but a day for veteran participants to verify whether the “snapshot—allocation—claim” loop actually works.

**Why now:** The official says the earning phase has ended. A final snapshot was completed on September 24 and allocation queries have been opened. Claims open at 10:00 UTC on September 25; PINE/SDA transaction plans will start at 10:00 UTC on September 26. The nodes are fairly clear, but the project is smaller in size—successful claiming doesn’t necessarily mean there will be enough liquidity the next day.

**Metrics worth tracking:**

- Whether participating wallets can display allocations and complete claims;

- Claim transaction failure rate and the official processing speed;

- Next-day pool depth, actual traded volume, and slippage for large transactions.

**Pitfalls I will avoid:** I won’t enter the claim page via comments, DMs, or search ads; I won’t directly convert the token amounts shown on the page into value. Some users have expressed dissatisfaction because the allocation is below expectations. For new users at this time, temporary interaction also can’t make up for the already-ended earning phase.

## Axis Robotics

**One-line takeaway:** What really needs checking isn’t how many robot tasks you did today, but whether the old trajectory has completed verification and been signed in the historical records.

**Why now:** Creator Program Epoch 2 started on September 19. Final rankings are based on cumulative performance across multiple rounds; community sales will end at 05:00 UTC on September 28. Over the past two days, the community has repeatedly warned that “unsigned tasks may not be counted for scoring,” but the exact snapshot time hasn’t been confirmed by the official at the same level in this search—so it’s suitable for leak-checking, not for blindly pumping volume based on rumors.

**Metrics worth tracking:**

- In Portfolio History: the three categories of statuses—Pending, Ready to Sign, and signed;

- Whether task acceptance rate, quality, and diversity matter more than sheer quantity;

- Whether the official has added details: snapshot time, point mapping, and the Epoch 2 ranking criteria.

**Pitfalls I will avoid:** I won’t treat the “green completion indicator for tasks” as already being scored, and I won’t infer a fixed allocation from community screenshots. Sales involve KYC, wallet screening, regional restrictions, and lockups—these are completely different from low-cost tasks and can’t be mixed when judging risk.

## Asentum

**One-line takeaway:** The most valuable signals these days aren’t XP promotions, but the fact that the official finally fixed the core issue where “nodes are running but votes weren’t being counted.”

**Why now:** On September 24, the official released Operator v0.6.68, which handles epoch boundary freezes, helps behind nodes catch up, counts votes, attributes signature rewards, and requires validators to upgrade before block 180,000. On September 25, they also emphasized that consumer-grade devices can participate. For existing nodes, this is a version window that directly affects how future scoring is done.

**Metrics worth tracking:**

- After upgrading, whether sync height keeps progressing and whether the vote counted logs remain stable;

- After block 180,000, whether the dashboard’s XP matches actual signatures;

- Whether the official will retroactively credit any previously missed XP, or continue releasing patched versions.

**Pitfalls I will avoid:** I won’t temporarily buy in or stake assets just because of a multiplier, and I won’t treat “program online” as effective verification. Nodes require hardware, power, network connectivity, and time for troubleshooting. Even with fast testnet upgrades, quick resync and missed crediting can still happen.

## Collectible decision-making framework

When I encounter new airdrop signals, I only pass through four gates: **first, check whether the node is given an official, explicit date; then check whether the action will truly change eligibility; third, see whether the result can be verified via on-chain records, past states, or the allocation page; finally, calculate the worst-case cost, including gas, slippage, lockups, device and account risk.** If two of the four are missing, I only observe. If the time is clear but eligibility has already been closed, I help old users with leak-checking. If the rules still rely on community retellings, I don’t add more funds for a “possible snapshot.” Today, the three correspond to claim verification, task signature checks, and node bookkeeping verification—the focus isn’t chasing hype, but confirming whether the system has truly credited you.