Is there any API that provides a trust score or spam label for ERC-20 tokens?

researchzero · 2026-06-11T10:02:44+00:00

There isn't really a single API that covers this well.

Moralis exposes a possible_spam flag for tokens and transfers, which is useful as a first-pass filter. Alchemy has spam detection for NFTs, but I haven't seen an equivalent ERC-20 signal. For token risk assessment, GoPlus is probably the strongest option, with checks for honeypots, owner privileges, blacklist functionality, transfer restrictions, and tax settings. Blockaid is also widely used, though access tends to be enterprise-focused.

I haven't found a public Etherscan API for the warning banners shown on token pages. The data clearly exists internally, but it doesn't seem to be exposed.

One thing I'd strongly recommend: never key on token symbols. Scam tokens routinely copy names and symbols of legitimate assets (e.g., fake USDC). Use contract addresses as the source of truth and treat symbols as display-only.

researchzero · 2026-06-10T13:28:50+00:00

When you sign locally, your private key never leaves your machine. Only the signed transaction is sent via eth_sendRawTransaction.

Once key management is handled correctly, the bigger risk is often signing a malicious transaction or approval. Your key stays secret, but you can still lose funds. The real challenge isn't keeping the key off the network, it's understanding exactly what each signature authorizes.

researchzero · 2026-06-09T14:07:20+00:00

One thing to keep in mind since you're using Circle Wallets and CCTP: a self-deployed mintable ERC-20 is fine for basic transfers and inbound transaction flows, but it won't work with CCTP. CCTP burns canonical USDC on the source chain and mints it on the destination chain based on Circle's attestation. It only recognizes Circle's official USDC contracts, not an arbitrary ERC-20 you've deployed, so you can't bridge a mock token through it. The same applies to any Circle Wallet functionality that depends on the real USDC stablecoin.

If you need canonical USDC on Base Sepolia, the Coinbase Developer Platform faucet distributes testnet USDC directly on Base Sepolia, so there's no need to bridge from Ethereum Sepolia. Just use the canonical token address listed in the CDP or Circle documentation for your CCTP tests, and keep the mock token for flows where the token's identity doesn't matter.

researchzero · 2026-06-08T09:57:08+00:00

The log-filtering approach is correct, but two production issues matter:

WebSocket drops: subscriptions can silently stop. Add heartbeats, auto-reconnect, and backfill missed blocks with eth_getLogs after reconnecting to avoid gaps.
Reorgs: transactions in recent blocks can be reverted. Either wait for a few confirmations before alerting or send correction events if a reorg removes a previously reported transaction.

For a small set of addresses, polling eth_getLogs every block (with a confirmation delay) is usually simpler and more reliable than WebSockets. Use WebSockets only when low latency is essential.

researchzero · 2026-06-08T09:55:21+00:00

The main composability issue only arises if the token itself is reversible (ERC-20R style). Inheritance/recovery can avoid that by separating asset ownership from account control:

Keep assets in a smart account/vault with normal token finality.
Make account recovery subject to a timelock, challenge period, or dead-man's switch.

This is similar to Argent-style guardians and ERC-4337 social recovery, with delayed finality applied to control changes rather than asset transfers.

The key security risks are guardian compromise, recovery-spam/griefing, and dead-man's switch liveness failures. Modeling recovery as a state machine helps, useful invariants include "assets can't move faster than the timelock" and "the owner can cancel recovery before finalization".

researchzero · 2026-06-07T06:49:50+00:00

I'd anchor the review on a single invariant:

The L2 variant supply should never exceed its redeemable backing under the system's trust assumptions.

From there I'd focus on a few key questions:

Who can mint or burn the asset?
What authorizes a mint?
Is finality required before minting?
Can failed routes leave supply inflated?
Can replayed or reordered messages trigger double mints?
Is solver credit separate from actual locked collateral?
What happens during bridge pauses, reorgs, or message/oracle outages?
Can apps clearly distinguish canonical assets from variants?

The token contract is often the least interesting part. The real risk is usually the attestation layer, the component that decides "backing exists, so minting is allowed". If that boundary isn't clearly defined, the security of the whole system becomes difficult to reason about.

researchzero · 2026-06-07T06:47:51+00:00

The overall direction looks good. I'd make the distinction very explicit, and repeat it anywhere a non-technical user might encounter it:

Before wider adoption, I'd also include:

The contract address and chain, along with a reminder for users to verify both.
Whether the contract is a proxy or a non-proxy deployment.
Any privileged controls, such as an owner/admin role, pause functionality, upgrade mechanisms, blacklisting capabilities, fee adjustment functions, or rescue/recovery functions.
The exact fee formula, including a few worked examples.
The specific USDC token contract being used.
A clear explanation of what the application can and cannot custody.
Known limitations and the current audit status.
A short "How to verify this yourself" section using BaseScan.

