Whitepaper · v1.0

Time plans you can inspect. Progress you can prove.

Chronava is a lightweight weekly mission calendar for people and small teams who want transparent planning, local-first data, and optional proof without surrendering the context of their work.

1. Problem

Goals often fail between intention and execution. Planning tools store events but do not explain how a goal became a schedule; automated systems may hide assumptions; and public proof systems can reveal too much. Chronava makes the decomposition visible, keeps every item editable, and separates private work data from minimal proof.

2. Goal decomposition and calendar logic

A user enters one weekly goal and selects light, balanced, or focused intensity. The current release uses clearly labeled deterministic demo logic to create three, five, or seven missions. The same goal and intensity produce the same ordered suggestions. Missions use predefined weekday and time slots, can be edited or moved, and remain ordinary local calendar records.

Chronava does not claim that deterministic suggestions are generated by a live model. A future configured model may propose richer decomposition, but its output must remain reviewable and user-controlled. No generated plan is professional advice or a guarantee of success.

3. Receipt model

The app serializes the goal, week label, intensity, and normalized mission state in a stable order, then computes a SHA-256 digest with the browser Web Crypto API. Completion changes produce a different receipt. The 64-character hexadecimal digest is a local commitment: by itself it does not prove that work was good, only that a specific private state can later be compared with the digest.

4. Web3 architecture

Wallet connection is read-only and requests only a selected public address and active chain ID. It does not sign a message, request an approval, send a transaction, or charge funds. Four independent contracts separate mission commitment, checkpoint records, an optional refundable bond, and a non-transferable completion badge.

Every review shows the selected role, complete destination address, ABI method, network, payload purpose, and value. Three actions transfer zero value; the optional bond uses a user-entered amount and is never bundled with wallet connection. Network gas may still apply to every action. Under the current bond contract design, the mission owner can release the same deposited amount after reaching the checkpoint target or after the deadline passes; the bond earns no yield, release is a separate transaction, and users must verify the deployed code and parameters. All four role addresses plus an explicit active suite status are required before writes are enabled.

5. Data minimization

Schedules, goals, completion state, receipt hashes, and submitted transaction history use browser storage on the current device. Chronava has no account system, team directory, third-party calendar sync, messaging layer, or background automation in this release. Clearing browser data may erase local records. A public chain address and minimal proof metadata become public only if a user later confirms a configured transaction.

6. Transaction receipts and history

After a wallet provider returns a valid transaction hash, Chronava stores that public hash and its related local receipt on the current device with an honest pending state. A manual refresh calls eth_getTransactionReceipt. Only a mined receipt with status 0x1 becomes confirmed; status 0x0 becomes failed, and a missing receipt remains pending. Explorer links point to BOT Chain’s public explorer.

7. Threat model

Risks include malicious wallet extensions, phishing interfaces, exposed public addresses, replayed or misleading receipts, accidental disclosure when sharing a digest with context, local-device compromise, network congestion, reverted transactions, malicious contract configuration, and incorrect environment settings. Mitigations include read-only connection, explicit contract previews, zero-value calldata construction, disabled live actions when configuration is absent, local hashing, minimal payloads, and receipt-backed state labels.

8. Limitations

A hash is not independent verification of task quality or real-world completion. Local storage is not a backup. Calendar conflict detection is visual and does not inspect external calendars. Submitted transactions may remain pending, fail, or be reorganized. Chronava does not provide investment, legal, tax, employment, or scheduling advice.

9. Roadmap

Possible future work includes encrypted export and import, receipt comparison, independent proof viewers, and external security review of the four-contract suite. These are directions, not commitments. Chronava will not add swaps, token approvals, automatic payments, or hidden background transactions.

Updated September 20, 2026