Known Issues & Pipeline
A public list of what we already know about, so researchers do not spend their time rediscovering it and we do not spend ours re-triaging it.
Last updated: August 2026 | Network stage: Public beta testnet
If something you have found appears below, it is already tracked — you are welcome to tell us anyway, but expect it to be closed as a duplicate. If it does not appear below, we want to hear about it: security@vexidus.com.
Known and intentional on testnet
These are deliberate configurations of the public beta testnet. They are not defects, and they do not carry to mainnet.
| Area | Testnet behaviour | Mainnet |
|---|---|---|
| Transaction signatures | Not enforced — see Testnet Security Model | Enforced; launch requirement |
| Token / test assets | No value, freely mintable via faucet | N/A |
| Chain reset | The testnet has been reset before and may be again | Never |
By far the most-reported item is the first one. Five independent researchers reported it between April and August 2026. It is known, it is intentional on testnet, and closing it for mainnet is tracked work rather than a discovery.
Known and being fixed
Work already identified and in the pipeline. Listed so you know it is not news to us.
| Area | Status |
|---|---|
| Signature enforcement for mainnet | In progress — the sequencing is deliberate, because enabling it carelessly would make some testnet-era balances permanently unusable |
| Client-side transaction signing across our apps | Largely complete as of August 2026; wallet, DEX, forge, governance and logistics surfaces now build and sign transactions client-side |
| Bridge hardening for mainnet | Tracked; cross-chain verification is not considered production-ready and testnet bridges should be treated as demonstrations |
| Rate limiting and request-shaping on public RPC | Tracked, partially deployed |
| TLS on direct validator RPC endpoints | Tracked for mainnet. On testnet every transaction is public on the explorer anyway |
| Email authentication (DMARC enforcement) | Tracked |
Out of scope
Reported often, and closed every time:
- Public ledger data described as "exposed" — validator sets, stakes, commissions, rewards, tokenomics splits, bridge fee schedules and jail policy are public by design. A blockchain cannot function otherwise. Reporting them as a disclosure vulnerability reflects a misunderstanding of the system rather than a finding.
- Verbose RPC error messages — intentional developer ergonomics on a developer-facing RPC. Everything they reveal is already public in our SDK and client version string.
- Anything derived from the testnet signature configuration above.
- Missing security headers on marketing pages, absent a demonstrated impact.
- Automated scanner output with no demonstrated impact on this system specifically.
What we especially want
- Anything that lets one participant take another's assets under mainnet rules — that is, where signatures are enforced.
- Consensus safety: two honest nodes persuaded to disagree on a committed block.
- Key handling: recovery, rotation, delegation or multi-signature flows that can be subverted by someone who should not be able to.
- Anything where our public documentation is wrong about what the system does. The gap that produced five duplicate reports was exactly this, and we would rather hear about the next one early.
How we handle reports
We verify every report ourselves, against our own systems, before assessing it — never from a link or attachment supplied with the report. We aim to tell you plainly whether a finding is new, a duplicate, or not a finding, and why.
There is no paid bounty programme at this time and we will not imply that there is. Reports are triaged and recorded; if a programme opens, earlier reports are revisited for eligibility, with credit to whoever reported first.