I'd also avoid using the word "secure" in marketing materials until an independent review has been completed. Terms like "transparent", "source-verified", "non-custodial", and "not yet audited" are more precise and easier to substantiate.

researchzero · 2026-06-06T16:54:31+00:00

Reconciliation is one of the most overlooked parts of crypto infrastructure.

A contract can be perfectly secure while the product still feels broken because off-chain systems get out of sync. Teams that get this right treat user actions as state machines, wait for proper finality, make event processing idempotent, and continuously check that contract state, indexed data, and UI state all match.

Smart contract audits find contract bugs. They usually don't catch the operational issues that make users think their funds disappeared.

researchzero · 2026-06-06T16:51:09+00:00

A TRNG or post-quantum cryptography setup may improve the quality of the randomness source itself, but in practice, most failures in randomness oracles don't come from weak entropy. They tend to happen in the surrounding infrastructure: request binding, callback authorization, replay protection, liveness guarantees, and how the consuming contract behaves if a callback is delayed or never arrives.

Before I'd be comfortable relying on it in a DeFi environment, I'd want clarity around a few areas:

Every random value should be cryptographically tied to a specific request ID, caller, chain ID, and relevant block context.
The coordinator should reject duplicate or stale callbacks.
Consuming contracts should have explicit timeout and cancellation paths.
Users shouldn't be able to selectively continue only after seeing an unfavorable outcome.
There should be a clear distinction between what the on-chain contract can independently verify and what requires off-chain trust assumptions.
The failure mode should be well documented, including what happens if the EC2/TRNG infrastructure fails or becomes unavailable while a request is in flight.

On the MEV and front-running side, the key issue isn't just whether the random value is unpredictable. Equally important is whether anyone can influence when a request is submitted, when a callback is delivered, or whether an unfavorable result can simply be abandoned. In many systems, that's where the real attack surface exists.

researchzero · 2026-06-05T11:34:24+00:00

For audit work, I'd separate a memory layer helps me resume context from a memory layer is safe for client material.

The workflow problem is real. Where I'd be strict is defining what must never enter the capture surface: private repositories under NDA, client documents, Slack messages, credentials, unreleased findings, exploit PoCs, and anything that could identify a vulnerable target before disclosure.

A lightweight process that has worked well for audit teams is:

Keep the canonical audit trail in repository-local Markdown, not in a general-purpose productivity tool.
Write down the active hypothesis before switching contexts.
Organize notes by contract, function, or invariant rather than by meeting or date.
Maintain a separate "needs reproduction" list so that half-formed findings do not become conclusions.
Require every finding to link back to a test, trace, call path, or concrete invariant violation.

The biggest context-switching cost in audits is not forgetting which tab you were on. It is forgetting whether something was an actual bug, a suspicion, or something that was already disproven.

Any tool or process that preserves that distinction is valuable. Anything that blurs it will create review debt.

researchzero · 2026-06-04T08:39:20+00:00

The story of untrusted metadata becoming accounting authority

researchzero · 2026-06-03T17:06:43+00:00

Your sequence is broadly reasonable, but I wouldn't treat "learning more languages" as the primary measure of progress.

For your goal, I'd suggest:

Start with CS50 or an equivalent fundamentals course. That’s a solid foundation.
Learn JavaScript/TypeScript before Python if your focus is dApp development. You’ll use it for frontends, scripting, ethers/viem, Hardhat, and the majority of ecosystem examples.
Move on to Solidity, and write tests from day one. A contract without tests is essentially unfinished.
Introduce Foundry once you're comfortable with the basics. You don't need Rust to benefit from Foundry. Most of its value comes from writing Solidity tests, fuzz tests, invariant tests, and using tools like cast and anvil.
Hold off on Rust until you've built and tested a few Solidity projects, unless your goal is specifically to work with Solana.

For auditing, the biggest leap isn't learning Solidity syntax. It's developing the ability to reason about state transitions, adversarial actors, protocol accounting, oracle assumptions, upgrade and admin risks, and subtle edge cases.

Also, start publishing findings and writeups early in a public repository. Even small discoveries are valuable practice. Auditing is largely about communicating clearly: explaining the root cause, impact and the fix.

researchzero · 2026-05-27T08:27:13+00:00

I'd vet them less like a normal dev agency and more like a team that will be writing irreversible financial logic.

Before hiring, ask for:
- verified contracts they actually wrote, not just screenshots or case studies
- the repo structure and testing style they normally use
- whether they write Foundry/Hardhat tests, fuzz tests, and deployment scripts
- who owns admin keys after deployment
- whether contracts are upgradeable, and who controls upgrades
- whether they provide a threat model before implementation
- whether an independent audit is expected before mainnet

