Tollkit — PRIVACY POLICY
Effective date: 2026-09-07
=============================================================================
DRAFT — NOT YET REVIEWED BY COUNSEL.
Every statement below was written against the actual behaviour of the running
software, and the code is the source of truth. If the code changes, this
document must change with it. Have an attorney in Maryland review before
launch, and re-check that the descriptions still match the code at that time.
=============================================================================
1. WHO WE ARE
Joseph E. Henry Jr ("we", "us") operates Tollkit, a pay-per-use service that sends
SMS messages to United States telephone numbers at the request of software
agents and their operators.
This policy explains what we collect, why, how long we keep it, and what we do
not do. Contact: hello@tollkit.dev.
2. THE SHORT VERSION
- We do not store recipient phone numbers. We store a salted one-way hash.
- We do not store message contents. We store a salted one-way hash.
- We do store your wallet address, because it is the payment instrument and
it is public on-chain anyway.
- We do not sell anything to anyone, ever.
- There are no accounts, so there is nothing to log into and no profile.
- There are no advertising or analytics trackers on our pages.
3. WHAT WE COLLECT
3.1 From an agent or operator using the Service
Wallet address. The public address that signs your payment authorization.
Necessary to take payment, apply per-wallet rate limits, and enforce blocks.
Payment authorization data. The signed EIP-3009 authorization you send. It
is passed to a third-party payment facilitator for verification and
settlement. WE NEVER RECEIVE OR HOLD YOUR PRIVATE KEY, and we cannot move
funds from your wallet without a signature you produce for a specific amount.
Request metadata. Timestamp, which surface you used (MCP or HTTP), the
outcome, the refusal reason if refused, the number of message segments, the
identifier our telecommunications provider assigned to the message, and the
settlement transaction hash.
Recipient number — AS A HASH ONLY. The destination number is used in memory
to place the call to our telecommunications provider and to check the opt-out
list. What is written to storage is an HMAC-SHA256 of the number under a
secret salt. Given a number we can check whether it appears in our records;
given our records, the number cannot be recovered.
Message body — AS A HASH ONLY. Same treatment, same reason. The body is held
in memory long enough to screen it and hand it to our provider, and what is
stored is a salted hash. We cannot read back what you sent.
3.2 From a person who receives a message
Opt-out status. If you reply STOP (or a similar word), we record a salted
hash of your number and the time, so that we can refuse every future message
to you. This is a legal obligation and we cannot honour it without keeping
the record.
Delivery status. Our telecommunications provider tells us whether a message
was delivered, failed, or was rejected, and any error code. We attach that to
the corresponding record.
Inbound message contents. If you reply with something other than a keyword,
the reply reaches our provider. Our systems act only on the keyword and do
not store the body of your reply.
3.3 From a person who uses the opt-in form on our website
The number you enter and the fact and time of consent, stored as a salted
hash and a timestamp. An email address if you choose to give one. Nothing
else — no cookies, no analytics, no advertising identifiers.
3.4 Server logs
Our hosting provider records ordinary web server logs, which include IP
addresses, for operations and abuse prevention. These rotate on the
provider's schedule and we do not mine them or join them to anything else.
4. WHY WE PROCESS IT, AND ON WHAT BASIS
To provide the Service you asked for — performance of a contract.
To take payment — performance of a contract.
To honour opt-outs and screen prohibited content — legal obligation, and our
legitimate interest in not losing our carrier registration.
To apply rate limits and block abusive wallets — legitimate interest in
keeping the Service available and our sender reputation intact.
To keep an audit trail sufficient to answer a regulator or a carrier —
legal obligation and legitimate interest.
Where the GDPR or UK GDPR applies, the bases above are Article 6(1)(b),
6(1)(c), and 6(1)(f) respectively. Note that the Service sends only to US
numbers.
5. WHO WE SHARE IT WITH
We share only what a processor needs to do its job:
Our telecommunications provider (currently Twilio Inc.) receives the
recipient number and the message body, because it is the party that actually
delivers the message. Its own privacy terms apply to that processing.
Our payment facilitator receives your signed payment authorization in order
to verify and broadcast it. It does not receive the recipient number or the
message.
The Base blockchain receives the settlement transaction. On-chain data is
public and permanent and is not under anyone's control, including ours.
Our hosting provider processes traffic and stores our database on our behalf.
We disclose information to law enforcement or a regulator only when we are
legally compelled, and we will tell the affected party where we are lawfully
able to.
WE DO NOT SELL PERSONAL INFORMATION AND WE DO NOT SHARE IT FOR CROSS-CONTEXT
BEHAVIOURAL ADVERTISING, as those terms are defined under the California
Consumer Privacy Act.
6. HOW LONG WE KEEP IT
Opt-out records: indefinitely. Deleting one would mean texting someone who
told us to stop. This is the one record we will not delete on request.
Audit records (hashes, wallet, outcome, timestamps): 24 months, then
deleted. This is long enough to cover the usual limitation period for a
claim about a message.
Opt-in form records: 24 months from the last message sent under that consent.
Server logs: per our hosting provider's rotation, typically 30 days.
7. YOUR RIGHTS
Depending on where you live you may have the right to know what we hold about
you, to get a copy, to correct it, to delete it, and to not be discriminated
against for asking.
You can exercise these by writing to hello@tollkit.dev. Two honest caveats:
Because recipient numbers and message bodies are stored only as salted
hashes, we can confirm whether a number appears in our records if you give us
the number, but we cannot produce a list of numbers or reconstruct message
contents. There is nothing to produce.
We will not delete an opt-out record, because keeping it is how we avoid
contacting you again. If you want messages to resume, reply START to a
message from our number or use the opt-in form.
If you are in the EU or UK you may also complain to your supervisory authority.
If you are in California you may designate an authorized agent to act for you.
8. SECURITY
Traffic to the Service is encrypted in transit with TLS. Credentials and the
hashing salt are held as deployment secrets, not in source control. The
database is not exposed to the public internet. Access is limited to the
operator.
We do not hold private keys and cannot move your funds. We do not store
recipient numbers or message contents in a recoverable form, which means a
breach of our database would not expose them.
No system is perfectly secure, and we do not claim ours is.
9. CHILDREN
The Service is a business tool and is not directed to children. We do not
knowingly collect information from anyone under 13. If you believe a child's
information has reached us, write to hello@tollkit.dev and we will delete what we can.
10. INTERNATIONAL USERS
We operate in the United States and process information there. The Service
sends only to United States numbers. If you connect from outside the US, your
request data is transferred to and processed in the US.
11. CHANGES
We may update this policy. The current version is always at the /privacy path
of the Service, and the effective date above reflects the last change. Material
changes will be noted at that URL. Because there are no accounts, we cannot
notify you individually.
12. CONTACT
Joseph E. Henry Jr
Maryland, United States
hello@tollkit.dev