Data Storage

How data is stored and persisted in Logbook.

#On-Chain Data

All campaign and response data is stored directly on the Sui blockchain.

#What's Stored

Campaign Data:

• Title, description and all questions with options (plaintext for open campaigns, encrypted otherwise)
• Commitments (hashes) to the files the campaign is about; the files themselves are stored off-chain
• Who can participate and who can read answers
• The address list (address-list campaigns)
• Creator address, the nonce the campaign id is derived from, and timestamps
• Who paid the gas of the creation, if anyone
• The content version (grows with every edit) and the access epoch (grows when an address leaves the list)
• The encrypted campaign content key; for password campaigns also the key wrapped with the password and the public key that checks proofs of the password

Response Data:

• Respondent's address
• Answers: plaintext when answers are public, otherwise an encrypted blob
• The access epoch the answers were encrypted for
• Password campaigns: the respondent's own copy of the content key, sealed for them
• Submission timestamp
• Transaction ID

#Data Persistence

On-chain data is:

• Permanent: Exists as long as the blockchain exists
• Immutable: Cannot be changed after writing
• Public: Anyone can read the bytes; private content is readable only with the right keys
• Verifiable: Cryptographically provable

#Off-Chain Data

Some data is stored locally for functionality:

#Browser Storage

localStorage (stays in your browser; signing out removes the sign-in data, the stored campaign passwords and the AI assistant's conversation):

• zkLogin identity (address, email, provider)
• zkLogin session data (JWT token, ephemeral key and its ZK proof)
• User preferences (theme, language, currency, date/time format)
• Last connected wallet
• Passwords of password-protected campaigns you created or opened while signed in, kept for that account
• AI assistant conversation (until you publish the campaign, clear the chat or sign out) and its settings
• Gas price cache

sessionStorage (this tab only, cleared when the tab is closed):

• The campaign form you are filling in, with its address list, kept over a reload or a sign-in and emptied after publishing
• Campaign passwords of a signed-out visitor: they last as long as the tab. When the visitor signs in in that tab, the password becomes the account's and leaves the tab's storage; other accounts, other tabs and later sessions never see it
• Campaign content keys and Seal session keys (valid for 15 minutes)
• Answers you are filling in, kept while you sign in
• Navigation state (return URLs, scroll positions)

This data is:

• Local to your browser
• Not shared with servers
• Content keys can be recovered by signing a message with your wallet or Google account (Seal)

#Logbook Servers

Logbook has no application database. Files a campaign is about, and documents about a campaign (the AI Analytics report and the results certificate), are stored on Walrus; the campaign object holds the pointer and the SHA-256 of the file, set by a creator-only contract function. Logbook's server keeps a cache copy as a fallback for when Walrus is unavailable; a file uploaded but never recorded on-chain is deleted from the cache after two days, and cache copies are always served as downloads. The cache needs no trust: readers verify every file against the on-chain hash, and documents of private campaigns are encrypted before they leave the creator's browser.

Besides that cache, Logbook's servers (Cloudflare storage) keep only daily quota counters (per sender address, per IP address, with IPv6 per /64 and per /48, and per API key; they expire after two days), integrator API keys (hashed), and the sessions of apps connected through the remote MCP connector, with their signing keys encrypted. The ticket that links the two steps of gas sponsorship is not stored: it is a signed receipt that the server checks again.

#How long files are kept

The blockchain is permanent; file storage is not. Walrus storage is rented for a period, and Logbook pays for it, so documents are kept for a stated minimum time: at least 50 days after publishing during the Testnet beta (about a year is planned for mainnet). The period is shown before you publish a document and next to every published document. After it the file may no longer be available.

What never expires is the on-chain record: who published the document, when, and the SHA-256 of the file. That is why a copy you keep stays verifiable forever: drop it on the verification page and it is compared with the hash on-chain, with no storage involved. For private campaigns download the original (encrypted) file and keep the verification link; together they can be verified and read at any time. Publishing a document again starts a new period. (During the beta the chain is Sui Testnet, and a Testnet reset removes on-chain records too.)

The votes themselves never depend on this: they live on Sui.

#Data Lifecycle

#Campaign Creation

1. 1Form data kept in the tab (Zustand, saved in sessionStorage so that a reload or a sign-in does not lose it)
2. 2On deploy, sent to blockchain
3. 3Campaign object created on-chain
4. 4Local form data cleared

#Response Submission

1. 1Answers selected in UI
2. 2Answers encrypted in the browser, unless they are visible to everyone
3. 3Transaction built and submitted to the blockchain
4. 4Response object attached to the Campaign
5. 5Vote counts updated atomically (public answers only)

#Data Retrieval

1. 1Campaign ID requested
2. 2Sui full node (gRPC) and indexer (GraphQL) queried
3. 3Campaign object returned
4. 4Data parsed and displayed

#Encryption

Everything is encrypted and decrypted in your browser (with the SDK or the local MCP server, on your own machine); the smart contract and Logbook's servers only ever see ciphertext. There are two exceptions:

• AI Analytics: if the creator runs it on a campaign whose answers are not public, they are asked first, and can send the individual answers (without addresses) or totals only. What they send is decrypted in their browser and passed to the AI provider to produce the report. The saved report is encrypted again before it is stored on Walrus
• The remote MCP connector: an app connected at logbook.zone/mcp with a Google account reads private data through Logbook's edge servers, which decrypt it for that account. The SDK and the local MCP server decrypt on your machine instead

#Campaign content

For campaigns that are not open to anyone, the title, description, questions and options are encrypted with a random 256-bit content key (AES-256-GCM). Each text is padded before it is encrypted (to 32, 64, 128 or 256 bytes, then to a multiple of 256), so the length of a ciphertext says little about the text: "Yes" and "No" look alike. Campaigns created before padding was added keep their unpadded texts, which still open.

• With password: the password is derived from the content key (HKDF), and the content key is wrapped with the password (PBKDF2 + AES-GCM) and stored on-chain. A second key derived from the content key signs the proofs of the password that the contract checks (ed25519; each proof names one address). The password travels in the share link after the #, which browsers never send to servers. The content key is also Seal encrypted for the campaign: the creator recovers it, and with it the password, by signing a message, and each respondent keeps a copy sealed for their own address.
• Address list: the content key is Seal encrypted for the campaign. Key servers release it to addresses on the list and to the creator.

#Answers

• Everyone: plaintext on-chain, validated and counted by the contract.
• Everyone with access (password campaigns): AES-256-GCM under the content key.
• Voters only, Only me, After the end date, and Everyone with access on address-list campaigns: Seal encrypted objects. Every identity starts with the campaign id. "Voters only" and "Everyone with access" answers are encrypted for the campaign's current access epoch, which grows when an address is removed from the list; "Only me" and "After the end date" answers are encrypted for their respondent. The contract decides who may decrypt what (see Smart Contract).

Every encrypted answer is bound to its campaign and respondent (as authenticated data) and padded to a multiple of 256 bytes, so its length says little about the choice. An answer copied from another respondent fails that binding and is never counted.

#Documents

For private campaigns the files a campaign is about are encrypted in the creator's browser with the content key, and the on-chain hash is salted (see Creating Campaigns). Each file is padded before it is encrypted (to a power of two of at least 4 KiB, up to the upload limit): the chain holds the padded size and an empty type, and the real name, type and size are encrypted together with the content key and bound to the file's commitment. An outsider sees neither the exact size nor the type of a private document, and the verification page says when a size is hidden. Documents attached before this was added (format v1) show their exact size and type on-chain, with only the name encrypted.

#Reports

An AI report or a results certificate of a campaign that is private, or whose answers are not public, gets its own random key (AES-256-GCM), protected like the results it summarizes. When the answers use Seal, the key is sealed for whoever may read the results; otherwise (public answers on a campaign with encrypted content, or everyone with access on a password campaign) it is wrapped with the content key. On address-list campaigns where everyone with access reads the answers, the key is sealed for the current access epoch, so an address removed from the list cannot read a report made after its removal. Reports of open campaigns with public answers are stored in plaintext.

#Seal in short

Seal is identity-based threshold encryption for Sui. A committee of independent key servers (2 of 3 on testnet) holds the master keys. To decrypt, your browser signs a short-lived session message, and each key server simulates the contract's seal_approve function for your address. Only if the policy passes does the server return its key share. Keys you have fetched are cached for the session.

#Key Storage

#Privacy Considerations

The Terms & Privacy page summarizes who can read what and what is stored where; the details follow.

#What's Public

• All responses linked to blockchain addresses
• Who responded and when (addresses and timestamps)
• Vote counts and aggregations when answers are visible to everyone
• Campaign content and questions (encrypted unless the campaign is open to anyone)

#What's Private

• Real identity (unless you share your address)
• Email (not stored on-chain with zkLogin)
• IP addresses (not logged; daily quota counters are kept per IP address, IPv6 per /64 and per /48, and expire after two days)
• Answers of campaigns with restricted visibility (encrypted; only readers allowed by the visibility rule can decrypt)

#Pseudonymity

Your blockchain address is a pseudonym. It's linked to your responses but not directly to your real identity. However:

• If you share your address, responses are linked to you
• zkLogin addresses are deterministic from Google accounts
• Pattern analysis could potentially de-anonymize