# Spark Audit Data Proposal An offer to share the results of an independent audit of how Spark is used on the public Firo chain, with the evidence, method and tooling behind it. - **Prepared by:** Vincent Medina (NexusOcean LLC) - **Contact:** nexusocean@proton.me - **Status:** Draft, October 2026 --- ## Summary I analyzed public Firo chain data to find out what an outside observer can learn about the people who move coins into and out of the Spark pool. The results show that Spark's cryptography held: no finding depends on breaking it. The exposure comes from how coins are handled before they go in and after they come out. Several of these patterns are common, measurable and fixable through wallet defaults and user guidance. I would like to share the full results with the community organization so they can inform wallet development, documentation and communication with users and masternode operators. ## Headline finding > **████% of public withdrawals can be tied to a deposit by the same owner, without touching Spark's cryptography.** Exact figures are withheld in this summary and provided under the terms below. ## About me I built and maintain FiroBlocks, the Firo block explorer, together with its Firo RPC service. The community has partly funded FiroBlocks' continued maintenance. I am also pursuing a master's degree in cybersecurity. ## What the audit covered - **Data source:** transactions indexed by FiroBlocks from public chain data only. - **Coverage:** several hundred thousand indexed transactions, with dense coverage from late April to early October 2026. Earlier chain history is not yet covered. - **Scope:** every Spark deposit, Spark spend and public withdrawal in that period, plus masternode payouts, registrations and the transparent transaction graph around them. - **Questions:** eleven research questions, each answered with a defined method and, wherever a result could arise by chance, tested against a control where no real link can exist. - **Data quality:** checks on the source index, with known labeling issues corrected before analysis. ## Findings overview Eleven questions were examined; four showed no leak. | Area | What it means for users | Assessment | Measured impact | | --------------------------------------- | ------------------------------------------------------------------------------------ | ---------- | ---------------------- | | Same owner on both sides | Reused addresses and wallet clustering tie withdrawals to the same owner's deposits. | ▲ Leak | ████ withdrawals | | Masternode rewards cycled through Spark | Operators who deposit rewards often merge withdrawn coins back into their own wallets. | ▲ Leak | ████ operators | | Where withdrawn coins go next | Withdrawn coins spent together reveal shared ownership, even without a deposit link. | ▲ Leak | ████ outputs | | Masternode collateral funded from Spark | Large withdrawals turned into masternode collateral make the destination visible. | ◆ Partial | ████ FIRO | | Exact coin values | A coin withdrawn untouched carries a fingerprint of the deposit that created it. | ◆ Partial | ████× fewer candidates | | Large multi-coin sweeps | Spending hundreds of coins at once points to the few depositors who hold that many. | ◆ Partial | ████ recipients | | Daily activity rhythm | A fixed daily routine on both sides of the pool is measurable. | ◆ Partial | top ████% | | Amount and timing round trips | Matching withdrawals to similar-sized deposits does no better than chance. | ● No leak | at chance | | Fee rates | Withdrawal fees carry no usable wallet signature. | ● No leak | at chance | | Spark name registrations | Registrations in the period were paid privately and reveal no payer. | ● No leak | none found | | Public change on Spark spends | Spends return change privately; no public change exists to analyze. | ● No leak | none found | **Legend:** ▲ leak: links owners outright · ◆ partial: narrows the candidates or exposes one side · ● no leak: indistinguishable from chance · ████ figure withheld The no-leak results are as useful as the leaks: they confirm which parts of Spark's design work as intended and can be communicated to users with confidence. ## Why this matters Most of the exposure can be fixed outside the protocol. - **Wallet defaults:** Withdrawing to fresh addresses, keeping withdrawn coins apart from depositing addresses, and spending inside Spark before withdrawing would remove most of the links found. - **Masternode operators:** Reward handling is the largest single source of links. Specific guidance for operators, and for any automatic reward-deposit feature, would have high impact. - **User education:** The findings translate directly into a short list of practices that users can follow today. - **A measurable baseline:** The same analysis can be rerun after changes ship, to show whether exposure actually went down. ## Method and rigor - Every probabilistic result is compared with a control (time reversed, clock rotated or values shuffled). Results that do not beat their control are reported as no leak. - Each finding states its confidence and its limits, and distinguishes direct evidence from heuristics such as address clustering. - The analysis is a reproducible TypeScript pipeline: one command rebuilds every result from the source data in under a minute. - Reports come in two editions from the same source: a public edition with aggregate figures only, and an internal edition with address-level evidence. ## Deliverables | Deliverable | Contents | Intended audience | | ------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------- | | Public report | All eleven findings with aggregate figures, charts, method, controls and limits. | Can be published | | Internal report | Adds the strongest cases per finding and full appendices with transaction and address-level evidence. | Named reviewers only | | Recommendations | Prioritized changes for wallets, operator guidance and user documentation, mapped to each finding. | Can be published | | Briefing | A walkthrough of the findings and Q&A with the people who will act on them. | Core contributors | | Analysis pipeline | Source code to reproduce the results and rerun them on new data. | By agreement | | Follow-up runs (optional) | Reruns after wallet changes ship, or over a longer stretch of chain history. | By agreement | ## Responsible handling The internal edition can link real users' transactions. I propose handling it as a private disclosure: - Address-level data is never published, by me or by recipients. - The internal edition goes only to named reviewers who agree to these terms. - Findings are shared privately first, with an agreed window to prepare guidance or wallet changes before any public summary. - Any public release uses the public edition, which contains no addresses or transaction ids. - Storage and retention of address-level data follow the terms agreed in the community discussion (see Next steps). The core user-protection guidance will be shared with the core team regardless of funding; compensation covers the detailed evidence, reports, briefing and tooling. If the proposal is not funded, further use of this research is at my discretion, including continued work as part of my master's program in cybersecurity. ## Proposed terms ### Compensation All amounts are in FIRO. - **Core** (private briefing if desired, internal edition, public edition, recommendations): 1,000 FIRO - **Pipeline** (source code released under the MIT license, so others can rerun it): +300–500 FIRO - **Follow-up run** (rerun after wallet changes ship, with a short comparison): +200–300 FIRO each ### Timeline Initial audit complete. Reports and briefing within 7 days of approval. ### Disclosure window 14 days between the private briefing and any public summary, to be agreed with the reviewers. ### Code license MIT ### Reviewers Open to discussion. ## Next steps 1. Confirm interest and name the reviewers. 2. Agree the terms and the disclosure window. 3. Community discussion of how the internal edition is handled: who receives it, how it is stored, and when the public edition is released. 4. Private briefing and delivery of the internal edition to the named reviewers. 5. Coordinated public release of the public edition and recommendations. --- *Figures in this summary are withheld deliberately. They are available to the community organization under the terms above.*# Spark Audit Data Proposal An offer to share the results of an independent audit of how Spark is used on the public Firo chain, with the evidence, method and tooling behind it. - **Prepared by:** Vincent Medina (NexusOcean LLC) - **Contact:** nexusocean@proton.me - **Status:** Draft, October 2026 --- ## Summary I analyzed public Firo chain data to find out what an outside observer can learn about the people who move coins into and out of the Spark pool. The results show that Spark's cryptography held: no finding depends on breaking it. The exposure comes from how coins are handled before they go in and after they come out. Several of these patterns are common, measurable and fixable through wallet defaults and user guidance. I would like to share the full results with the community organization so they can inform wallet development, documentation and communication with users and masternode operators. ## Headline finding > **████% of public withdrawals can be tied to a deposit by the same owner, without touching Spark's cryptography.** Exact figures are withheld in this summary and provided under the terms below. ## About me I built and maintain FiroBlocks, the Firo block explorer, together with its Firo RPC service. The community has partly funded FiroBlocks' continued maintenance. I am also pursuing a master's degree in cybersecurity. ## What the audit covered - **Data source:** transactions indexed by FiroBlocks from public chain data only. - **Coverage:** several hundred thousand indexed transactions, with dense coverage from late April to early October 2026. Earlier chain history is not yet covered. - **Scope:** every Spark deposit, Spark spend and public withdrawal in that period, plus masternode payouts, registrations and the transparent transaction graph around them. - **Questions:** eleven research questions, each answered with a defined method and, wherever a result could arise by chance, tested against a control where no real link can exist. - **Data quality:** checks on the source index, with known labeling issues corrected before analysis. ## Findings overview Eleven questions were examined; four showed no leak. | Area | What it means for users | Assessment | Measured impact | | --------------------------------------- | ------------------------------------------------------------------------------------ | ---------- | ---------------------- | | Same owner on both sides | Reused addresses and wallet clustering tie withdrawals to the same owner's deposits. | ▲ Leak | ████ withdrawals | | Masternode rewards cycled through Spark | Operators who deposit rewards often merge withdrawn coins back into their own wallets. | ▲ Leak | ████ operators | | Where withdrawn coins go next | Withdrawn coins spent together reveal shared ownership, even without a deposit link. | ▲ Leak | ████ outputs | | Masternode collateral funded from Spark | Large withdrawals turned into masternode collateral make the destination visible. | ◆ Partial | ████ FIRO | | Exact coin values | A coin withdrawn untouched carries a fingerprint of the deposit that created it. | ◆ Partial | ████× fewer candidates | | Large multi-coin sweeps | Spending hundreds of coins at once points to the few depositors who hold that many. | ◆ Partial | ████ recipients | | Daily activity rhythm | A fixed daily routine on both sides of the pool is measurable. | ◆ Partial | top ████% | | Amount and timing round trips | Matching withdrawals to similar-sized deposits does no better than chance. | ● No leak | at chance | | Fee rates | Withdrawal fees carry no usable wallet signature. | ● No leak | at chance | | Spark name registrations | Registrations in the period were paid privately and reveal no payer. | ● No leak | none found | | Public change on Spark spends | Spends return change privately; no public change exists to analyze. | ● No leak | none found | **Legend:** ▲ leak: links owners outright · ◆ partial: narrows the candidates or exposes one side · ● no leak: indistinguishable from chance · ████ figure withheld The no-leak results are as useful as the leaks: they confirm which parts of Spark's design work as intended and can be communicated to users with confidence. ## Why this matters Most of the exposure can be fixed outside the protocol. - **Wallet defaults:** Withdrawing to fresh addresses, keeping withdrawn coins apart from depositing addresses, and spending inside Spark before withdrawing would remove most of the links found. - **Masternode operators:** Reward handling is the largest single source of links. Specific guidance for operators, and for any automatic reward-deposit feature, would have high impact. - **User education:** The findings translate directly into a short list of practices that users can follow today. - **A measurable baseline:** The same analysis can be rerun after changes ship, to show whether exposure actually went down. ## Method and rigor - Every probabilistic result is compared with a control (time reversed, clock rotated or values shuffled). Results that do not beat their control are reported as no leak. - Each finding states its confidence and its limits, and distinguishes direct evidence from heuristics such as address clustering. - The analysis is a reproducible TypeScript pipeline: one command rebuilds every result from the source data in under a minute. - Reports come in two editions from the same source: a public edition with aggregate figures only, and an internal edition with address-level evidence. ## Deliverables | Deliverable | Contents | Intended audience | | ------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------- | | Public report | All eleven findings with aggregate figures, charts, method, controls and limits. | Can be published | | Internal report | Adds the strongest cases per finding and full appendices with transaction and address-level evidence. | Named reviewers only | | Recommendations | Prioritized changes for wallets, operator guidance and user documentation, mapped to each finding. | Can be published | | Briefing | A walkthrough of the findings and Q&A with the people who will act on them. | Core contributors | | Analysis pipeline | Source code to reproduce the results and rerun them on new data. | By agreement | | Follow-up runs (optional) | Reruns after wallet changes ship, or over a longer stretch of chain history. | By agreement | ## Responsible handling The internal edition can link real users' transactions. I propose handling it as a private disclosure: - Address-level data is never published, by me or by recipients. - The internal edition goes only to named reviewers who agree to these terms. - Findings are shared privately first, with an agreed window to prepare guidance or wallet changes before any public summary. - Any public release uses the public edition, which contains no addresses or transaction ids. - Storage and retention of address-level data follow the terms agreed in the community discussion (see Next steps). The core user-protection guidance will be shared with the core team regardless of funding; compensation covers the detailed evidence, reports, briefing and tooling. If the proposal is not funded, further use of this research is at my discretion, including continued work as part of my master's program in cybersecurity. ## Proposed terms ### Compensation All amounts are in FIRO. - **Core** (private briefing if desired, internal edition, public edition, recommendations): 1,000 FIRO - **Pipeline** (source code released under the MIT license, so others can rerun it): +300–500 FIRO - **Follow-up run** (rerun after wallet changes ship, with a short comparison): +200–300 FIRO each ### Timeline Initial audit complete. Reports and briefing within 7 days of approval. ### Disclosure window 14 days between the private briefing and any public summary, to be agreed with the reviewers. ### Code license MIT ### Reviewers Open to discussion. ## Next steps 1. Confirm interest and name the reviewers. 2. Agree the terms and the disclosure window. 3. Community discussion of how the internal edition is handled: who receives it, how it is stored, and when the public edition is released. 4. Private briefing and delivery of the internal edition to the named reviewers. 5. Coordinated public release of the public edition and recommendations. --- *Figures in this summary are withheld deliberately. They are available to the community organization under the terms above.*