Security posture.
The trust boundary for transaction assurance: key handling, authenticated access, encrypted communication and decision evidence.
Transaction signing boundary
TXShield assesses proposed transactions before signing. It does not hold your private keys, sign your transactions or replace your custodian. Your existing custody, MPC or HSM infrastructure retains signing authority; your systems enforce the returned transaction decision.
Responsible disclosure
Found something? Tell us first.
- security@txshield.dev
- security.txt
- /.well-known/security.txt
- Severity
- Mark
[CRITICAL]in subject for anything that exposes customer data, lets a third party act as a customer, or could change a transaction decision. - Bounty
- Negotiated case-by-case. We don't run a points-based program, but we pay for real findings.
Please do not use customer data, run automated scanners against production, or test on accounts that aren't yours. Use a free-tier sandbox key for everything.
What we do today
Encryption
API keys stored only as salted hashes, never in plain text. All traffic TLS 1.2+ (TLS 1.3 preferred). Webhook payloads signed HMAC-SHA256 with per-endpoint secret.
Key rotation
You rotate API keys from the dashboard at any time.
Isolation
API keys, risk policies and audit records are scoped to the owning account.
Logs & audit
On the institutional tier each simulation writes a signed, append-only audit record. sim_id is the stable join key — quote it on any support request.
Compliance
- GDPR (EU) — DPA available on request. We are the data processor; the customer is the controller for any wallet/tx data their users submit.
For a security questionnaire, architecture diagram or sub-processor list, email security@txshield.dev from a corporate domain.
Sub-processors
- LeaseWeb (NL-AMS) — primary compute
- Helius — blockchain network access
- Stripe — billing
- Resend — transactional email