User wallet
Stores local signing material, presents transaction facts, applies local risk checks, and signs only after user approval.
Signing authority stays with the person holding the wallet.
VelarumPay routes and validates requests, but it does not move private keys to a server or grant merchants and agents the ability to sign user transactions.
Core boundaries
Designed to reduce authority, not hide it.
Security starts by defining what each participant can and cannot do.
Platform API
Authenticates, validates, routes, stores request state, applies policy, and synchronizes status. It does not sign for users.
Merchant or agent
Creates requests and reads permitted status within scoped access. It cannot export keys, approve, or sign.
Controls
Layered around the request lifecycle.
No single label makes a payment safe. The product combines local key custody, deterministic validation, limited connections, and explicit user review.
Local key custody
Seed phrases, private keys, and derived signing material remain on the user's device.
Approval by default
Real payments require the wallet user to review and approve before local signing.
Scoped connections
Connections receive limited, explicit capabilities and can be revoked.
Expiry
Requests and invitations have time boundaries and cannot remain silently actionable forever.
Idempotency
Creation retries are designed not to produce duplicate payment requests.
Status history
Request state and events support diagnosis without giving observers signing power.
Truth before presentation
Chain facts cannot be overridden by marketing copy.
A transaction context can explain a purchase. It cannot change the network, asset, amount, recipient, contract or issuer, memo, or fee being reviewed.
01
Immutable payment factsNetwork, asset, amount, recipient, contract or issuer, memo, and fee
02
Separate transaction contextReason, evidence, order details, and agent activity
03
Visible mismatch riskConflicting claims are a reason to stop, not a reason to reinterpret facts
Preview limits
Security architecture is not a release certificate.
The Preview remains subject to device testing, deployment exercises, license review, legal review, and release evidence.
Use test and explicitly enabled paths onlyDo not infer production safety, regulatory availability, network support, asset support, or audit completion from this website or a protocol example.
For wallet users
- Never share a recovery phrase or private key.
- Verify the exact recipient and network.
- Reject unexpected or urgent requests.
- Use only capabilities shown as supported in your build.
For integrators
- Keep tokens out of client logs and source code.
- Request the minimum scopes needed.
- Use exact amount strings and idempotency.
- Do not place private or signing material in metadata.
Found a security concern?
Do not include secrets or sensitive user data in the first message. The coordinated disclosure process remains part of Preview readiness.