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 and timestamps
• The encrypted campaign content key

Response Data:

• Respondent's address
• Answers: plaintext when answers are public, otherwise an encrypted blob
• 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; sign-in data is removed on logout):

• zkLogin identity (address, email, provider)
• zkLogin session data (JWT token, ephemeral keys)
• User preferences (theme, language, currency, date/time format)
• Last connected wallet
• Campaign passwords of password-protected campaigns you created or opened
• AI assistant chat draft (until you publish the campaign or clear the chat) and settings
• Gas price cache

sessionStorage (cleared on browser close):

• Campaign content keys and Seal session keys (valid for 15 minutes)
• ZK proof cache
• 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. 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.

#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.

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

#Data Lifecycle

#Campaign Creation

1. 1Form data stored in Zustand (memory)
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; the smart contract and Logbook's servers only ever see ciphertext. The one exception is AI Analytics: if the creator runs it on a private campaign, the decrypted answers are sent to the AI provider to produce the report. The saved report itself is encrypted again before it is stored on Walrus.

#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).

• With password: the content key is wrapped with a random password (PBKDF2 + AES-GCM) and stored on-chain. The password travels in the share link after the #, which browsers never send to servers. The key is also Seal encrypted for the creator, so you can recover it by signing a message.
• Address list: the content key is Seal encrypted for the campaign. Key servers release it to addresses on the list.

#Answers

• Everyone: plaintext on-chain, 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. The identity of each object encodes the campaign and, for "Only me" and "After the end date", the respondent, so the contract can decide who may decrypt what.

#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

#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)
• 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