The problem Proof of Life solves

Under the RTI Act, any citizen can ask a public office for its records. People who use it to expose fraud get killed for it: CHRI's tracker lists at least 107 RTI users murdered since 2005, and the Whistle Blowers Protection Act of 2014 has still not been brought into force. When an activist dies, the evidence often dies too. A study of RTI killings in Maharashtra found families had burned the documents out of fear.

Proof of Life lets an activist seal their documents and check in with one tap on a rhythm they choose. The documents are encrypted in the browser and written to Arkiv as read-only entities owned by an address nobody holds, so nobody can delete them, the activist included. The key is split k-of-n among custodians the activist picks (a journalist, a lawyer, a friend). The heartbeat is an Arkiv entity only the activist's key can extend. If they stop checking in, Arkiv drops it at its deadline, custodians publish their pieces, and any browser can open the documents. A duress passphrase makes a check-in that looks the same on chain while telling the custodians, through an encrypted note only they can read, to release now. Killing the activist no longer buries the findings, which takes away one reason to kill, as long as enough custodians stay free to act.

What an RTI filer can use today. The RTI clock takes the date the PIO received an application and shows the reply deadline (30 days, or 48 hours for life or liberty, plus 5 days through an APIO), when silence becomes a deemed refusal, and the appeal windows, each with its section of the Act. Once the deadline passes it drafts a First Appeal in English, Hindi or Telugu. It runs in the browser and works for a real application now. Optionally it writes one sealed record to Arkiv that shows the application existed by that block, with nothing sensitive on chain.

Every screen works in English, हिन्दी and తెలుగు, in a phone browser, with no wallet to install. The vault runs on Arkiv's Tiramisu testnet with synthetic documents, so for now it is a working rehearsal: a real vault needs a network that will still exist in a year.

Challenges I ran into

• A 128 KiB payload, the documented maximum, can never be written. I traced it to the public RPC's 262,144-byte request-body limit (HTTP 413) and the payload doubling as hex inside JSON-RPC; the SDK reports it as "Execution error without revert data". Ciphertext now goes in 96 KiB chunks, each created and sealed in one batch.
• Sealing atomically. I wanted entities undeletable from their first block. predictEntityKeys plus ownershipChanges to an address nobody holds in the same executeBatch does it, but predictions only hold within one transaction, so vault children link by a random vault_id and trust comes from $creator.
• No event fires when an entity expires, which is the moment this product exists for. Pages and the CLI set a timer from the heartbeat's own expiry block and confirm with one query.
• My first duress design deleted the heartbeat. That emits a public EntityDeleted event, so a coercer could spot it. I replaced it with a fixed-size encrypted note per custodian written with every check-in, so a forced check-in and a normal one have the same calldata length (4042 bytes each, measured).
• Keyless reads are rationed, so a vault page costs exactly one query (vault_id = … AND NOT (type = 'chunk')), with a small relay only as a fallback.