How we work
How a deebug engagement runs: written authorisation first, a fixed scope, findings with proofs, critical issues reported at once, and a list of what was not reviewed. For what a withdrawal-path review covers, see scope and method.
Principles
- Written authorisation before any testing. We do not scan, test or probe a system until you have authorised it in writing and we have agreed a scope list. If the scope is missing, we stop and ask.
- Fixed scope, fixed price. Price is set per scoped deliverable, not per day, and agreed in writing before work starts. The proposal states objectives, in-scope and not-reviewed items, milestones, deliverables, acceptance criteria, assumptions, your responsibilities and change control.
- We review; you fix. We do not change your live systems and we never move funds. Fixes are yours; we re-check them.
- Findings with proof. Every finding has a reproduction, a proof of concept that fails before the fix and passes after, and a way to verify the fix.
- Confirmed or suspected, said plainly. We separate what we confirmed from what we suspect, and say what evidence would settle a suspicion.
- Critical issues at once. A confirmed critical finding goes to your named contact as soon as it is confirmed, not in the final report.
- What was not reviewed is written down. Every report ends with a list of what we did not look at.
The sequence
| Step | What happens | You provide |
|---|---|---|
| 1. Scoping call | You describe what you run and why now. We ask what is missing. | A contact and a rough description of the systems |
| 2. Conflict check | We check the engagement against our conflict register and disclose any overlap in writing before scoping goes further. | Nothing |
| 3. Proposal | Fixed scope and price in writing. | Approval, or comments |
| 4. Authorisation | A signed scope list and authorisation for each system. | A signatory |
| 5. Review | Document and architecture review, walkthroughs, tests on named systems. | Access, documents, engineer time |
| 6. Reporting | Critical findings immediately; a full report at the end. | A contact who can receive findings |
| 7. Readout | A session with your engineers and risk owner. | Attendees |
| 8. Fix review | We re-check the fixes you make. | Fixed builds or evidence |
Severity
Each finding has a severity and a one-line reason for it. We rate by what an attacker or a fault can do to funds, to balances and to the withdrawal path, not by a scanner score. Severity is not negotiated for commercial reasons.
Confidentiality
Your material is confidential. We do not name clients or prospects in public material. We sign a mutual non-disclosure agreement before you share code, configuration or findings, and before the scoping call if you ask.
Questions
Do you test production systems?
Only systems named in the written scope. Where production testing is in scope, we agree the method with you first and we avoid anything that changes live state or moves funds.
Do you sign an NDA?
Yes. We sign a mutual non-disclosure agreement before you share code, configuration or findings, and before the scoping call if you ask.
Do you use AI?
Yes, in a limited way, and on client material only with a local model. Client material never goes to a third-party model service. A named person reproduces every finding, sets every severity and signs off every report. See how we use AI.
What do you need from us?
A named contact, architecture documents, read access to the code or design of the withdrawal path, some engineer time for walkthroughs, an agreed test environment, and written authorisation for each system in scope.
What do you not do?
We do not do standalone smart-contract audits, general web-application penetration testing, red-team or threat-led exercises, round-the-clock incident response, certification audits, or legal and regulatory opinions. Where you need one of these, we say so and can introduce a partner.
Do you fix the problems you find?
No. We report each finding with a recommended fix and re-check the fix you make. This keeps the review independent of the remediation.
Can you tell us whether we comply with our regulator's rules?
We can map our findings to the framework your regulator uses, as evidence for your own compliance work. We do not give legal advice or regulatory opinions, and a deebug report is not an audit opinion or a certification.
How long does it take and what does it cost?
A single withdrawal flow is planned at three to five weeks, confirmed at scoping. Price is fixed per scoped deliverable and agreed in writing before work starts. The home page shows the "from" prices for the packages.
Where are you based and which markets do you serve?
deebug is operated by 株式会社eMoment Japan KK in Tokyo and works with exchanges and custodians in any market. We provide regulatory mapping for Japan and the EU now, and for other regions as each is checked.
Want to talk it through?
Tell us what you run and what is prompting the review. We reply with questions, not a sales pitch.