You read one feed covering deposits, withdrawals, movements, agent actions, approvals and security events, grouped by month with money-in and money-out subtotals. Export it as a CSV statement from the filters you applied, or as an evidence bundle carrying the protocol receipt bytes and the hash-chained audit log for your account. A third party runs verify_export and rewalks that chain without the service, so truncation, reordering or alteration is refused rather than served quietly.

What it does

The Paxeer X account app keeps one activity feed covering deposits, withdrawals, movements, agent actions, approvals and security events, and lets the account holder export it two ways: a CSV statement, or an evidence bundle carrying the exact protocol receipt bytes behind each row. Every consequential action is also appended to a per-account hash-chained audit log, and that chain exports as its own independently verifiable bundle. Notifications cover nine event classes across push, email and in-app, with per-class toggles nested under each channel and a detail level that bounds how much financial detail the content carries.

Key capabilities

• One feed over six activity kinds, grouped by month with money-in and money-out subtotals.
• CSV statement export from the same filters the feed applied, row per activity entry.
• Evidence bundle export bound to the account and the Paxeer settlement domain.
• Hash-chained audit log per account, exportable and verifiable without the service.
• Nine notification classes across push, email and in-app, with per-class toggles.
• In-app notifications grouped by recency, deduplicated, with deep links to the exact surface.

Differentiators

The evidence bundle verifies offline: verify_export re-walks the chain from a genesis link derived from the account identifier, recomputes every entry link, and checks each referenced evidence row against the digest the entry bound, with no service store and no trust in the producer. The "receipt-verified" label cannot be forged by calling code. The verdict field is private and its only constructor consumes the verifier's own typed result.

Outcomes

• Download a statement that matches the filters you applied
• Hand over evidence a third party checks without trusting the service
• Tune nine notification classes across push, email and in-app

Technical notes

• Operations: POST /v1/activity/query, GET /v1/activity/{entry_id}, POST /v1/activity/exports/statement, POST /v1/activity/exports/evidence, GET /v1/notifications, POST /v1/notifications/{notification_id}/read, and GET/POST /v1/notifications/preferences. Both export operations are idempotent.
• Limits: page size is capped at 100 entries; an export is built with an explicit finite byte bound and refuses anything above 64 MiB. Statements are text/csv; charset=utf-8 with the header entry_id,kind,status,occurred_at,projected_at,verification,receipt_references; bundles are application/vnd.layerx.evidence-bundle.
• Completion states are receipt-gated. Done, Done, finalised, deposit Done and withdrawal Paid out are only reachable through a verified receipt; the pending status type cannot express them. A refusal always states whether money left the account.
• Every feed response, including an empty page, carries freshness: projection time, age in seconds, the configured freshness bound, the observed agent head and the lag against it.
• Verification labels are exactly three: receipt-verified, unverified and unavailable. An unverified row names its reason: tampered, digest-mismatch, principal-mismatch, settlement-domain-mismatch or authority-mismatch.
• Failures carry a stable code, a copy-catalog key, a retriability class (retriable, retriable-after, structural or final) and the envelope trace identifier, so nothing is swallowed. The notification.preferences.set refusal for a fully suppressed security class is specified in the contract and in the copy catalogue but is not yet returned by the handler, which stores the preference and falls back to in-app delivery instead.
• Reads behind these views come from the kernel projection and history index. A history query returns at most 4096 results, and a projection behind its source returns a typed stale error rather than a silent stale read.

More in Interface