Your wallet key does not belong on this server.
Veliox is designed around a simple boundary: cloud automation can gather evidence and recommend. Wallet authority stays with the user.
No signing key field
The app configuration accepts model and data-provider credentials, not a EVM seed phrase or private key.
Fail closed
Bad JSON, timeouts and request errors are treated pessimistically. The checker does not silently pass failed analysis.
Code-owned brakes
Position size, daily loss and trade limits are enforced by deterministic code, not model instructions.
Responsible disclosure
Do not post live credentials, private wallet material or exploit details in a public issue. Report a vulnerability privately to the configured security contact. Include affected version, reproduction steps, impact and whether any secret or personal data may have been exposed.
Deployment hardening
- Terminate HTTPS before public traffic reaches the application.
- Use rate limiting and request-size limits at the reverse proxy.
- Run containers as a non-root user and mount configuration read-only.
- Keep provider keys server-side and rotate them after any suspected exposure.
- Restrict the approval API to trusted users or a private network in a commercial deployment.
- Review logs before sharing them publicly.
What this project does not claim
No software can eliminate rugs, MEV, provider outages, stale data, market gaps, model error or economic loss. Security controls reduce specific failure modes. They do not make speculative token trading safe.