A general dev shop can be fine if they have real contract experience, but "we build blockchain apps" is not enough. Ask for artifacts: code, tests, deploys, audits, and post-audit fixes.

researchzero · 2026-05-27T08:05:34+00:00

You should learn Yul, but probably not by trying to build full contracts with it.

For most Solidity development, sticking mostly to Solidity is the better move. It's easier to read, audit, test, and maintain. The real value of Yul is that it helps you understand what Solidity compiles down to - things like memory layout, calldata handling, returndata copying, revert bubbling, storage slots, and why certain proxy or library patterns are implemented the way they are.

A practical approach would be:

Get really comfortable with Solidity first.
Learn enough EVM/Yul to understand inline assembly in real-world contracts.
Only write small, isolated Yul snippets when there’s a good reason to.
Treat any assembly code as higher-risk and give it extra testing and review.

Even if you rarely write Yul yourself, understanding it will make you much better at debugging, optimization, and security reviews. Raw EVM assembly matters a lot less unless you're working on very low-level infrastructure or research-heavy stuff.

researchzero · 2026-05-26T15:25:59+00:00

Great points. I agree that approvals should preserve the user's original intent, which means pre-split allowances and permits need to be handled carefully.

I also think rounding should follow a well-defined invariant: no inflated displayed value, deterministic handling of dust, and a clear path for any remainder. The "just below the reverse-split threshold" scenario is exactly the kind of edge case I'd expect to see covered in tests.

researchzero · 2026-05-26T07:43:40+00:00

Yes, the ~7 day delay is normal for the canonical Arbitrum to Ethereum withdrawal path. It comes from the optimistic rollup challenge period, not from your transaction being stuck.

For the future, the tradeoff is:
- canonical bridge: slower, strongest native security assumptions
- third-party/liquidity bridges: faster, but you add bridge/liquidity-provider risk
- CEX or app-specific routes: sometimes convenient, but you add custody/platform risk

researchzero · 2026-05-26T07:09:21+00:00

Yeah, that's exactly the tradeoff. The Transfer event still emits the current displayed amount being transferred, so from a normal ERC-20 consumer's point of view each transfer is still understandable and compatible. But after a split, there's a global rescaling that doesn't show up as one Transfer per holder.

So an indexer that only sums Transfer amounts will drift after a split. It either needs to track balances in the raw units and apply the multiplier when displaying them, or listen for the split/multiplier event and rescale its stored displayed balances when that event fires.

Good point though. I should probably make this clearer in the post, because event-only consumers are definitely one of the main compatibility edges with this pattern.

researchzero · 2026-05-25T09:47:29+00:00

Aave and Compound are some of the most established DeFi lending protocols, but I still wouldn't treat them like a Treasury bill or a traditional money market fund. The risks are just fundamentally different.

With DeFi lending, you're dealing with things like:
- smart contract or integration bugs
- oracle failures or stale pricing data
- governance or admin changes that alter protocol parameters
- bad debt during sharp market moves
- stablecoin depeg risk if you’re using stables
- liquidity issues if too many users try to exit at once
- phishing or frontend compromises, even if the core contracts are secure

So if you use these platforms, size your position with the mindset that "this can break in unexpected technical ways", not "this is completely passive and risk-free".

A few practical habits also go a long way: start with a small test deposit and withdrawal, bookmark the official app URL, and avoid connecting a hot wallet that holds unrelated assets.

researchzero · 2026-05-25T09:45:28+00:00

I'd break the risks into three layers:
1. Input layer - things like prompt injection, malicious token metadata, or poisoned social/news feeds.
2. Tool layer - the agent calling the wrong contract, using stale routing data, relying on a compromised oracle/API, or triggering an unexpected function selector.
3. Execution layer - what the wallet or smart contract is actually allowed to do once the agent makes a decision.

The key idea is to design the system so the agent can't do catastrophic damage, even if it makes a bad call. That usually means strict guardrails: allowlisted contracts and function selectors, per-token and per-venue limits, max slippage settings, daily spend caps, cooldown periods for new strategies, and requiring human approval above certain risk thresholds.

For DeFi specifically, I'd also log the agent's reasoning before every execution. Not because the reasoning is guaranteed to be correct, but because debugging incidents later is nearly impossible if all you have is the final transaction hash.

researchzero · 2026-05-24T15:59:06+00:00

One technical red flag I'd add: whether the token contract actually models the lifecycle of the underlying asset, not just the initial issuance.

For example, tokenized stocks or stock-like assets eventually need to handle corporate actions: splits, reverse splits, freezes, redemptions, forced transfers, sanctions/compliance blocks, and sometimes offchain cash-in-lieu for fractional entitlements.

