MantisMesh
PUBLIC PAID ACCESS ENABLEDView status ↗
MantisMesh / Security

Ownership, encryption, and explicit expiry

Understand MantisMesh wallet authentication, operator-managed encryption, delete-after-read behavior, retention limits, quotas and operational boundaries.

A clear trust model

Your wallet controls access.
The service manages encryption.

Your state is encrypted before storage. MantisMesh decrypts it for authorized requests and manages the encryption keys. This is not end-to-end encryption.

Prove control. Share no wallet secrets.

Authentication uses a one-time Solana Ed25519 challenge signature, followed by a one-hour bearer session. Challenges expire after five minutes. Your wallet’s seed phrase and private key are never required by the service.

Checkpoint access is authorized against the owner wallet. Handoff snapshots are retrievable by the specified recipient wallet, not every agent that knows an object ID. Treat bearer sessions as sensitive credentials.

Encrypted before storage.

MantisMesh uses authenticated AES-GCM encryption for stored payloads. Encryption binds payloads to their object and wallet context. HTTPS is required for the public API, with TLS served through Cloudflare. Application logging does not emit plaintext submitted payloads.

Know the boundary. The service can read payloads to fulfill authorized requests. If your application needs confidentiality from the service operator, apply your own client-side encryption before submitting state.

Expiry is part of the contract.

Choose 1h, 24h, 7d or 30d retention. Access checks enforce expiry; scheduled cleanup removes expired records in bounded batches. Physical deletion can lag while a backlog drains.

Delete-after-read atomically claims a payload. An encrypted replay copy may remain for up to five minutes, or until the earlier object expiry, so the same wallet and operation key can recover a lost response. Other operation keys cannot reread it.

Backups have their own retention. Delete-after-read does not promise immediate erasure of every ciphertext copy from backups.

Bounded by design.

BoundaryLimit
Checkpoint payload64 KB of UTF-8 JSON, including serialization
Active checkpoints per wallet500
Active locks per wallet50
Maximum retention30 days
Protected requests per wallet120 / minute
Authentication attempts per IP20 / minute

Keep operational authority separate.

The API uses only the public operational receiving address. Operational and treasury wallet private keys are not held by the service. Moving funds to a treasury is a separate operator action, not an automatic service capability.

Recovery callbacks require a reviewed HTTPS origin, a signing secret and recipient verification of signatures/replays. They are at-most-once delivery attempts, not guaranteed job execution. Locks coordinate logical access but do not provide fencing tokens.

Retain payment receipts and original operation keys when a settlement is uncertain. A timeout does not establish that a payment failed, and a new payment must not be sent automatically.

Review the API contract