Generate Keys

Create your secure digital identity. The 'Generate Keys' tab creates your unique cryptographic keypair.

• Public Key: Your public address. Share it so others can identify you on the ledger.
• Private Key: Your secret password. It's used to sign your actions and is never shared or stored by the app.

You must save your private key securely. If you lose it, you will lose the ability to sign new actions linked to your public key.

Create an Entry

This is the heart of KWQR. An 'entry' is a signed, verifiable record of an action you've taken.

1. Go to the "Create Entry" tab.
2. Provide your Private Key to prove it's you.
3. Link to a previous entry's QR code to continue a chain, or leave it blank to start a new one.
4. Describe the action you're taking.
5. Click "Sign & Generate Entry" to create your new, permanent QR code record.

Build a Smart Contract

Go beyond simple records by creating automated, conditional actions. A smart contract is a rule that executes only when certain conditions are met. Use this tab to generate the contract's QR code, which you then use in the "Create Entry" tab to kick things off.

Ledger Explorer

Turn a long chain of entries into something easy to understand.

• AI Summary: Get a plain-language summary of a member's recent activity, powered by AI.
• Search & Validate: Combine multiple entries to search, audit, and verify the entire history of a ledger.

File Vault

Securely store and retrieve entire files on the ledger by breaking them into a verifiable chain of QR codes and their corresponding data.

1. Store a File: In the "File Vault" tab, provide your private key and select a file. The application will encode the file, split it into chunks, and generate a series of signed ledger entries. You can then download a ZIP archive which contains both PNG images of the QR codes (for printing/physical backup) and TXT files containing the raw data (for reliable digital reassembly).
2. Reassemble a File: To retrieve a file, upload the corresponding ZIP archive. The application reads the raw data from the included TXT files, verifies the cryptographic signature of each chunk in the chain, and reconstructs the original file. You can then download the reassembled file. This process ensures that the file has not been tampered with since it was stored.

Joint Approval (Multi-Sig)

Ensure important actions are approved by multiple people. Think of it as a digital safe that requires two keys to open.

1. Build: In "Build Smart Contract," select "Joint Approval" and specify the public keys of all required signers.
2. Approve: Each required signer creates their own "Approve" entry, using the contract's QR code as the "Previous Entry." This is their digital signature of consent.
3. Execute: To finalize the action, create an entry using the contract's QR code. In the "Supporting Entries" box that appears, add all the signed "Approve" entries. The action will only succeed if all approvals are present and valid.

Oracle

Trigger an action based on a signed report from a trusted external source (an "oracle").

1. Build: Select "Oracle," specify the oracle's public key, and define the exact JSON report data you expect it to provide.
2. Report: The trusted oracle creates a "Report" entry, using the contract QR as the "Previous Entry" and including the required JSON data.
3. Execute: Scan the contract QR, then provide the oracle's signed "Report" entry in the "Supporting Entries" box to trigger the action.

Group Vote

Execute an action only if enough members of a group vote in favor.

1. Build: Select "Group Vote," define the list of eligible voters (by public key), and set the number of "yes" votes required to pass.
2. Vote: Each eligible member creates their own "Vote" entry ("yes" or "no"), using the contract QR as the "Previous Entry."
3. Execute: Scan the contract QR, then provide all the signed "Vote" entries in the "Supporting Entries" box. The contract will automatically tally the valid votes and execute if the threshold is met.

Failsafe Switch

An action that triggers if a user fails to perform a periodic "check-in," useful for inheritance or emergency protocols.

1. Build: Specify the Owner (who must check in), the Heir (who inherits), and the check-in interval (e.g., 30 days). This creates a contract with a `check_in_deadline`.
2. Check-in: The Owner periodically logs a "Check-in" action, using the Failsafe Switch contract as its "Previous Entry." This action generates a *new* contract with a new, extended deadline, invalidating the old one.
3. Execute: If the deadline passes without a check-in, the Heir can execute the contract. They use the *last known* switch contract as the "Previous Entry" and provide their own private key. The contract action will then be logged.

Bounty

Post a reward for a task that can only be claimed when a designated reviewer approves a submission.

1. Build: Create a Bounty contract, specifying the Reviewer's public key and the reward.
2. Submit: A participant completes the task and logs a "Submit to Bounty" action, which includes their work or a description of it.
3. Approve: The Reviewer verifies the submission. They then log an "Approve" action, referencing the unique hash of the participant's "Submit to Bounty" entry.
4. Execute: The participant executes the original Bounty contract, providing both their submission entry and the reviewer's approval entry in the "Supporting Entries" box to claim their reward.

Scheduled Payment

Authorize a recipient to pull a fixed payment from a sender on a recurring schedule.

1. Build: Create a "Scheduled Payment" contract, defining the sender, recipient, amount, and interval (e.g., every 30 days).
2. Execute: When a payment is due, the Recipient executes the contract. They must provide all previous payment entries related to this schedule to prove when the last payment was made.
3. Cancel: The Sender can log a "Cancel Scheduled Payment" action at any time to stop future payments. The next time the recipient tries to execute, the contract will see the cancellation and fail.

Secure Swap (HTLC)

Lock funds that can be claimed by a recipient who knows a secret, or reclaimed by the sender after a time limit expires. The foundation for trustless atomic swaps.

1. Build: The Sender creates an HTLC, specifying the Recipient, a hash of a secret phrase, and a lock-time (e.g., 60 minutes). The Sender gives the actual secret phrase to the Recipient off-ledger.
2. Claim: Before the deadline, the Recipient logs a "Claim HTLC" action, providing the secret phrase. The contract verifies the secret against its stored hash and releases the funds.
3. Refund: If the Recipient fails to claim the funds before the deadline, the Sender can log a "Refund HTLC" action to reclaim their locked funds.