dapp-acta is the ACTA panel at dapp.acta.build: wallet connection, DID management, vault creation, credential issuance and verification. It is a client of the ACTA API and signs every state-changing transaction with the user's own wallet.

This is a hosted application. Only the version currently deployed to dapp.acta.build is supported — we patch forward and redeploy. Running your own build from an older tag is unsupported.

In scope

• XSS, including through credential fields, DID metadata, or share-link content rendered in the panel
• The panel constructing or displaying a transaction that differs from what the user is asked to sign. This is the highest-severity class here: a user who signs a misrepresented XDR loses control of a DID, a vault, or funds
• Leaking an API key, session token or wallet secret to a third-party origin, into logs, or into analytics
• CSRF on any state-changing route
• Rendering another user's credentials, or a share link exposing more than the fields the holder selected for disclosure
• Bypassing the selective-disclosure UI to reveal undisclosed fields
• Dependency vulnerabilities reachable from the deployed client bundle

Out of scope

• Vulnerabilities in the ACTA API — email acta.xyz@gmail.com, handled under the acta-api policy
• Vulnerabilities in the Soroban contracts — report against contracts-acta
• Anything requiring a compromised wallet extension or a compromised user device
• Self-XSS, or attacks requiring the victim to paste code into a console
• Missing security headers with no demonstrated impact
• Clickjacking on pages with no state-changing action
• Automated scanner output with no verified impact

Rules for testing: use testnet and your own wallet. Do not test against other users' credentials or vaults.

Do not open a public issue for a security report.

Use GitHub's private reporting: Report a vulnerability

Or email acta.xyz@gmail.com with SECURITY in the subject.

Please include the affected route, your browser and wallet, reproduction steps, and what an attacker gains. Screenshots or a short recording help a lot for UI-level issues.

Anything in the transaction-misrepresentation class is treated as critical regardless of how hard it is to trigger.

You will get an update at each stage, and at least once every two weeks while a report stays open.

If we accept it: we fix, deploy, tell you when it is live so you can verify, and credit you however you prefer.

If we decline it: we explain why in writing, and will reconsider if you push back.

We ask for 90 days or until the fix is deployed, whichever comes first. Since remediation is a deployment, this is usually much faster. If we go quiet or miss the timelines above, disclose — we will not object.

• Non-custodial. The panel never holds private keys. Every mutation is signed by the user's wallet through a prepare/submit flow, and on-chain authorization is enforced by the contract's require_auth().
• DID Documents are public by design. They are readable from the chain by anyone. Their visibility is not a vulnerability.
• Credential payloads are encrypted; status is public. That a credential exists and whether it is active, revoked or expired is intentionally world-readable.

This repository is source-available under BUSL-1.1, not open source. You may read it, fork it, and report vulnerabilities against it. Security research is explicitly permitted by the Additional Use Grant.