Frequently Asked Questions

Where is the data stored?

Arkiv data lives on Layer 3 DB-Chains. A DB-Chain is an application-specific blockchain tailored for structured and unstructured data storage and retrieval. Users manage and access entities through familiar CRUD operations (create, read, update, delete) exposed via RPC.

Storage is priced in GLM and calculated from data size, expiry time, and current storage load. Once an entity's expiration passes, it is removed from the active, queryable state of the DB-Chain.

Where is the compute coming from?

Arkiv runs on a 3-layer stack. The actual compute happens at L3, which is a modified version of op-geth (the OP Stack execution client). Today the network runs on OVH Europe.

What is the to: address on the tx confirmations?

The to: address on transaction confirmations is the L3 system contract that processes entity operations. When you submit a transaction through the SDK, it gets sent to a system contract on the L3 chain that handles parsing and executing the typed operations (createEntity, updateEntity, etc.). The address is a system-level entry point owned by the protocol. Think of it as the entry point for all Arkiv operations on the DB-Chain.

What is the roadmap for self-hosted nodes?

This is something we care about deeply because it directly touches web3 self-sovereignty and permissionlessness. The principle is: reads are free via public RPC, and if you need more, you can always run your own node.

Right now we are still in testnet. The plan is to allow self-hosted nodes and DB-chains as soon as we can. Bear with us on exact timelines here. We don't want to promise dates we can't hit.

What are the tokenomics?

This was a big discussion. Here's where we landed: GLM (Golem Network Token) is the payment token. We are using GLM instead of launching a new token.

At some point we'll enable AA and smart accounts to make this seamless.

The foundational pricing model is gas-based. You pay for what you use: storage (size x duration) plus compute (per operation).

What alternatives are there and how do they stack up against Arkiv?

This is a question we've spent a lot of time on. The honest answer is: the landscape has shifted significantly. Tableland and Ceramic merged into Recall Labs and pivoted to AI agent infrastructure. Here is how the field looks right now.

What makes Arkiv different:

• Time-scoped storage economics. You pay bytes x duration. Nobody else does this. Most charge perpetual storage or per-query. For anything with ephemeral data (gaming sessions, marketplace listings, social posts), this is a fundamentally better model.
• Ethereum-native alignment. Built on OP Stack, anchored to Ethereum. Space and Time has their own L1.
• Data ownership as a primitive. Every entity has an on-chain owner.

How does editing / deletion work?

Pretty straightforward, actually.

Editing: updateEntity takes an entity key and replaces the entire entity atomically. It is a full replacement that preserves the entity key.

Deletion: deleteEntity removes the entity from the SQLite DB and query index. After deletion, the entity returns 404 when queried.

The nuance: data stored in the DB-Chain also remains in the transaction history (including the fact that the entity existed, what it contained, and when it was deleted). You can prove "entity E existed at block N" even after deletion, though you would need to rebuild the state up to that point. Deletion removes an entity from the active, queryable state while leaving the historical record intact.

Only the owner can edit or delete. This is protocol-enforced.

Is this like a non-relational database?

Sort of, though we wouldn't call it that exactly. It's its own thing.

Arkiv has a fixed entity schema (rather than user-defined tables). Every entity has the same structure: key, owner, payload, attributes, expiration. The payload is a blob, and the attributes are indexed key-value pairs you can query against.

Arkiv sits between relational and traditional NoSQL. There are no tables, joins, foreign keys, or SQL for writes, and no document store semantics either. The closest model is a structured key-value store with queryable indexes and ownership semantics.

The mental model we'd suggest: think of it as owned database rows with built-in expiration. The "rows" here are structured, queryable data units with a fixed shape that you don't define yourself.

How could privacy / encrypted data work on Arkiv?

This is something we're still thinking through. Here is the honest current state.

All entity data is public. Nothing stops you from encrypting the payload before storing it. The protocol treats the payload as a bytes blob. Some options:

• Client-side encryption: encrypt your payload before calling createEntity. Store the encrypted blob. Only people with the decryption key can read the actual content. The entity metadata (owner, timestamps, attributes) remains visible, while the payload itself is opaque.
• Attribute-level encryption: encrypt sensitive string attributes while keeping non-sensitive ones in plaintext for querying. You lose the ability to query on encrypted attributes (unless querying for exact match).
• Integration with access control protocols: something like Lit Protocol (we haven't tried it ourselves) could manage decryption conditions.

The tradeoff is clear: the more you encrypt, the less you can query. Encrypted payloads are just blobs. You can't filter on content you can't read.

A proper privacy layer (something like ZK-based access control) would be significant research. We haven't specced this out. If there is enough demand, it's worth exploring.

If we all share a space ID, couldn't this be an easy attack vector?

Good question. The short answer is: no. A spaceId is an application-level convention rather than a protocol-level trust boundary. It is a string attribute that apps use to isolate their data when querying. It acts as a filter. The actual security lives at the entity ownership level.

Why sharing a spaceId doesn't create a meaningful attack surface:

• Write access is owner-only. Even if someone knows your spaceId, they can't modify or delete your entities. Only the entity owner can do that. Protocol-enforced.
• Read access is public anyway. All data on Arkiv is publicly readable regardless of spaceId. Knowing the spaceId doesn't give you access to anything you couldn't find otherwise.
• Spam within a space. Could someone flood a shared spaceId with garbage entities? Technically yes, though they're paying gas for each entity they create. The economic cost of spam makes it impractical at scale.

The thing to watch for is at the application layer: if your app naively trusts all entities in a spaceId without verifying ownership, that is an app-level bug. The protocol itself remains sound. Your app should always verify entity.owner matches expected addresses.

What is the max size of payload that Arkiv can handle?

Straightforward, with a caveat: the formal size limit as of now is 116KB.

In practice, Arkiv is designed for structured data. Think user profiles, marketplace listings, social posts, credentials. Large media (videos, images, documents) should live elsewhere.

The recommended pattern for large files: store the file on IPFS or Arweave, and store the CID / reference as an entity attribute on Arkiv. Nothing prevents you from chunking files and rebuilding them at the application layer, though this is outside the intended use case.

What is the max TTL allowed? Is there a limit?

Every entity has a mandatory expiration (expiresAt), expressed in block numbers. You set it via expiresIn (in seconds) when creating or extending an entity.

Is there a max? Not formally specified yet. You could theoretically set a very long TTL (years), though there are economic implications: you are paying size_KB x duration_days x STORAGE_RATE upfront. Longer TTL means proportionally higher cost. The pricing model naturally disincentivizes extremely long durations without needing a hard cap.

That said, there should probably be a protocol-level max TTL to prevent edge cases. We will think about this one before going to mainnet.

One important nuance: after expiry, entities are removed from the queryable database, while the historical data remains on the transaction history. So expiry doesn't mean the data is "gone gone" from the universe, only from the active queryable state. Reactivation is unavailable: once an entity is gone, if you want it back, you need to re-create it.

What are the costs? What will they be when on mainnet?

We're still actively working on this, so here is the formula and where our heads are at, instead of final numbers.

The goal is to be competitive while staying realistic about the product category. Arkiv is different from a traditional database. You are paying for storage and compute, and also for ownership guarantees, tamper-proofing, and cryptographic verifiability. The pricing reflects that. We don't think it's fair to compare us dollar-for-dollar against Firebase or Supabase, because those don't give you any of the web3 guarantees. At the same time, we're not trying to charge "blockchain premium" for the sake of it.