dvcrn Onchain Contract / Token Analysis
Use this skill when the task is to assess a token, protocol, launch module, vault, staking system, router, or related onchain project from a security, permissions, tokenomics, or behavior perspective.
Core objective
Produce a practical analysis that answers:
- What the system does
- Who controls it
- How value and fees move
- What privileged actions exist
- What users can lose money from
- Whether there are obvious red flags or design risks
Workflow
1. Identify the scope
First determine which of these the request actually targets:
- token contract
- factory / launcher
- vault / staking / locker
- router / hook / proxy / module
- admin / governance / registry
- full protocol system
If the scope is unclear, infer it from the files, addresses, ABI names, deployment scripts, or docs.
2. Map the architecture
Before judging risk, build a compact model of the system:
- main contracts
- ownership / admin roles
- external dependencies
- upgradeability pattern
- event flow
- token creation flow
- fee routing flow
Prefer a short system map over long prose.
3. Check control and permissions
Always verify:
owner,admin,governor,operator,manager,signer- role-based access control
- pausable / blacklist / whitelist powers
- mint / burn / seize / rescue / withdraw permissions
- parameter setters
- upgrade authority
- emergency functions
Call out who can do what, and whether those powers are bounded or dangerous.
4. Check token mechanics
For ERC-20 and tokenized systems, verify:
- total supply model
- mintability
- burnability
- transfer restrictions
- fee on transfer / tax
- max wallet / max tx rules
- trading enable switch
- blacklist / antibot logic
- rebasing / reflection / hidden balance logic
- allowance edge cases
If the token claims to be standard, confirm whether behavior actually matches that claim.
5. Check fee and value flow
Trace where user funds or protocol fees go:
- LP fee recipients
- treasury recipients
- locker / vault recipients
- protocol fee splits
- conversion / swap path
- withdrawal path
- claim path
Do not just name recipients. Explain whether they are:
- immutable
- admin-changeable
- delayed
- claim-based
- dependent on offchain identity or signatures
6. Check upgradeability and mutability
If proxies or modules exist, verify:
- proxy type
- implementation admin
- initialization safety
- reinitialization protection
- storage layout assumptions
- upgrade trust model
If not upgradeable, still check whether behavior can change through configurable modules.
7. Check attack surface
Look for:
- arbitrary external calls
- reentrancy opportunities
- unchecked token callbacks
- unsafe approvals
- signature replay
- missing nonce / deadline checks
- address(0) edge cases
- misconfigured recipient logic
- accounting mismatch
- stale state after recipient updates
- rounding leakage
- griefing / denial-of-service vectors
When risk depends on business assumptions, state that explicitly.
8. Check market-facing risk
When the target is a token or launch flow, explicitly assess:
- honeypot-like behavior
- sell restrictions
- hidden tax changes
- admin ability to freeze exits
- liquidity custody
- locker guarantees
- whether front-end labels could misclassify the asset
Do not overclaim. Distinguish:
- confirmed malicious logic
- dangerous centralization
- poor design
- heuristic / market-behavior false positives
Output format
Default to this structure:
Summary
One short paragraph stating what the system is and the top conclusion.
Findings
List issues in severity order:
- severity
- title
- affected contract / function
- why it matters
- exploit or failure mode
- whether it is confirmed or conditional
Trust model
State:
- who controls upgrades
- who controls fees
- who controls pauses or restrictions
- what users must trust offchain
Token / fee flow
Explain:
- how tokens are created
- where fees accrue
- who can claim them
- what can change later
Open questions
List anything blocked by missing source, missing ABI, missing deployment info, or offchain dependencies.
Special guidance
When reviewing a suspicious token
Be precise:
- "can blacklist holders" is stronger than "looks risky"
- "owner can change tax" is stronger than "may be a scam"
- "no onchain sell restriction found" is stronger than "not a honeypot"
When reviewing a launch module
Always distinguish:
- launcher logic
- underlying token implementation
- LP locker behavior
- fee locker behavior
- who receives economic rights
When chain data is required
If the task depends on live state, verify with current chain or explorer data instead of assuming from source alone.
Do not
- Do not call something malicious without code-based support
- Do not confuse admin centralization with exploitability
- Do not ignore offchain identity dependencies when they control payouts
- Do not stop at contract syntax; trace actual economic outcomes