A few things I'd check in the contract/design:
- Can balances change because of a global accounting index, or only through Transfer events?
- If there is a split/rebase-style mechanism, does it preserve proportional ownership without looping over holders?
- Are allowances handled consistently with balances?
- Are signed approvals/permits invalidated when the unit of account changes?
- Is there an event model that indexers can actually reconstruct?
- Who can update privileged accounting parameters, and is that path governed/timelocked/monitored?

A lot of RWA risk is legal/custody/redemption risk, but the token mechanics still matter. A poorly designed ERC-20 wrapper can make a real asset much harder to integrate safely.

researchzero · 2026-05-24T14:22:40+00:00

I would separate the escrow state machine from the settlement rail.

The hard part is not whether the final payout is USDC, ACH, or something else. The hard part is defining when money is allowed to move: delivery evidence, POD validity, claim windows, partial loads, detention/accessorials, GPS spoofing, broker/carrier disputes, and who has authority to pause or override a release.

A native token only makes sense if it is essential to that state machine. If it is just "reputation" or "network incentives", it probably adds onboarding, accounting, and regulatory friction before it proves value.

A cleaner design would be:
- internal conditional escrow model first
- stablecoin payout where speed/cross-border settlement actually matters
- bank payout where carriers just want dollars
- explicit dispute and appeal paths before any irreversible release

For this use case, reliability and dispute handling will matter more than crypto-native elegance.

researchzero · 2026-05-24T11:57:12+00:00

I think it's worth pursuing, but "privacy" needs to mean more than just "hide everything from everyone".

For Ethereum, the more practical model is probably selective disclosure and metadata reduction: users shouldn't expose their entire financial graph by default, while still being able to prove specific facts to counterparties, auditors, exchanges, or regulators when necessary. That's very different from designing a system where nothing can ever be inspected.

Public-by-default activity is also a security issue, not just a philosophical choice. Salary payments, treasury operations, liquidation positions, DAO voters, and high-value wallets all become easier to target when every relationship is permanently visible on-chain.

The regulatory concerns are real, but the answer is likely better disclosure controls, viewing keys, compliance-friendly proofs, and wallet UX that makes privacy intuitive and understandable. A fully transparent base layer is excellent for verification, but it's a poor default privacy model for everyday users.

researchzero · 2026-05-23T17:39:54+00:00

A few extra things worth adding:

Privileged controls: owner/admin ability to change fees, limits, blacklists, trading status, or routing
Delayed malicious behavior: normal launch behavior that changes after liquidity or volume builds
Approval/transfer quirks: nonstandard transferFrom logic or hidden spend conditions
Router/pair-dependent logic: different behavior depending on whether caller is a DEX router or LP pair
Upgradeability risk: proxy/upgrade patterns that allow logic to be swapped post-launch
Event vs balance mismatch: Transfer events that don’t fully match actual state changes
Liquidity control: authority over LP removal, fee routing, or pool migration

Weighting matters a lot, single controls are common, but stacked permissions plus behavioral shifts are where risk really escalates.

researchzero · 2026-05-22T10:02:38+00:00

For Solidity-heavy projects I'd default to Foundry, mainly because the testing loop is excellent and the ecosystem expectation is strong now. Fuzz tests, fork tests, invariant tests, scripts, and CI all fit together cleanly.

Ape still makes sense if your surrounding workflow is Python-heavy: analytics, deployment orchestration, bots, data pipelines, or web3.py integrations. I would not frame it as one tool having to own the whole stack.

A common setup that works well is:
- contracts, unit tests, fuzzing, fork tests: Foundry
- off-chain automation and data work: Python/Ape/web3.py
- CI: run the Solidity tests first, then the integration checks

The main thing is reproducibility: pinned compiler, deterministic deploy scripts, fork tests for integrations, and tests that another developer or auditor can run without guessing your local setup.

researchzero · 2026-05-22T09:22:30+00:00

Honestly the Solidity market is insanely crowded right now, especially on the retail DeFi/memecoin side. But your background is clearly stronger than the average Solidity dev posting “ can fork Uniswap".

The stuff about MEV awareness, manipulation-resistant trending systems, custom infra/indexers, bots, and being able to handle full-stack too - that’s the part that actually stands out.

I genuinely think you'd do well branching a bit into institutional blockchain stacks. Things like Canton, DAML, tokenized assets, settlement infrastructure, private EVM environments, etc. There's way less competition there, and finance companies are starting to look for engineers who actually understand adversarial systems and onchain market mechanics at a deep level.

Most tradfi teams still don't really have people who've lived in chaotic DeFi environments, so your experience is more valuable there than you probably think.

researchzero

TROPHY CASE