What Dripcheck is today
Dripcheck is currently a documented mechanism and design direction, not a running scanner. No contract-analysis engine, lock-contract reader, or public case log has been implemented yet.
Concept in development
Dripcheck is a proposed fast-glance concept for liquidity-lock and owner-privilege signals — not yet a live scanning tool.
How it works
Dripcheck is currently a documented mechanism and design direction, not a running scanner. No contract-analysis engine, lock-contract reader, or public case log has been implemented yet.
The intended flow: paste a token address, receive a plain yes/no on liquidity-lock status and owner-privilege flags in place of a raw audit. This on-chain checking and bytecode analysis is PLANNED, not built.
Even if built, a lock-status flag would only be a heuristic glance. It could miss novel scam patterns entirely and would carry no liability or warranty of safety — this boundary is intentional and permanent.
DRIP's only proposed relationship to the product is a non-binding feature-priority poll on future direction — no equity, no revenue share, no guaranteed roadmap, and this polling mechanism itself is not yet implemented.
Possible misreading as investment advice, false negatives on novel contracts, gaming of any future public report log, and regulatory sensitivity around tools that imply safety signals — all acknowledged before any code ships.
The honest boundary
Holding the token unlocks a vote on which chain, feature, or flag-type gets built next; the roadmap is literally shaped by holder polls, no other utility promised.
This is a heuristic scanner, not a guarantee — it cannot catch every scam pattern, holds no legal liability for losses, and the token itself carries no equity, revenue share, or governance beyond feature-priority polls.
Questions
No. At this stage Dripcheck is a documented concept and mechanism design. No scanning engine, lock-contract reader, or public case log has been implemented or deployed.
No, even in its intended future form Dripcheck would be a heuristic glance, not a safety guarantee. It could not catch every scam pattern, including novel contract structures, and would carry no liability for trading losses.
The only proposed relationship is a non-binding feature-priority poll — for example voting on which chain or flag-type to prioritize if development proceeds. DRIP would carry no equity, revenue share, or governance rights beyond that, and even this polling mechanism is not yet built.
Nothing is implemented yet. Any chain coverage, translation, or accessibility support beyond an initial English interface is PLANNED at best, and would depend on future engineering and community translation efforts that have not started.
This is unresolved. A community-submitted case log is only a proposed feature; anti-gaming, moderation, and verification safeguards for it do not exist yet and would need to be designed before any such log could be trusted.