Security

Last updated: 23 October 2026

The short version

• >commit_ is in closed beta: we let projects and people in a few at a time.
• The split record is built so that no one, including us, can quietly rewrite a signed version: each version is chained to the last, every signer gets a receipt, and the record is time-stamped daily by an outside service.
• There are no passwords to leak. Store and revenue access is read-only, and those keys are encrypted separately.
• Our staff open a project only when you ask for support, and every access is logged.
• Found a problem? Tell us at [email protected].

1. At a glance

We hold no security certifications (such as SOC 2 or ISO 27001). If that changes, we’ll say so here.

2. How the split record is protected

2.1. Append-only versions. A split is never edited in place. Every change, even a typo fix, is a new version. Earlier versions stay readable by every member.

2.2. Hash chain. Each version is reduced to a fingerprint (a cryptographic hash) that also covers the previous version’s fingerprint. Change anything in an old version and every fingerprint after it stops matching. Anyone with an export can recompute the chain and check it.

2.3. Receipts. When you sign, you get a receipt with the version’s fingerprint. Keep it: it’s your own proof of what you signed, independent of us. A PDF copy is available on request.

2.4. Daily outside time-stamp. Once a day, the latest fingerprint is anchored with OpenTimestamps, an open time-stamping service. Only the fingerprint leaves our systems, never your data. This proves the record existed in that form on that day, so we can’t back-date or swap it without it showing.

2.5. Signing. Only a person can sign, by clicking in the app after signing in with their email. Agents and API keys can propose changes but can never sign.

2.6. Export. Any member can export the full history of their project as one file, including the fingerprints, so it can be checked without us.

3. Encryption

• In transit: all traffic to commit.cx uses HTTPS.
• At rest: the database is hosted on Cloudflare D1, which encrypts stored data. Store, revenue, git and API keys are encrypted again, separately from the rest of the data, and are decrypted only to read revenue or commit history.
• Secrets: service keys (for example, our email sending key, which can only send) are stored as encrypted secrets in our hosting provider, not in code.

4. Access control and staff access

4.1. Your account. There are no passwords to leak or reuse. Sign-in relies on access to your email inbox, so protect your email account with a strong password and two-factor authentication. Sign-in links and codes work once and expire after 15 minutes.

4.2. Project access. Only members of a project can see its split, history and revenue figures. Board posts are public, but contact details are never included in public feeds.

4.3. Staff access. Our staff open a project’s data only when a member asks for support, and only for as long as needed. Every staff access is logged with who, when and why, and the log is kept for two years.

4.4. Our own accounts. Only the founding team can access the database, through our hosting account. Every account with access to our infrastructure and providers, including Cloudflare, Resend and PostHog, is protected with two-factor authentication.

5. Store and revenue connections

• We ask Stripe, RevenueCat, App Store Connect and Google Play only for read-only access to revenue data. We can’t change prices, issue refunds, publish builds or move money with these keys.
• Keys are encrypted separately (section 3) and used only to read revenue for the project they belong to.
• Git repositories. A project can connect its repository (GitHub, GitLab or any git host) with a read-only token, so we can mark shipped titles “checked”. The token is encrypted separately, like store keys. We read only commit authors and commit counts or dates, and never store source code. You can revoke the token at any time by deleting it on the git host.
• You can disconnect a source at any time; we then delete the key. We recommend creating a key just for >commit_ in each provider, so you can revoke it there too.

6. API, MCP and agent keys

• The split sheet is open data for its members, reachable over an API and MCP. Access is read-only by default.
• Each agent gets its own key. You can see which keys exist, what each one did, and revoke any of them at any time.
• An agent can propose a change, never sign one. Every change drafted by an agent shows who asked for it.
• Treat keys like passwords: don’t paste them into public places or share them between agents.

7. Payments and payouts

Only when we publish your app.

• Payouts go through Stripe Connect. Bank details, identity checks and tax forms are collected and held by Stripe, not by us.
• Team funds are kept in an account separate from >commit_’s own money.
• The provider’s fee for each payout is taken from that payout and shown to you before it is sent.

8. Spam and abuse protection

Every form has a hidden field that only bots fill in. Each IP address can make only a limited number of submissions per hour, counted in our database; stored IP addresses are deleted after 30 days. Analytics requests pass through our own address, which strips cookies before forwarding them to PostHog.

9. Providers

We rely on a small set of providers, each listed in our Privacy Policy: Cloudflare (hosting, functions, database), Resend (email), PostHog (analytics), Stripe (payouts), and the revenue sources you connect. We choose providers that encrypt data and publish their own security practices, and we give each one only the access it needs.

10. If something goes wrong

10.1. We investigate any suspected incident straight away, contain it, fix the cause and record what happened.

10.2. If an incident affects your personal data, we will tell you within 72 hours of confirming it, with what happened, what data was involved and what you should do. We will notify data protection authorities where the law requires, for example within 72 hours under the GDPR.

10.3. If a key you connected might be affected, we will revoke it and ask you to issue a new one.

10.4. Because of the hash chain, receipts and outside time-stamps, an incident can’t silently change a signed split. If a fingerprint ever fails to match, we will tell every member of the affected project.

11. Reporting a vulnerability

If you think you’ve found a security problem, email [email protected]. Please include steps to reproduce it. Our contact details are also in /.well-known/security.txt.

• We’ll reply within 3 business days and keep you updated until it’s fixed.
• We won’t take legal action against good-faith research that follows these rules: don’t access or change other people’s data beyond what you need to show the problem, don’t disrupt the Service, don’t use social engineering or physical attacks, and give us reasonable time to fix the problem before you tell anyone else.
• We don’t run a paid bug bounty yet. We’re glad to credit you publicly if you’d like.

12. Changes

We update this page when our practices change. The date at the top shows the latest version.