Agreements you own. Readable by humans, machines, and courts.

Ricardian Augmented Markdown. Readable prose with machine-readable parameters inline. One document serving both audiences — not a human version and a machine version that can drift apart.

Not JSON, not XML: a judge can't read those, and the prose is the legal agreement. The parameters serve the prose, never replace it. Where the two conflict, prose governs — stated in the contract itself, signed by all parties to it.

Jurisdiction, dispute resolution and termination live in the document too, as a signed section rather than in a platform policy. Everything that governs the agreement is inside the thing the parties put their name to.

Each party signs with an Ed25519 key. At minimum that is paired with a one-time code to their email, proving both cryptographic intent and email control at the moment of signing. From there the requirement can be raised: a Riccy ID, a verified Riccy ID where we have checked the identity behind the account, or a wallet signature for parties already operating on-chain. The contract states what it requires, so the bar matches the stakes instead of being fixed for everyone.

Quorum works the same way: two-party, three-party and n-of-m arrangements are all expressed in the document itself. Signing needs a Riccy account and takes a link, a code and a click — no gas, no wallet, no keys to manage. Verifying a finished agreement needs nothing at all — no account, no software, no connection. That asymmetry is deliberate: the effort sits with the people taking on obligations, not with everyone who later needs to check the record.

An account proves control of a login, not who you are in the world. So where the stakes justify it, a party can additionally be bound to a verified real-world identity — verified by us, or vouched for by a government eID or an organisational credential. That is an option a contract turns on, not a hurdle every signer has to clear.

The signed document is anchored to permanent decentralised storage, fixing its content and timestamp beyond any party's reach. The fingerprint proves the document hasn't changed; the anchor proves it existed at a given moment.

Together they close the two ways a record fails: alteration, and a party simply denying it ever existed. Timestamps can additionally be recorded on Solana or Ethereum where a client wants on-chain corroboration — an option, not a dependency. No chain has to be running for a contract to verify, which is precisely what keeps verification permanent.

Every contract is either public or private, chosen when it is created. A public contract is readable by anyone who has its reference — useful when the point is to be seen: a published licence, an open commitment, a credential meant for the world to check.

A private contract is encrypted before it is ever uploaded, so what sits in permanent storage is ciphertext — unreadable to anyone without the key, including us. The key travels inside the Evidence Package, to signatories only. The parties can always read and verify their own contract, while the stored copy reveals nothing. Commercial terms, rates and margins stay between the people who agreed them.

Private contracts also give a workable answer to the right to erasure. Delete the key and the ciphertext becomes permanently unreadable — functional erasure, without pretending that something written to permanent storage can be unwritten.

Real work is a hierarchy: a client engages a contractor, who engages subcontractors, who engage suppliers. Each relationship is its own agreement with its own proof, referencing its parent — so the whole tree is traversable and auditable without anyone's server.

Privacy is per node. A subcontractor's margin sits in their contract and stays invisible to the client unless explicitly granted. Visibility is agreed and signed up front, not assumed by the platform.

Each node is also independent for amendments. Changing one contract requires only its own signatories, and changes nothing elsewhere in the tree — so no one can rewrite an agreement they are not party to.

The same machinery for single-party declarations, where one party issues a record rather than two agreeing one. A university issuing a degree or a course certificate. An employer confirming a role, dates and standing, so a former employee can prove their history years later without chasing an HR department that may no longer exist. A lab releasing a result, a body certifying compliance, an auditor confirming a check was done.

The issuer signs it once. The recipient holds it permanently and can present it to anyone, who can verify it without contacting the issuer at all — which is the part that makes credentials and employment records actually portable.

Contracts can be created, signed, and verified through the API — so agreements become part of a system rather than a manual detour out of one. Issue an attestation when a milestone closes; verify a counterparty's document before releasing work.

Because the same document is machine-readable, an autonomous agent can read the terms it is bound by, and verification returns structured output rather than a rendered page. As software starts transacting on behalf of people, the question of what an agent actually agreed to becomes a record, not a log line.

An auditor, regulator, funder or insurer can be granted access to a contract or an entire project tree and check every document independently — no chasing counterparties for their copies, no trusting that what they were sent matches what was signed.

A project-level package assembles the complete cryptographic record of a job: every node, every fingerprint, every signature, and a verifier for each. Every claim in it stands on its own evidence rather than on anyone's assurance that the file is genuine.

Conventional bookkeeping is double entry: each party keeps their own record, neither authoritative, disputes settled by comparing two unverified accounts.

A signed Riccy contract is a third entry — a record no party controls that all of them can verify. Where a contract carries financial terms, the structured accounting entry is produced automatically at signing and exports to any external system. No separate step, no reconciliation between two versions of events.

