document
version of 7 September 2026 · effective from publication
This is an English translation for reference. The Portuguese original is the governing text; if the versions differ, the Portuguese text prevails.
This page describes what raizelo receives, what it stores, what it does not receive, and what becomes public and permanent. The summary below is short because the system was designed to receive very little. The full policy follows immediately after it — and the summary links to it section by section.
The file never leaves your device. When you use the checking box, its code is calculated by your browser, and only that code can be sent — and only if you open the verification page. We do not receive, see or store the file or its contents.
section 1A 32-byte code — the file’s fingerprint. It cannot be used to reconstruct the file or tell what it contains. The document issuer sends this code and may attach an internal label for their own use. We receive and store that label, and it is never published: the verification page does not show it, and the page cannot reveal what the document is about.
section 3.2Each code becomes part of a batch, and the batch’s code is published on a public blockchain. When the batch contains only one proof, the published value comes only from that document — and still reveals nothing to anyone who does not have it. This record cannot be deleted or altered, by us or by anyone else. That is what gives the proof its value, and it is the only irreversible part of this system. No file, name or personal data is part of it.
section 4The verification page only shows the issuer’s name when that issuer has chosen to be identified. Without that choice, the record does not identify anyone. The choice applies retrospectively — including proofs registered before it — and continues after the account is closed, so that closing an account does not silently remove trust from documents already in circulation. It can be reversed at any time.
section 5.1This page and the verification page do not use cookies — whether for login, tracking or analytics. You do not need an account to verify a document. The server records your IP address and the time of access, as any web server does, for security and because the Brazilian Internet Civil Rights Framework requires it.
sections 3.3 and 11Questions about this policy and requests to access, correct or delete data: contact@raizelo.com. This is also the contact channel for the data protection officer, and you can use it to exercise all the rights granted to you by the LGPD.
sections 10 and 12This Privacy Policy describes how completIn Devs, registered under Brazilian corporate taxpayer number (CNPJ) 40.219.142/0001-69, with its registered office at Rua Afrânio Peixoto, 2211, Bairro São José, Divinópolis/MG, CEP 35501-284 ("Raizelo", "we"), processes personal data within the Raizelo platform, accessible at raizelo.com and through its API (the "Service"), in accordance with Law No. 13,709/2018 — the Brazilian General Data Protection Law ("LGPD") — and other applicable rules.
By creating an account, using the API or accessing the public verification page, you declare that you have read and understood this Policy.
Raizelo provides proof of document integrity and existence. The client sends our API only the cryptographic hash (SHA-256) of a file — a sequence of 64 characters that acts as a mathematical fingerprint of its contents. Raizelo groups these hashes into batches and publishes a single cryptographic digest per batch (a Merkle tree root) on a public blockchain network, creating a record of date and integrity that anyone can verify.
This architecture entails commitments that are not commercial promises, but deliberate technical limitations of the Service ("privacy by architecture"):
2.1. Account, usage and browsing data. For the data described in sections 3.1, 3.3 and 3.4 — including the public issuer name (section 5.1) — Raizelo acts as the controller, as defined in Article 5, VI, of the LGPD.
2.2. Documents and metadata submitted by the client. The documents whose hashes are registered belong to the client and remain under their exclusive control. The client is the controller of any personal data that may be contained in those documents and in the metadata they choose to associate with each proof (the "label" field). In this context, Raizelo acts as a processor (Article 5, VII, of the LGPD), processing such information exclusively in accordance with the client's instructions as expressed through use of the API and this Policy.
2.3. The client's responsibilities as controller. The client declares and warrants that: (a) they have an appropriate legal basis for processing the data contained in the documents they hash; and (b) they will not insert unnecessary personal data into metadata fields (particularly the "label" field).
| Data | Purpose | Legal basis (LGPD, Article 7) |
|---|---|---|
| Name and email address | Account creation and identification; operational communications | Performance of a contract (V) |
| API keys (stored exclusively as hashes) | Request authentication | Performance of a contract (V) |
| Public issuer name (optional — see section 5.1) | Public display of the issuer in the verification result | Performance of a contract (V), upon express request |
The Service does not use passwords: authentication is exclusively through an API key, which is displayed only once when created and stored by us only as a hash.
We do not currently collect billing or payment data. Before billing features are launched, this Policy will be updated to describe the relevant tax and payment data and their legal bases.
| Data | Purpose | Notes |
|---|---|---|
| Document SHA-256 hash | Proof registration, anchoring and verification | One-way; does not reveal contents |
| "label" field (optional) | The client's internal reference for locating their proofs | Private: never displayed on the public verification page |
| Dates, batch identifiers and counts, leaves and Merkle proofs, blockchain transaction references | Composition of the verifiable cryptographic receipt | Mathematical and operational data |
| Data | Purpose | Legal basis |
|---|---|---|
| IP address, date/time, resource accessed, user-agent | Security, fraud and abuse prevention, auditing and diagnostics | Legitimate interest (IX), limited to the minimum necessary |
Access to the public verification page does not require an account. For request rate limiting, per-origin counters are held only in memory, in short windows, without persistence. Separately, application access records (logs) are retained for the period specified in section 8, in compliance with the Brazilian Internet Civil Rights Framework (Marco Civil da Internet).
Operational email communications (service, security and support notices), when sent, are inherent to the Service (performance of a contract). News or marketing communications, if any, will be sent only with consent, which may be withdrawn at any time through the unsubscribe link or the contact channel in section 12.
The home page provides a public contact form that does not require an account.
| Data | Purpose | Legal basis (LGPD, Article 7) |
|---|---|---|
| Submitted email address and message contents | Receiving and responding to contact initiated by the data subject | Preliminary procedures relating to a contract, at the data subject's request (V); and, where the contact does not concern contracting, legitimate interest in responding to those who write to us (IX) |
We do not store these messages. The form does not write to a database: the message is validated, forwarded by email to the address in section 12, and discarded by the application. The submitted address and message contents are also not recorded in application logs. Once sent, the message exists in the recipient's mailbox and in the records of the email delivery provider identified in sections 6 and 7, subject to that provider's retention policies.
The email address submitted through the form is not verified and is used only to respond to that contact: it is not added to a mailing list, matched against account data or shared with third parties other than the delivery provider.
To prevent abuse of the form, we apply per-origin rate limiting on the same terms as section 3.3 — counters only in memory, in short windows, without persistence.
4.1. What is recorded on the blockchain. Exclusively: each batch's Merkle root (a 32-byte value derived mathematically from that batch's proofs), the number of proofs in the batch, and technical transaction metadata. Labels, names, client identifiers and any personal data are not published.
Batch size varies with volume: anchoring takes place in periodic cycles, using the proofs in the queue, up to an operational limit per batch. When a batch contains only one proof, the published value is derived only from that document — in a one-way process that does not reveal the document or any information it contains to anyone who does not possess it.
4.2. Immutability. Records on a public blockchain are permanent by nature and cannot be altered or deleted by us or by third parties. What we publish contains no personal data, names, labels or document contents, and nothing in it allows anyone who does not possess a document to identify it.
Someone who already possesses the document and its corresponding receipt, however, can independently confirm that it was anchored and on what date. This is precisely the contracted purpose of the Service: verification does not depend on us and, for that very reason, is not reversed by deleting our records. The deletion described in section 8 covers everything under our control; it does not cover — because nobody can — a record already published on a public network.
4.3. Contract queries. Raizelo's smart contract is public and may be queried independently by anyone, as part of the Service's commitment to verifiability. These queries take place directly on the blockchain network and outside Raizelo's systems.
Anyone who possesses a document's hash (for example, through a QR code printed on a certificate) may consult the public verification page. It displays: the queried hash, proof status (verified, pending or not found), dates, technical anchoring data — such as batch identifier and count, leaf and Merkle proof, transaction, contract and network — and the public issuer name, only when the client has requested its display (section 5.1).
Never displayed: the file name or contents, the "label" field, internal client identifiers, email addresses or any account registration data.
The public issuer name is a single attribute of the client's account, disabled by default and enabled only upon express request. Before requesting activation, the client must be aware that:
By requesting activation, the client declares that they are authorized to make the specified name public.
We do not sell, rent or trade personal data. We share data only with:
All contracted processors are subject to contractual confidentiality and security obligations consistent with the LGPD. When billing features are launched, the payment institution involved will be included in this section.
International data transfers take place, under Article 33 of the LGPD, to:
We adopt appropriate safeguards — including contractual clauses and compliance mechanisms offered by the providers — to ensure a level of protection equivalent to that required by Brazilian law. Communications between systems are encrypted in transit.
8.1. General rule. We retain personal data only for as long as necessary for the purposes of this Policy, subject to statutory retention periods.
8.2. Specific periods.
| Category | Retention |
|---|---|
| Account data | While the account is active; deleted or anonymized after closure, subject to legal exceptions and the public issuer name exception (sections 5.1 and 8.4) |
| Application access records (logs) | At least 6 (six) months, under Article 15 of the Brazilian Internet Civil Rights Framework (Law No. 12,965/2014); additional operational logs for the shortest necessary period |
| Public contact form messages (section 3.5) | Not retained by the application: forwarded by email and discarded. They remain in the recipient's mailbox for as long as necessary to respond, and in the delivery provider's records |
| Proofs, hashes and cryptographic receipts | While the proof is active (see 8.3) |
8.3. Preservation is the nature of the Service. Raizelo's contracted purpose is to keep proofs verifiable over time. Hashes, Merkle proofs and receipts are therefore retained while the client keeps their proofs active. The client may request deletion of specific proofs or all their proofs at any time, aware of the consequence: a deleted proof can no longer be verified through our public page or our records, and will return the "not found" status. Anyone who has kept the document and its corresponding cryptographic receipt retains the ability to verify it directly on the blockchain network, independently of Raizelo — as described in section 4, without involving any personal data. The previously published aggregate root remains on the network because it is immutable.
8.4. Public issuer name after account closure. If the client has activated display of the public issuer name, it continues after the account is closed, for the purpose described in section 5.1, unless deactivation is expressly requested — which may be done at any time, including after closure, through the contact channel in section 12.
We adopt technical and administrative measures proportionate to the risks, including: encryption in transit (TLS) for Service communications, including the database connection; authentication exclusively through API keys, stored only as hashes; segregation of processes and credentials by service; the principle of least privilege for infrastructure access; request rate limiting on the Service's public interfaces; automatic, periodic database backups; and the product's own design, which eliminates the most serious class of risk by never receiving document contents.
No system is invulnerable. If a security incident could cause significant risk or harm to data subjects, we will notify the Brazilian National Data Protection Authority (ANPD) and affected data subjects, under Article 48 of the LGPD.
Under Article 18 of the LGPD, you may request: confirmation that processing exists; access to data; correction of incomplete, inaccurate or outdated data; anonymization, blocking or deletion of unnecessary, excessive or unlawfully processed data; portability; information about sharing; information about the possibility of withholding consent and its consequences; and withdrawal of consent where it is the legal basis for processing.
Requests will be handled within the periods established by the LGPD and ANPD regulations, through the channel identified in section 12. Where Raizelo acts as a processor (section 2.2), we will forward the request to the client controller or advise the data subject to contact them, providing appropriate support.
The Service does not use tracking, advertising, behavioral analytics or audience measurement cookies, nor does it use pixels, fingerprinting or equivalent technologies. There is no authentication cookie: the Service has no logged-in area, and the API is authenticated by key, without a session.
There is one strictly necessary cookie, only on the home page:
| Cookie | Where | Purpose | Duration | Attributes |
|---|---|---|---|---|
| `.AspNetCore.Antiforgery.<suffix>` | Only on the home page (`/`), because it contains the contact form in section 3.5 | Protection against cross-site request forgery (CSRF): ensures a form submission originates from this page rather than a third-party site | Session cookie — deleted when the browser closes; no expiration date | `HttpOnly`, `SameSite=Strict`, `Path=/` |
This cookie contains only a cryptographic token linked to the request. It carries no person identifier, is not read by JavaScript, does not follow the visitor across sites, and is used only for anti-CSRF verification. Because it is strictly necessary for the security of a feature the data subject chooses to use, its use is based on legitimate interest in security (Article 7, IX, of the LGPD) and does not depend on consent.
The public verification page (`/verify/…`), this Policy page and the API do not send any cookies — they remain entirely cookie-free, which can be checked by inspecting the response headers of those routes.
If a future feature requires other cookies, this section will be updated.
Raizelo's officer responsible for personal data processing may be contacted at:
Email: contact@raizelo.com Officer: William Nascimento
This is the channel for exercising rights, asking questions about this Policy and communicating about data protection. You may also submit complaints to the ANPD (gov.br/anpd).
The Service is intended for professional and business use and is not directed at anyone under 18. We do not intentionally collect data from children or adolescents; if we identify an account in that situation, it will be closed and the data deleted.
This Policy may be updated to reflect changes to the Service or the law. The current version will always be published at raizelo.com/privacidade, with its last-updated date at the top. For material changes, we will make reasonable efforts to notify clients through their registered contact channels.
This Policy is governed by the laws of the Federative Republic of Brazil. The courts of the judicial district of Divinópolis, State of Minas Gerais, are designated to resolve disputes arising from this Policy, without prejudice to legally established protective jurisdictions.
