Arkiv write safety

One authorized account writer submits bounded batches and preserves every known transaction hash. A JavaScript exception does not establish that the chain rejected a write.

Choose and prepare the write

• Validate stable row IDs, payloads and duplicate IDs before any wallet call. Freeze input order and intended fields so receipt keys and readback can be matched to the prepared rows.
• For importing 5,000 rows, use multiple executeBatch({ creates }) transactions with durable per-batch progress. Choose batch sizes from encoded size, gas estimates, provider limits, and an approved spend budget; there is no verified universal 1,000-operation cap.
• One native batch is atomic. The SDK applies creates, patches, deletes, extensions, then ownership changes; property order in the input object does not reorder them. Multiple batches are separate transactions and can leave partial progress.
• Use arkiv-entity-lifecycle for permissions and relationship ordering, arkiv-entity-expiration for renewal calculations, and arkiv-security-trust for signer custody.
• Check configured network, connected account, current permissions, deadline, and GLM balance before submission. Compare an unsigned estimate and fee cap, with a margin, against both balance and approved remaining spend. Estimates spend no GLM, but the provider can still reject balance or fee fields. They do not authorize a funded send.
• Use lowercase MIME types such as application/json. The SDK sorts attribute cells by their encoded names; raw ABI callers must do so themselves. An empty batch throws Error("No operations to perform"); an empty patch throws EmptyPatchError. Skip empty work.
• Keep payload limits separate from total encoded transaction limits: ABI framing, attributes, and every operation add bytes. Do not present a payload limit as the transaction limit.

Nonces, fees, and predictions

Serialize all writes for an account. Promise.all over wallet writes can collide on transaction nonces; a queue in one process cannot coordinate another tab, server, wallet application, or process. Use an account-wide coordinator or exclusive custody when correctness depends on ordering.

The transaction nonce orders Ethereum-compatible transactions. The entity-minting nonce is a separate counter per creator and advances for each create. Pass the creating signer's address as owner in reader.predictEntityKeys({ owner, count }) or reader.predictEntityKeys({ owner, salts }); with salts, their length determines the count. This counter is not getTransactionCount() and does not follow later ownership transfers. Hold exclusive access to every create between prediction and submission, use exactly the predicted salts, and verify receipt keys. An intervening create can invalidate relationships even if transaction nonce allocation was correct.