Inkwell Finance Documentation

CONFIDENTIAL & PROPRIETARY © 2026 Inkwell Finance, Inc. All Rights Reserved. This document is for informational purposes only and does not constitute legal, tax, or investment advice, nor an offer to sell or a solicitation to buy any security or other financial instrument. Any examples, structures, or flows described here are design intent only and may change.

Applies to every row below. Encrypt’s current devnet deployment does no real encryption: ciphertext accounts hold plaintext, and the executor sees everything. The confidentiality claims on this page hold only once Encrypt runs threshold FHE, planned for Alpha 1. Until then, treat every encrypted figure as public.

Dagon Payroll follows the Dagon privacy-model convention: every data flow is enumerated, each party’s view is named, and each LINDDUN category gets a disposition. The payroll flows are the PAY-* rows of the Dagon privacy-model registry, recorded in ADR-024.

Who sees what

Party	Sees	Does not see
Public chain observer	Every account, instruction, event and token transfer. That means: the company, its authority, mint, vault and policy (auditor, operator, salary cap, paused); headcount and every employee wallet; total funding; each run’s period, budget ceiling, headcount, paid count and bonus count; which employee was cranked in which run, and whether it was a salary or a bonus; each withdrawal’s amount, recipient and whether it paid; the fact of each `grant_view` (grantor, viewer, source handle).	Any salary, bonus or accrued balance. Treasury remaining, run spend, flagged count. Whether a given payment succeeded.
Multisig signers	Everything the observer sees, plus proposal contents: employee wallets, salary and bonus ciphertext handles, period, budget, cap. The HR member who encrypts a salary knows the value they encrypted.	Salaries. Signers approve a handle, never a plaintext amount.
Crank / operator	What the observer sees. It submits payments against handles.	Any amount. The crank never decrypts anything and never sees whether a payment succeeded.
Employee	What the observer sees, plus their own salary and balance, by granting a view to their own key.	Other employees’ figures. Treasury, run spend, flagged count.
Auditor (key set by the authority)	Any encrypted figure, by granting a view to itself.	Nothing it hasn’t pulled through `grant_view`. It cannot grant a view to anyone else.
Encrypt executor / decryptor (post-alpha: threshold committee)	Ciphertexts and graph executions. Plaintext only on a decryption request, and the program requests decryption only for a withdrawal’s `paid` value (the requested amount or 0).	Post-alpha: any value it is not asked to decrypt. Pre-alpha: nothing is hidden from it; a single mock executor sees plaintext.

Public vs. ciphertext

Datum	Visibility
Company exists, authority, mint, vault, policy (auditor, operator, cap, paused)	Public
Headcount and employee wallets (Employee PDA seeds)	Public
Total deposited and withdrawn (SPL transfers to and from the vault)	Public
Run period, budget ceiling, paid count, bonus count	Public
Each salary, bonus, accrued balance	Ciphertext
Treasury remaining, run spend, flagged count	Ciphertext
Withdrawal amount and whether it paid	Public at withdrawal time

What leaks by design, and why

Employment is linkable to a wallet. Employee records are PDAs seeded by the employee’s wallet, so the wallet-to-employer link and headcount are public. The mitigation is a fresh wallet per employer.
Funding totals. Funding is a plain SPL transfer. The total payroll funding is disclosed; the per-employee split is not.
The cap and the budget are upper bounds. The public per-payment cap bounds every salary from above. The public budget ceiling bounds the run total. Set them loosely to reveal less. Actual spend stays encrypted.
Withdrawals are public. The SPL exit amount is inherently public. A failed withdrawal reveals balance < amount to everyone. Only the remaining balance stays encrypted.
Withdrawal timing correlates with pay dates. This is tracked as open. Withdrawing sums other than the salary, or at other times, weakens the correlation.
Grants are public events. That a disclosure happened is visible, including the viewer key. Its value is not.

Hiring, pay changes, run approvals and grants are deliberately attributable: they are signed governance or consent records.

Disclosure permissions

grant_view enforces this matrix on-chain:

Grantor	Figures	To whom
Authority	Any (treasury, salary, balance, pending bonus, run remaining, run flagged)	Anyone
Auditor	Any	The auditor only
Employee	Own salary or own balance	Anyone

Nothing is decrypted on-chain. The copy is a new ciphertext authorized to the viewer, who reads it through Encrypt ReadCiphertext.

Open items

Encrypt pre-alpha. Every confidentiality claim is open until Encrypt Alpha 1, as stated at the top of this page.
Withdrawal correlation. Withdrawal amounts can be correlated with pay dates. A confidential exit through Encrypt’s pc-token is roadmap.
EU employers. Visibility of the employment relationship needs a jurisdiction review (GDPR, pseudonymous data) before EU employers onboard.

Roadmap to less linkability

Per-employer wallets. A fresh wallet per employer breaks cross-employer linkage. Available today, as an operating practice.
Confidential exits. Settling into Encrypt’s pc-token instead of plain SPL would hide withdrawal amounts.
Blinded headcount. Replace wallet-seeded employee records with commitment-seeded ones, at the cost of an extra authentication step at withdrawal.

Start Here

Payroll

Concepts

Architecture

FAQ

Performance

Comparisons

Objections

Who sees what

Who sees what

Public vs. ciphertext

What leaks by design, and why

Disclosure permissions

Open items

Roadmap to less linkability

​Who sees what

​Public vs. ciphertext

​What leaks by design, and why

​Disclosure permissions

​Open items

​Roadmap to less linkability

Who sees what

Public vs. ciphertext

What leaks by design, and why

Disclosure permissions

Open items

Roadmap to less linkability