# Privacy and data handling

Updated: 2026-10-19. https://tronhooks.com/docs/privacy/

This notice describes the data handled by tronhooks.com. Contact [ops@tronhooks.com](mailto:ops@tronhooks.com) for questions, access requests or account deletion. Do not send passwords, API keys, webhook secrets or wallet recovery phrases.

## Data and purpose

| Data | Purpose |
|---|---|
| Email or wallet login identity, password hash where applicable, sessions and verification records | Account access, recovery and abuse prevention |
| Signup IP and signup source | Abuse prevention and acquisition measurement; missing attribution remains unknown |
| Watched public addresses, asset/direction settings, webhook URLs and Telegram chat binding | Match transfers and deliver the alerts you configure |
| API key hashes, encrypted webhook signing secrets | Authenticate requests and sign outgoing webhooks |
| Matched chain events, delivery attempts and error/status records | Delivery, retry, reconciliation and support |
| Web request paths, query parameters, referrer, user agent and hashed access-log IP fields | Operational diagnostics and aggregate funnel analysis |

Wallet private keys and recovery phrases are never required. A public address and its transactions are not secret, but linking them to an account is account data. Do not put credentials or sensitive personal information in URL parameters. Aggregate analytics are not a record of every user's full browsing history.

## Service providers and destinations

Email verification/recovery uses the configured email provider (Resend). Telegram receives messages for watches you connect. Your webhook receiver receives the transfer payload you request. Hosting and backup storage process service data for operation and recovery. There is no third-party advertising tracker in the public pages; normal network requests still create server logs.

## Retention and deletion

Account, watch and credential records remain while needed to operate the account. Deleting a watch stops new matching and deletes its notification records and delivery-attempt history through database cascades. Underlying matched-chain-event records can remain. A delivery already in progress may still complete. Retention tooling supports deleting delivered events older than 90 days and attempts older than 30 days, but its default mode is **dry-run**: those values must not be read as guaranteed automatic deletion deadlines. Pending/dead-letter notification records are retained by that cleanup. Delivery-attempt history older than 30 days can be removed even when its parent notification is pending or dead-lettered.

Access logs rotate subject to age, size and file-count limits; historical coverage can be shorter than the reporting window. Backups are rotated separately (configured targets: local 14 days, off-site 30 days). Account deletion requests require identity verification and operator processing; backup expiry is separate from deletion in the live database. Ask support for the scope and expected completion of your request. No universal immediate-erasure promise is made.

See [security](/docs/security/) and [service terms](/docs/terms/). This notice describes current handling; material changes will be reflected here.

Daily growth snapshots retain aggregate counts and fixed source/page categories without account identifiers, address, visitor hash, or raw URL. These aggregate snapshots have no automatic expiry.