Version 2026-09-07.1
This notice is part of the AFA Protocol beta terms. You accept it at the same time. It says what we hold, why we hold it, how long, and what you can make us do about it.
Counsel has not reviewed this document. It was written and approved by the operator of the service. A review is pending, and this paragraph will be removed when it has happened, which will change the version and the hash.
Infrastructure Driven Growth And Future (IDGAF Holdings LLC) decides what is held here and why. Write to idgafholdingsllc@gmail.com.
The one thing to read if you read nothing else
We record hashes and metadata. We do not record what your agent said, what it was asked, or what a tool returned.
The client is built to send a hash of a tool's arguments rather than the arguments themselves, and the store holds a payload_hash and never a payload. That is not a policy we could quietly change without you noticing: a hash is what the chain is built from, and a record carrying content instead would look different to anyone reading their own export.
The exception is you. If you put content into a field that takes free text, we store the text you put there. That is true of an inquiry message, a continued-access request, and any field of an event you fill in yourself. Read what your client sends before you send it.
What we hold
Your account. Your email address, when the account was created, when it last signed in, and whether it is an administrator.
Your keys. For each API key: an identifier, a prefix, the machine name you gave it, when it was created, when it expires, when it was last used, whether it was revoked, and its capability scopes. We do not store the key itself, only a hash of it, which is why we cannot show you a key again after it is issued.
Your records. For each event: the identifiers, sequence numbers, hashes, signatures, decision and timestamps you send. Not the payload.
Your agreements. For each document you accept: the document id, its version, the content hash of the exact text you were shown, the time, and the network address the acceptance came from. The address is there so an acceptance can be shown to somebody later; an acceptance nobody can place is not worth much.
Your usage. A count of calls per day, per key, per capability. Counts, not contents.
Your messages. If you send an inquiry or ask for continued access, the text you wrote and the address you gave.
Our logs. Ordinary service logs: request paths, status codes, timings and network addresses. These are for running the service and finding faults.
Why we hold it
- To run the service and to authenticate you.
- To produce the record, which is the product.
- To tell you things you need to know: a key expiring, a chain break, the free period ending.
- To answer you when you write to us.
- To find and fix faults, and to deal with abuse.
- To show that an agreement was made, if we ever have to.
How long
- Your records: while your account exists, and for thirty days after a closure we initiated so you can still export.
- Your account and keys: while your account exists.
- Agreement acceptances: kept after closure. They are the evidence that an agreement was made, and deleting them would destroy the only thing that shows what you agreed to.
- Inquiries and requests: kept while we may still need to answer them, and for our own record of what was asked.
- Service logs: rotated on the ordinary schedule of the hosting provider.
Who else sees it
- Our hosting provider, which runs the containers and the database.
- Our email provider, which sends sign-in codes and notices. It sees your address and the text of the message.
- A webhook endpoint you register, which receives what we send it. You chose it and you control it.
- An anchoring provider, if you turn anchoring on. It receives a hash of your chain root and nothing else.
We do not sell your data. There is no advertising in this service, no tracking across sites, and no third-party analytics in the console.
What you can make us do
- Get a copy. Ask and we will send everything we hold for your account. You can also export most of it yourself through the API at any time.
- Correct it. Tell us what is wrong and we will fix it. Note that a stored RECORD is corrected by adding a record that says what was corrected, not by editing the original; that is how the chain works, and it is in the terms.
- Delete it. Ask and we will delete your account and its records.
- Object, or ask us to stop. Write and say so.
Write to idgafholdingsllc@gmail.com for any of these. We will answer within thirty days and tell you what we did.
What deletion cannot reach
Deletion removes your data from the service. It cannot reach a copy you or anybody else already exported, and it cannot reach a backup until that backup rotates out on its ordinary schedule.
We keep the minimum needed to show an agreement was made and to deal with abuse. That minimum is your address and your acceptance rows.
Where the data is
The service runs in the United States. If you are somewhere else, your data is handled there.
We have not completed a transfer assessment for any other jurisdiction, and we are saying that rather than implying it is done. If you need one before you can use this service, write to us and say what you need; the honest answer today is that it does not exist yet.
If something goes wrong
If we find that data has been exposed, we will tell affected account holders at the address on the account, say what we know, say what we do not yet know, and say what we are doing about it. We will do that whether or not we are required to.
Changes to this notice
This notice is versioned and its content hash is computed from its own text. A new version does not apply to you until you accept it, and you will be asked at your next sign-in.
Contact
Infrastructure Driven Growth And Future (IDGAF Holdings LLC)
idgafholdingsllc@gmail.com
This is the text the console shows at sign-in; the version and hash recorded with your acceptance are the ones above.
Back to the legal index