You don't edit a signed contract. Nobody can, including us — that is the whole basis of the proof. Instead you issue a new contract that names the one it supersedes, and its parties sign it as they signed the first.

The original stays exactly where it was written, permanently. Anyone can follow the chain from the current version back to the very first, so every state the agreement ever passed through remains provable. In a dispute you show what was agreed on a given date, with cryptographic proof, instead of reconstructing it from an email thread.

Not by any party to it, and not by us. Once anchored it cannot be altered, hidden, or withdrawn — which is precisely what makes it usable as evidence.

For private contracts there is a bounded version of erasure: delete the key and the stored ciphertext becomes permanently unreadable. That has a real limit worth stating plainly: signatories who already hold the Evidence Package keep their copies. Key deletion removes future access through the platform; it cannot retrieve what people were entitled to hold.

You do, in the contract. Governing terms — jurisdiction, dispute resolution, termination, and the rule that prose governs — are a section of the signed document, agreed by its parties at signing.

They are not buried in our terms of service. That distinction matters in a dispute: what governs the agreement is inside the thing the parties signed, not in a platform policy one of them never read and we could change later.

The prose wins. Always.

The parameters are instructions to software; the prose is the legal obligation. Where they disagree, the obligation is what was written in words. This is not our assumption about how you'd want it read — it is stated in the governing terms of every contract and signed by its parties, so it holds in front of a court rather than only inside our system.

Nothing, unless the parties to those contracts sign something. Each node in a tree is an independent agreement between its own parties. Amendments do not cascade down or up.

That doesn't leave the tree stranded. If a change upstream means a downstream agreement has to change too, those parties issue their own new contract — referencing the one above it, or superseding their own previous version, or both. The link is made by reference, and the consent is given by signature. What you cannot do is have a change propagate into someone's agreement without them signing for it.

The corollary is the protection: you cannot amend someone else's contract. A client cannot rewrite the terms between a contractor and their supplier, and a contractor cannot quietly alter what they agreed with the client by changing something further down.

They can be barred from entering into new contracts within a project, and that exclusion is itself a signed, timestamped, auditable record — who excluded whom, when, and why.

The honest limit: exclusion runs forward, not backward. A signed contract cannot be retroactively voided without the other party's consent unless that contract already contains a termination clause granting the power. Whatever consequences exclusion carries — barring new work only, suspending existing work, or triggering termination — must be defined in the root contract and agreed by everyone joining the project, in advance. Nobody can invent that power after the fact.

There are two kinds of access, and they behave very differently.

If you signed it, your access is permanent. You hold the Evidence Package. Nobody can revoke it — not the other party, not the client above you, not us.

If you were granted sight of a contract you didn't sign — an auditor, a client looking down the tree — that access is served through the platform and can be withdrawn. Withdrawing it stops future access, including to later versions and new contracts; it does not unsee what has already been seen, and it cannot claw back anything already delivered.

A party is one or the other, never both. Beyond that, visibility is set when a contract is signed and can only be changed the way anything else changes: by a new agreement its parties sign.

Yes, and we would rather say so plainly than imply a trustlessness we do not have.

Signing keys are generated and held for you, so that signing works from any device and a key cannot be lost with a browser. This is what every established e-signature platform does, and it carries the same cost: while we hold a key, we are technically capable of using it. What follows from that is a matter of audit trails and controls rather than mathematics — which is exactly the position the rest of the industry is in.

For private contracts we also hold the content key, the one that decrypts the document. That is what makes platform-served views possible — a client or an auditor granted sight of a contract they did not sign is served the plaintext rather than handed a key they would keep forever — and it is what makes key deletion work as erasure.

Here is where it differs from the alternatives. Holding keys affects who we can show a contract to and what we could in principle sign. It has no bearing on whether an existing agreement can be verified. Verification runs on the fingerprint and the signatures already in the document, so anyone holding an Evidence Package can prove their contract with no key of ours, no cooperation from us, and no dependence on us existing. A platform that holds your keys and holds the only copy of your proof is a very different proposition from one that holds keys and gives the proof to you.

Parties who want to remove the dependency entirely can bring their own key — a hardware token or an existing certificate — and sign without one ever being generated here. Public contracts involve no content key at all.

Your contracts are unaffected. They stay where they were anchored, the signatures stay valid, and the verifier in your Evidence Package keeps working — it runs offline and makes no calls to us.

What you'd lose is the convenience layer: composing new contracts, the interface, granted views for non-signatories. What you keep is everything that constitutes the proof. That is the difference between a record and a subscription.