Security & Privacy
The central design constraint is that public chain evidence and private subject data are different things and must not be stored together.
The public/private boundary
ImplementedA chain transaction is a public fact. The relation between that transaction and a specific user is not.
| Object | Nature |
|---|---|
ChainTransaction, TransactionInclusion, TransactionExecution | Public chain facts |
AccountTransactionLink, Observation | Private, subject-scoped relations |
This is why the same transaction appearing across several of a user's wallets produces one transaction and one execution, with only the per-account Link and Observation differing.
The enforcement rule: public execution artifacts contain provider execution evidence only. They must not include subjectId, account IDs, or ownership windows. Without this, shared execution artifacts would leak the association between users and transactions precisely because they are shared.
Personal data in the schema
ImplementedThe schema never embeds original personal data. It records only the location and hash of immutable artifacts. Source payloads — API responses, PDFs, CSVs, manual entry batches — live in a database or object storage, and are not copied into the schema data.
SourceArtifact holds the location and whole-file hash. SourceRecord holds a coordinate and a record hash. Neither holds the content.
Access control in the JIT daemon
Implementedjitd, the Go gRPC daemon, implements:
- Access control by Unix peer UID or mTLS subject
- Secret redaction in logs and error paths
- A health endpoint and graceful shutdown
User-supplied facts
Facts that cannot be established from observation alone — address ownership, transfer purpose, unsolicited deposits, known data gaps — are recorded as UserContextAssertion rather than being inferred.
The inverse also holds: users are not asked to choose tax policy or lot calculation methods. Assertions capture what the user knows, not what the user would prefer the result to be.
Ownership and exclusion
Accepted ownership periods cannot overlap for the same account, though multiple non-overlapping periods are allowed — loss of control followed by reacquisition, for instance.
When a user excludes a known account from a publication's scope, the manifest discloses the account, who decided, the reason, and the grounds. An unknown external address is never disguised as an exclusion; such transfers remain external or unconfirmed.
On-chain payload boundary
Not verifiedThe intended GIWA design records a non-identifying commitment and revision state only — no transaction source text, wallet lists, amounts, or personal information.
This boundary is designed but not verified, because no contract or transaction exists yet. Confirming it against a real deployment is listed in Current Limitations.
Reporting
Security vulnerabilities should not be filed as public issues. Use the private reporting channel indicated in the repository.