-
Notifications
You must be signed in to change notification settings - Fork 0
DATA_PRIVACY.md
CeloHT is committed to protecting personal information and minimizing unnecessary data collection across its applications, websites, educational programs, agent network, community activities, and blockchain integrations.
CeloHT's privacy architecture is based on the principle that personal information should only be collected, processed, stored, and shared when there is a legitimate operational, security, legal, or service-related reason.
Because CeloHT operates within a Web3 environment, privacy must address both conventional application data and publicly visible blockchain data.
CeloHT therefore distinguishes between:
Personal information
Account information
Operational information
Blockchain information
Public information
Security and audit information
CeloHT follows these core privacy principles:
Data minimization
Purpose limitation
Transparency
Security by design
Privacy by default
Limited retention
Controlled access
User rights
Responsible data sharing
Protection against unauthorized disclosure
CeloHT should collect only information necessary for the specific service being provided.
Examples of potentially necessary information include:
Name
Contact information
Account identifier
Wallet address
Training information
Agent information
Transaction-related information
Community participation information
CeloHT should avoid collecting information that is not required for the stated purpose.
CeloHT may process several categories of information.
Examples:
Name
Email address
Username
Account identifiers
Authentication metadata
Examples:
Public wallet address
Blockchain network
Transaction hashes
On-chain activity associated with a wallet
Wallet addresses are public blockchain identifiers but may still be treated as potentially sensitive identifiers within application systems.
CeloHT must never request or store:
Seed phrases
Private keys
Recovery phrases
Secret signing credentials
Where educational services are provided, CeloHT may process:
Course participation
Training completion
Assessment results
Training dates
Community or program participation
Educational information should only be accessible to authorized personnel and systems.
Agent-related information may include:
Agent identity
Operational status
Service area
Transaction activity
Performance metrics
Training status
Access should be restricted according to operational requirements.
Transaction-related information may include:
Transaction hash
Wallet addresses
Amount
Asset
Timestamp
Network
Transaction status
Agent identifier where applicable
Blockchain transactions may be publicly visible by their nature.
CeloHT must not represent blockchain data as private when it is inherently public.
Blockchain technology creates unique privacy considerations.
Transactions recorded on a public blockchain may remain publicly accessible indefinitely.
Therefore:
Blockchain Transparency
≠
Complete Personal Privacy
CeloHT should avoid placing unnecessary personal information directly on-chain.
Personal information should generally not be written directly to blockchain transactions or smart-contract storage unless there is a clearly justified reason.
For example, CeloHT should avoid storing:
Full names
Email addresses
Phone numbers
Home addresses
Identity documents
Private notes
directly on a public blockchain.
Where verification is required, the system should consider privacy-preserving alternatives.
Where appropriate, CeloHT should separate personal data from blockchain records.
Conceptually:
CeloHT Application
|
+---------+---------+
| |
v v
Private Data Blockchain Data
| |
v v
Secure DB Celo Network
The blockchain should store only the minimum information required for decentralized functionality.
A wallet address may not directly contain a person's name, but blockchain analysis can sometimes associate an address with an identifiable individual.
Therefore, CeloHT should avoid assuming that wallet addresses are completely anonymous.
Internal systems should handle wallet addresses responsibly.
Before collecting personal information, CeloHT should determine:
Why the information is required
What service requires it
Who needs access
How long it should be retained
Whether the information can be avoided
Whether the information must be shared
Collection mechanisms should provide appropriate notices where required.
Data collected for one purpose should not automatically be reused for unrelated purposes.
For example:
Training Registration
|
v
Training Administration
does not automatically authorize the information to be used for unrelated marketing or commercial purposes.
Additional use should be appropriately justified and disclosed.
Where consent is the appropriate legal basis for processing, CeloHT should obtain consent through clear and understandable mechanisms.
Consent mechanisms should:
Explain the relevant purpose
Avoid deceptive language
Avoid unnecessary complexity
Allow withdrawal where applicable
Maintain appropriate records
Consent should not be assumed simply because a user interacts with a public website.
Depending on the jurisdiction and activity, personal data processing may rely on different legal bases.
Potential legal bases may include:
Consent
Contractual necessity
Legal obligation
Legitimate interests
Protection of vital interests
Other legally recognized grounds
The applicable basis should be determined according to the relevant jurisdiction and activity.
CeloHT should not claim a specific legal basis without appropriate legal assessment.
Where applicable under relevant privacy laws, individuals may have rights concerning their personal information.
Potential rights include:
Right to access
Right to correction
Right to deletion
Right to restriction
Right to data portability
Right to object
Right to withdraw consent
The availability and scope of these rights depend on the applicable law and circumstances.
Blockchain immutability creates an important distinction.
A user may request deletion of personal information from CeloHT-controlled systems, but information already permanently recorded on a public blockchain may not be technically removable.
Therefore, CeloHT should minimize personal information written on-chain.
Privacy architecture should assume that blockchain records may remain permanently accessible.
CeloHT should retain personal information only for as long as necessary for its intended purpose or as required by applicable law.
Retention periods should consider:
Operational requirements
Security requirements
Legal obligations
Financial records
Audit requirements
User rights
When information is no longer required, it should be securely deleted or anonymized where appropriate.
Deletion procedures should address all systems under CeloHT's control where applicable.
Potential locations include:
Production databases
Application storage
Backups
Analytics systems
Customer-support systems
Internal tools
Blockchain records are treated separately because public blockchain data may be immutable.
Where full personal information is not required, CeloHT may use anonymization or pseudonymization techniques.
Examples:
Full Name
|
v
Pseudonymous Identifier
or:
Individual Records
|
v
Aggregated Statistics
Aggregated reporting can reduce exposure of individual information.
Personal information must be protected using appropriate authorization controls.
Access should follow:
Need to Know
+
Least Privilege
+
Role-Based Access
Employees, contributors, agents, developers, and administrators should not receive unrestricted access to personal data simply because they have access to the platform.
Administrative access to personal information should be:
Restricted
Audited
Justified
Revocable
Reviewed periodically
Privileged users should only access information required for their responsibilities.
Sensitive information should be protected using appropriate encryption.
Communications should use secure encrypted protocols such as HTTPS/TLS.
Sensitive stored information should use appropriate encryption mechanisms where practical.
Passwords and authentication secrets must never be stored in plaintext.
If CeloHT supports password-based authentication, passwords must be securely hashed using an appropriate password-hashing algorithm.
CeloHT must never store plaintext passwords.
Password reset mechanisms must also be designed to prevent account takeover.
APIs must not expose personal information unnecessarily.
API responses should return only the fields required for the requesting operation.
For example:
Bad:
Return complete user database record
Better:
Return only required profile fields
Sensitive fields should require explicit authorization.
Logs can contain sensitive information and must therefore be treated carefully.
Logs should not contain:
Passwords
Private keys
Seed phrases
Authentication tokens
Recovery codes
Unnecessary personal information
Where possible, identifiers should be minimized or pseudonymized.
Analytics systems should collect only information required to understand product and service performance.
Where possible, CeloHT should prefer:
Aggregated metrics
Anonymous usage statistics
Pseudonymous identifiers
Limited retention periods
Analytics should not become an unnecessary surveillance mechanism.
If CeloHT uses cookies or similar technologies, the implementation should clearly distinguish between:
Essential functionality
Security
Analytics
Preferences
Marketing or advertising
Tracking technologies should comply with applicable legal requirements.
CeloHT may integrate with external services such as:
Blockchain infrastructure providers
Wallet providers
Cloud services
Analytics providers
Communication services
Development platforms
Before sharing personal information with a third party, CeloHT should assess:
What information is shared
Why it is shared
Security practices
Data retention
Applicable legal requirements
Contractual safeguards where appropriate
Wallet providers may process information independently from CeloHT.
For example, a wallet application may have its own:
Privacy policy
Data collection practices
Security model
Transaction infrastructure
CeloHT should clearly distinguish CeloHT-controlled processing from third-party processing.
CeloHT may operate across multiple countries and communities.
Where personal information crosses national borders, applicable requirements concerning international data transfers should be evaluated.
Appropriate contractual, technical, or organizational safeguards may be required depending on the jurisdictions involved.
CeloHT educational initiatives may reach young people.
Where services involve children or minors, additional safeguards may be necessary.
CeloHT should consider:
Age requirements
Appropriate consent mechanisms
Parental or guardian requirements where applicable
Data minimization
Limited profiling
Restricted public disclosure
The applicable legal requirements depend on the jurisdiction.
CeloHT should avoid collecting sensitive personal information unless there is a clearly justified and legally appropriate reason.
Examples may include:
Government identification documents
Financial account credentials
Biometric information
Precise location information
Health information
Other specially protected information
If sensitive information must be processed, stronger controls should apply.
A suspected privacy breach should trigger an incident-response process.
The process should include:
Identify the affected system.
Contain the incident.
Determine the information affected.
Assess potential impact.
Secure compromised credentials.
Preserve relevant evidence.
Determine notification obligations.
Notify affected parties where required.
Remediate the vulnerability.
Document lessons learned.
Privacy should be incorporated during system design rather than added after development.
A privacy review should occur when introducing:
New user data
New analytics
New integrations
New blockchain functionality
New agent services
New educational programs
New authentication mechanisms
Default settings should minimize unnecessary exposure.
Examples:
Private Profile
|
v
Public Only When Explicitly Chosen
and:
Minimum Data Collection
|
v
Expanded Collection Only When Justified
CeloHT should classify information according to sensitivity.
A possible model is:
| Classification | Example |
|---|---|
| Public | Public documentation |
| Internal | Internal operational information |
| Confidential | User records |
| Highly Confidential | Credentials and security secrets |
Privacy responsibilities should be assigned clearly.
Relevant responsibilities may include:
Defines what information is required.
Implements technical privacy controls.
Protects data against unauthorized access.
Manage access according to policy.
Provides oversight for major policy decisions.
Control the information they voluntarily provide within the limits of the platform and applicable law.
CeloHT should maintain appropriate public-facing privacy documentation.
Documentation should explain, as applicable:
What information is collected
Why it is collected
How it is used
How it is protected
Whether information is shared
Blockchain-specific privacy limitations
User rights
Contact mechanisms
The public privacy policy should remain consistent with actual system behavior.
CeloHT recognizes that Web3 combines transparency with privacy challenges.
The design objective is therefore not to hide blockchain activity but to avoid unnecessarily linking personal information to public blockchain records.
The architecture should favor:
Public Blockchain Transparency
+
Private Personal Data
+
Minimal On-Chain Personal Information
Before launching a feature that processes personal information:
[ ] Purpose documented
[ ] Data requirements identified
[ ] Unnecessary fields removed
[ ] Data classification completed
[ ] Access controls implemented
[ ] Encryption reviewed
[ ] Retention period defined
[ ] Deletion process defined
[ ] Logging reviewed
[ ] Third-party sharing reviewed
[ ] Blockchain exposure assessed
[ ] Privacy risks assessed
[ ] User notice prepared where required
[ ] Security review completed
Privacy is not a one-time implementation task.
CeloHT should periodically review:
Data collection
Data retention
Access permissions
Third-party integrations
Blockchain exposure
Analytics
Security controls
User requests
Applicable legal requirements
Changes in the platform may require updates to privacy documentation.
Privacy and security are closely related but not identical.
Security protects information against unauthorized access, alteration, or destruction.
Privacy governs how information is collected, used, shared, retained, and disclosed.
CeloHT must address both.
Privacy depends on strong identity and access controls.
Related systems include:
Authentication
|
v
Identity
|
v
Authorization
|
v
Data Access
|
v
Privacy Protection
Authentication and authorization failures can therefore become privacy failures.
Blockchain security protects the integrity of on-chain systems.
Privacy architecture determines what information should be placed on those systems.
These concerns must be considered together before deploying new smart-contract functionality.
Privacy incidents should be incorporated into CeloHT's broader incident-response framework.
The response process should consider:
Technical impact
Data affected
Number of affected individuals
Geographic scope
Legal requirements
Blockchain implications
Notification requirements
Corrective measures
CeloHT's privacy architecture is based on a simple principle:
Collect less, protect what is collected, and never place unnecessary personal information on a public blockchain.
The platform should continuously improve privacy controls as its technology, community, geographic reach, and regulatory environment evolve.
AUTHENTICATION_ARCHITECTURE.mdAUTHORIZATION_MODEL.mdSMART_CONTRACT_SECURITY.mdSECURITY.mdBLOCKCHAIN_INTEGRATION.mdAPI_ARCHITECTURE.mdENVIRONMENT_CONFIGURATION.mdGOVERNANCE.md
Document: Data Privacy
Project: CeloHT
Classification: Privacy / Security Documentation
Status: Privacy Architecture Reference
© 2026 CeloHT - Open Source. Global Impact. Licensed under Apache.