Security & Trust Statement

1The design principle: trust the math, not the vendor

FreeholdIP is built so the things that matter — authenticity, ownership, status, survivability — are provable without trusting FreeholdIP. Verification runs in the checker’s own browser against the public record. We are a convenience for creating and hosting records; we are deliberately not in the trust path for believing them.

2Key custody: we hold none

• Client-side key generation. The firm’s signing key and the client’s identity key are generated in the user’s own browser. FreeholdIP never receives, stores, transmits, or can recover a private key. We cannot sign as a firm or a client, alter their identity, or seize it.
• Encrypted-at-rest keystores. Keys a user chooses to store are protected by an Argon2id key-derivation function and AES-256-GCM, with the KDF parameters bound into the encryption so any tampering fails closed. The password never leaves the browser.
• No asset custody. FreeholdIP holds no client funds, securities, accounts, or wallets, and is never in the flow of funds.

3The trust root: the firm’s key, bound to the firm’s domain

• An issuing firm’s identity is recorded on the public ledger (an Algorand asset for new issuers; identities anchored earlier on other public chains keep verifying) owned by the firm’s key — not by FreeholdIP.
• The firm’s signing key is published in the firm’s own DNS (a TXT record the firm controls). A verifier confirms that the key which signed a record matches both the firm’s on-chain identity and the firm’s domain — so a lookalike cannot forge the firm’s records. Domain control is the trust root; our endorsement is not.
• Key rotation is supported without breaking past records: the firm rotates its signing key under a signed, Bitcoin-timestamped key history; the stable published identity name does not change.

4What is stored — and what is not

• Stored (non-secret by design): the signed records themselves (powers of attorney, inventories), the firm’s signed revocation list, and content-addressed copies on IPFS — all public, watch-only information. Asset references in an inventory are public identifiers only (an xpub, a descriptor, a domain, an account handle) — never a private key, seed, or password; a fail-closed guard rejects anything that looks like a secret before it can be stored.
• Stored as ciphertext only: a reconstruction recipe for a self-custodied asset is encrypted to the successor’s own key before it reaches us. We hold the ciphertext; we cannot read it.
• Not stored: private keys, seeds, passwords, Shamir shares, or co-signing keys — none of these ever reach FreeholdIP. Transient documents collected to vet a new issuer are purged after review.

5Integrity & tamper-evidence

• Every record is content-addressed (its identifier is the hash of its contents) — any alteration changes the identifier and fails verification.
• Records are anchored in Bitcoin via OpenTimestamps, giving an independent proof that a given version existed by a given block — defensible in a file or a courtroom.
• Status (in force / suspended / revoked / expired) is read live from the firm’s signed registry at verification time, so a stale copy cannot misrepresent current authority.

6Survivability: it outlives its provider

This is the core invention and the strongest assurance for a risk review:

• Each record carries its own means of verification and is anchored to a public ledger.
• Revocation lives in the firm’s own signed list, resolvable by anyone from the public record — not dependent on FreeholdIP.
• A downloadable, offline self-verifying copy confirms authenticity with our servers switched off.

7The operate layer: non-custodial by construction

For self-custodied digital assets, a successor takes control via a reconstruction recipe — encrypted to the successor’s own key — that points at a Shamir-share plan or a native-multisig policy (the successor a co-signer from the start). The shares or co-keys are held by the client’s chosen parties; the successor reconstitutes control on the asset’s own chain, on their own device, with standard tooling. No key, share, or signing operation ever passes through FreeholdIP or the firm. The platform proves and coordinates the handoff; it never performs custody. No new on-chain contracts or assets are created on our side for any of this.

8Operational posture (honest, maturing)

We distinguish architecture from operations:

• The architectural guarantees above do not require trusting our operations — they are cryptographic and independently checkable.
• Operationally, FreeholdIP is an early-stage platform. We have performed a security hardening pass (fail-closed authentication, separated session secrets, least-privilege key-file permissions, host-gated administrative surfaces, dependency and configuration hygiene) and we run on dedicated infrastructure. We do not yet hold a formal third-party attestation (e.g., SOC 2); we will say so plainly rather than imply otherwise, and we are glad to walk your team through the current controls.
• Because the records’ validity, ownership, and revocation are anchored off-platform, the blast radius of any operational incident at FreeholdIP excludes the authenticity and survivability of records already issued.

9What we will do for your review

• Walk your security/IT team through the verification flow, the trust root, and the revocation demonstration.
• Demonstrate a record verifying offline, with our servers off.
• Provide the role / UPL analysis and the issuer agreement for your legal and procurement review.
• Scope a pilot that lets your team test the controls against real (non-production) mandates.

See also: Role / UPL analysis · How an institution verifies a certification · The end-to-end walkthrough