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, and so are groups and memberships.

#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

Group Data:

• Name, description and card form (plain text for a public group, encrypted for a private one)
• The addresses of the owner and the admins, appointments that wait and an offer of the ownership
• How people join, whether joining is open, who counts once, whether a card is required
• The fingerprint of the list (one hash for the whole list), where its published form is stored, and the hash of the admins' encrypted copy
• The parent group, the groups under it and the requests to link
• Invitation links: the public half of each link's key, its limit, its last day and how often it was used
• Applications: the applicant's address, the encrypted text and the encrypted card
• The campaigns that reach the group

Membership Data (kept in the group's member shards):

• One record per address that ever joined: when each membership began and ended, the way of joining, and whether an admin ended it. A record is never deleted
• Member cards, encrypted
• For a community with a list: which address holds which seat (the seat's id is a salted hash, not its name)

#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, the AI assistant's conversation and what was kept for the account about groups):

• 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
• Groups, kept for the signed-in account: the draft that prefills your member card when you join a new group (Account, My data); the ids of the groups this browser saw you act in; the seats you took from it
• Groups, for an admin, kept for the signed-in account: the invitation links made in this browser with the names you gave them (the chain keeps only the public half of a link, so the link can be copied again only here, while you stay signed in), and the encrypted copy of a list you opened or wrote, with a draft of one being rebuilt
• Groups, for anyone: the published form of lists this browser met (one fingerprint per seat, public data)

Signing out removes everything kept for the account about groups, the invitation links included: copy a link you still need before you sign out, or revoke it afterwards and make a new one. The same happens when another account takes the place of yours in this browser (another wallet account, or a wallet instead of the Google account). Nothing kept for one account is read under another. The published form of lists stays. A Google session that ends by itself removes nothing: you sign in again and find what you kept

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 database of campaigns, responses or members: those are on the blockchain. Two more things are kept with the secret-ballot mode and community addresses, in Cloudflare D1 databases. The vault: for each account, its seed for the addresses it has in communities, sealed for the key servers under that account, and its encrypted list of those communities; kept without a time limit, until the account moves it away: on the Account page it can be kept on the person’s own device with a file instead, and Logbook’s store then deletes its record and keeps a mark that it was moved (a fingerprint of the sealed seed), so that nobody makes another record in its place (what Cloudflare can restore of the database stays for up to 30 days). The relayer’s queue: each ballot handed to the relayer (the box, the part, the ballot’s number, the sealed answers, the proof), from the moment it arrives until it is recorded, at most until its vote ends. The row holds no network address. It holds the fixed time of the ballot’s batch, which is the start of a half hour, and whether the ballot came in the last half hour before the end of its vote: so the half hour in which a ballot arrived is in the row, and the moment within it is not. Per campaign and per day the relayer also keeps how many ballots it paid for and what they cost. Cloudflare can restore a D1 database to any minute of the last 30 days (7 on its free plan), so a deleted row, and the minute it first appeared, can be brought back by whoever has the Cloudflare account until that time has passed. The relayer writes no log line for a request. For two days it keeps a counter per network and day, under a name made from the network address with a secret that changes daily: what that network wasted (a ballot whose proof does not verify, a request that is not a well-formed ballot), in all and for each vote. A network that wasted nothing has no counter. What Cloudflare itself logs of each request (network address, path, time) is its own, as for every page.

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 and the files of the lists of groups (below), Logbook's servers (Cloudflare storage) keep, besides the vault and the relayer’s queue named above, daily quota counters (they expire after two days and are deleted with the next request after that), integrator API keys (hashed), and the sessions of apps connected through the remote MCP connector, with their signing keys encrypted.

What the names of the counters hold. The gas sponsor's counters are named by a keyed hash of the sender's address and of the network (an IP address, with IPv6 per /64 and per /48), made with a secret that Logbook holds and different every day, with the id of the group beside it for joining and leaving (a deployment that sets no such secret hashes without a key, and says so in its log). Whoever holds that secret can test an address or a network they name against a day's counters, and two counters written by one transaction carry the same amount, so a hashed network can be paired with a hashed address. The counters of the other endpoints hold the value itself: the wallet address for uploads of documents, reports and lists and for the email check, the IP address for AI, uploads, sign-in proofs and the email check, the id of the Google account for sign-in proofs. The email check also counts by keyed fingerprints of the Google account and of the mailbox. A counter of an API key is named by a hash of the key.

Logs. The server's log lines, which Cloudflare keeps, are written to hold no participant's wallet address, email or token. A sponsored transaction is logged with its function, its gas budget and a short code that stands for its sender for one day, and error reports from the app are cut to their path and lose what looks like an address or an id. Three kinds of line are different: a line about a report upload that failed names the campaign; a line about the treasury names the treasury's address; and several error lines hold the error as the chain, the storage or a library worded it, which Logbook does not edit and which can hold an address or an id. Cloudflare itself, as the host, sees every request to logbook.zone with its IP address and path. The ticket that links the two steps of gas sponsorship is not stored: it is a signed receipt that the server checks again.

#Lists of Groups

A group that lets people in by a list keeps only the fingerprint of that list on-chain. The list itself is two files in Logbook's storage (Cloudflare KV), the same store as the document cache:

• The published form: one hash per seat. Anyone can download it. A person who takes a seat needs it to show where the seat is in the list, and the browser checks that the hashes add up to the fingerprint on-chain, so a wrong or outdated file is refused by the reader. It tells the number of seats and nothing about them
• The admins' copy: the names of the seats, the expected holders, their emails if the admin entered them, and the secret of every personal link not yet used. It is encrypted in the admin's browser with a key made for that one version, and that key is released by the Seal key servers only to the owner and the admins of the group. Logbook's servers store the ciphertext and are never given the key. The group records the hash of the copy on-chain, so an admin can tell that the copy they were handed is the right one

An upload needs the signature of an admin, checked against the chain. Files are stored before the transaction that writes the new fingerprint. An upload the chain never commits to is deleted after two days; once the chain names it, it is kept for 400 days and renewed whenever an admin opens the list. Taking a seat and responding do not depend on the admins' copy: only handing out links and changing the list do.

If the admins' copy is lost from the store and from every admin's browser, members who took their seats keep them, because who holds which seat is on-chain. The names of the seats and the links nobody used are gone: the admin starts again from the chain, names the taken seats and hands out new links for the others. The list screen has "Download the list" for a backup of the names.

#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 and one limit:

• AI Analytics: before the creator runs it, they are shown what is sent and to whom, and confirm; they can send the individual answers (without addresses) or totals only. What they send was decrypted in their browser and passes in plain text through Logbook's server to the AI provider (DeepSeek), which produces the report. So the answers of an encrypted campaign are then seen by two parties its setting does not name. 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
• The limit: the upgrade key. Who is served a key is decided by the contract, and Logbook holds the key that can upgrade the contract. An upgrade could change the rule for everything already encrypted. It would be public; it is not yet prevented (see Smart Contract, Versions and Upgrades)

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

#Groups

• A private group: name, description and card form are encrypted with a random group key (AES-256-GCM), and the key is Seal encrypted for the group. Key servers release it to the owner, the group's own admins and its current members. A public group stores these texts in plain
• Member cards: a card has two parts, each a Seal encrypted object. The members part opens for the current members and the admins of the group; the admins part, where an email usually goes, opens for the admins only. The owner of a card reads both. A card opens only while its owner is a member
• Applications: what an applicant writes, and the card sent with it, open for the applicant and the group's admins while the application waits
• The admins' copy of a list: see Lists of Groups above
• Campaigns for the members of groups: encrypted like an address-list campaign when one of the groups is private, with the member records in place of the address list. Key servers release the keys to the creator and to addresses that were members when the campaign was created

When a member is removed or an admin is removed, the group starts a new key period (an "epoch" in the contract). What is written afterwards is encrypted for an identity the removed address never had a key for. What it read before, it may have kept. See Privacy in Groups.

#Seal in short

Seal is identity-based threshold encryption for Sui. Three key servers that Logbook does not run hold the master keys, and two of the three must agree. Who runs the three key servers this site uses: two are run by Mysten Labs, the company behind Sui, which also runs the full node this site reads and the service behind Google sign-in; the third is a committee of operators reached through an address of Mysten Labs. They are independent of Logbook, not of each other: any two of the three release a key, so Mysten Labs alone could read what they protect. 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

Privacy is the one page that says what is public, what is encrypted and what cannot be deleted. The Terms & Privacy page has the short version. The details of who sees what follow.

#What's Public

• All responses linked to blockchain addresses
• Who responded and when (addresses and timestamps)
• Answers and vote counts when answers are visible to everyone
• Campaign content and questions (encrypted unless the campaign is open to anyone)
• The address list of an address-list campaign, with every address added or removed later
• Who is a member of which group, when and how each joined and left, who applied, who the owner and the admins are, and how groups are linked: also for private groups (see Privacy in Groups)

#What's Encrypted

• Answers of campaigns with restricted visibility: the readers allowed by the visibility rule decrypt them, each next to its address. No rule keeps them from everybody
• The content of a campaign that is not open to anyone
• The name, description and card form of a private group, member cards, the texts of applications, and the names of the seats of a list

Encrypted data on a public blockchain is still public data: anyone can copy the ciphertext, and it stays there. What protects it is who is served the key.

#What Logbook and Others Can See

What Enoki, the key servers, the public nodes and Cloudflare keep, and for how long, is their policy. We have not verified it and do not control it.

#Pseudonymity

Your blockchain address is a pseudonym, not anonymity. Outside communities it is one address for every campaign; in each community (a group and the groups inside it) you act under an address made for that community alone. Everything an address did is public. It becomes a name:

• for the members and admins of a group where you have a member card or a seat on a list
• for Mysten Labs, when you sign in with Google (the address is computed from the Google account)
• for anyone you tell, and for anyone who can tie the address to you through what it did elsewhere