Arkiv security and trust

Treat payloads, attributes and transaction calldata on the public Arkiv network as public. Encryption can protect payload contents; Entity Expiration or deletion cannot retract bytes another party has already read. Do not promise permanent archive access or secure erasure.

Before storing data

• Identify sensitive payload fields, indexed attributes, wallet addresses and logs. Store secrets off-chain or encrypt payloads with an independent, privately backed-up key. Do not put private labels in attributes; they remain queryable in clear.
• Keep access/signing/encryption keys out of chat, URLs, logs, browser bundles and NEXT_PUBLIC_*. If a user pastes a private key, do not use or repeat it; direct them to replace the exposed credential and configure the replacement locally through their secret store.
• Choose who signs and owns entities, who can change the current contents, who may decrypt, and what recovery/key rotation means. Successful decryption does not establish publisher identity or application authorization.
• Evaluate readonly and permissionlessExtension at creation. Flags cannot be changed later. Readonly prevents payload/attribute edits, while ownership transfer, deletion and expiry extension remain possible. Permissionless extension lets third parties keep an entity live; do not rely on expiration as privacy enforcement.

Read privacy.md for encryption, equality-index design and expiration limits. Use arkiv-encryption for the published payload-encryption API; HMAC indexes and access-gating services are separate designs, not that package's API.

Trust a publication, not a namespace