Skip to main content
LumenWipe is non-custodial and keeps no record of who closed which account. The API’s logs follow from that: they exist to find and fix failures, and they are written so they cannot be used to reconstruct a close.

​
Request ids

Every API response carries an X-Request-Id header, and every error body repeats it as error.requestId. The id is generated by the API for each request; a value sent by the caller is ignored. The web app shows it as a reference beside a failed close, and @lumenwipe/sdk exposes it as LumenWipeApiError.requestId. Quote it when you report a problem: it is the key to the one log line written for that request.

​
What is logged

The API writes one JSON object per line to standard output. Cloud Run forwards each line to Cloud Logging, which reads the severity field to classify the entry (DEBUG, INFO, WARNING, ERROR or CRITICAL). Each request produces one line when its response is sent: Failures inside a request add lines with a message, the error’s stack and the same requestId. The service also logs its own start-up and degraded-dependency messages.

​
Key lifecycle lines

Creating, rotating or revoking an API key, through the operator API or through a wallet session, writes one more line from the audit logger, success or failure: Notes:
  • The operator API is protected by one shared token, so actor cannot say which operator acted; it is always admin.
  • Wallet addresses in actor and owner follow the address rule below: first four and last four characters plus a keyed hash. The hash matches an actor across lines only while LOG_HASH_KEY is the same; without it each instance and each restart uses its own random key, so stable correlation across instances requires setting LOG_HASH_KEY.
  • The owner label on the operator API is free text. Do not put personal data in it.
  • A rejected operator token, a missing wallet session and an invalid request body are not lifecycle actions and get no such line; the request’s access line records them.
  • The raw key, the full key hash and session or operator tokens are never written.

​
What is never logged

  • Request or response bodies.
  • Memos and deposit tags.
  • The destination of an exchange close. Any address that belongs to a listed exchange is written as the fixed token [exchange], with no prefix, suffix or hash.
  • Secret keys, bearer tokens and signed transaction envelopes.
  • Client IP addresses. The platform’s own request log is the only place an address is recorded, under the platform’s own policy.

​
How addresses appear

Any other account address that reaches a log line is cut to its first four and last four characters, followed by a short keyed hash, for example GABC...WXYZ~1a2b3c4d. The hash lets two lines about the same address be matched without storing it, and it cannot be reversed to the address. It is derived with a key held by the operator, so it means nothing outside the deployment that wrote it.

​
How the policy is enforced

The rules are applied where lines are written, not left to each call site. Before a line leaves the process, the logger replaces secret-shaped strings, bearer tokens, long encoded blobs and full addresses as described above, and removes any memo the request itself carried, including one inside a signed envelope. Route patterns are logged instead of paths so that addresses in a URL never reach the line. Automated tests run a close that fails at every step and assert that no full address, memo, secret-shaped string or body appears in any line.

​
Retention and access

Logs go to standard output, Cloud Run forwards them to Cloud Logging, and retention is that log bucket’s setting. The default bucket keeps entries for 30 days unless the operator changes it. Reading them requires logging permission on the Google Cloud project that runs the API; nobody else, including API integrators, can read them.