-
Notifications
You must be signed in to change notification settings - Fork 0
TRANSPARENCY.md
Document Type: Transparency & Accountability Framework Project: CeloHT Status: Active / Evolving Last Updated: August 2026 Authors: Johnny Dubic & CeloHT Community
Transparency is a core principle of CeloHT.
CeloHT aims to provide users, contributors, partners, researchers, sponsors, and the broader community with accurate and understandable information about:
- The project
- Its governance
- Its technology
- Its finances
- Its programs
- Its partnerships
- Its impact
- Its risks
- Its development
Transparency does not mean publishing every piece of information.
Sensitive information must remain protected when disclosure could create security, privacy, legal, or operational risks.
CeloHT follows these principles:
- Accuracy
- Accountability
- Verifiability
- Timeliness
- Accessibility
- Privacy
- Security
- Honest uncertainty
Transparency means making important project information available in a way that allows people to understand:
What CeloHT does, who contributes to it, how systems work, how resources are managed, what results have been achieved, and what risks remain.
CeloHT maintains public documentation covering areas such as:
- Architecture
- Governance
- Security
- Technology
- Programs
- Roadmaps
- Smart contracts
- Treasury
- Research
- Performance
- Impact
Documentation should be updated when material changes occur.
Where appropriate, CeloHT publishes software and documentation through public repositories.
Open-source development can allow:
- Community review
- Technical contributions
- Security research
- Reproducibility
- Independent analysis
Open source does not eliminate security risks, but it can improve accountability.
CeloHT should document important governance mechanisms.
This includes:
- Proposal processes
- Voting procedures
- Working groups
- Governance responsibilities
- Decision records
- Applicable rules
See:
GOVERNANCE.mdVOTING_SYSTEM.mdWORKING_GROUPS.md
Material decisions should include appropriate documentation of:
- The decision
- Context
- Alternatives
- Rationale
- Responsible participants
- Expected consequences
Not every operational decision requires public documentation.
CeloHT should provide appropriate information regarding significant financial activity.
Where practical, reporting may include:
- Funding received
- Major expenditures
- Program allocations
- Treasury activity
- Sponsorships
- Grants
- Material financial commitments
Treasury resources should be managed according to established controls.
Where blockchain assets are held on-chain, appropriate public addresses may be disclosed when doing so does not create unacceptable security risks.
See:
TREASURY.md
Material sponsorship relationships should be disclosed appropriately.
Public information may include:
- Sponsor
- Sponsorship type
- Supported program
- Period
- Material restrictions
See:
SPONSORS.md
CeloHT should distinguish between:
- Revenue
- Donations
- Grants
- Sponsorship
- Investments
- In-kind contributions
These categories should not be presented interchangeably.
CeloHT maintains a no-proprietary-token policy.
The project should not imply that users must purchase a CeloHT token to participate.
See:
NO_TOKEN_POLICY.md
Production smart contracts should be documented where applicable.
Information may include:
- Contract name
- Network
- Address
- Version
- Source repository
- Verification status
- Security review
See:
SMART_CONTRACTS.md
Where supported, deployed contracts should be verified through appropriate blockchain explorers.
Verification helps users and researchers compare deployed code with published source.
CeloHT should communicate significant security issues responsibly.
Public disclosure should balance:
- User protection
- Vulnerability remediation
- Researcher safety
- Operational security
See:
SECURITY.mdSECURITY_AUDITS.md
If an independent security audit is completed, CeloHT should publish appropriate information about:
- Auditor
- Scope
- Date
- Version
- Findings
- Remediation status
An audit should not be represented as proof that a system is completely secure.
Security researchers should have an appropriate way to report vulnerabilities.
CeloHT should encourage responsible disclosure.
Public disclosure of an unresolved critical vulnerability may unnecessarily expose users and should be handled carefully.
CeloHT should accurately distinguish:
- Founder
- Contributors
- Maintainers
- Volunteers
- Advisors
- Partners
- Sponsors
The project should never fabricate team members or professional credentials.
See:
TEAM.md
CeloHT identifies Johnny Dubic as its founder.
Founder status should not be represented as equivalent to unrestricted control over all community decisions.
Contributors may be publicly recognized based on actual participation.
Public profiles should not contain personal information without appropriate consent.
Material partnerships should be described accurately.
A collaboration should not be represented as:
- An investment
- An endorsement
- A government relationship
- A formal partnership
unless that relationship actually exists.
CeloHT programs should communicate:
- Objectives
- Activities
- Participants where appropriate
- Results
- Limitations
- Funding where relevant
Education programs should distinguish between:
- People registered
- People attending
- People completing
- People demonstrating improved knowledge
These are different metrics.
Agent-related reporting may include:
- Number of active agents
- Communities served
- Supported services
- Transaction activity
Sensitive individual transaction information should remain private.
Environmental reporting should distinguish between:
- Trees planned
- Trees purchased
- Trees planted
- Trees maintained
- Trees surviving
CeloHT should not equate planting activity with verified carbon removal unless appropriate evidence exists.
Impact reporting should distinguish between:
Resources used.
Actions performed.
Immediate measurable results.
Changes resulting from the program.
Sustained effects over time.
Success stories should be:
- Authentic
- Evidence-based
- Consent-based
- Contextualized
CeloHT should never fabricate testimonials or impact stories.
See:
SUCCESS_STORIES.md
Important performance indicators may be published periodically.
Potential metrics include:
- Users
- Training
- Transactions
- Agents
- Revenue
- Programs
- Environmental activity
Metrics should include dates or measurement periods where relevant.
Public metrics should have clear definitions.
For example:
"Trained" should not automatically mean "completed training."
Definitions should be documented to prevent misleading comparisons.
If CeloHT discovers that published information is materially incorrect, the project should correct it.
Corrections should be made promptly.
Where appropriate, the correction should identify:
- What was incorrect
- What is correct
- When the correction occurred
Material historical information should not be silently rewritten to make past performance appear better.
Version history, changelogs, and archived reports can help preserve accountability.
Roadmaps should clearly distinguish between:
- Completed
- In progress
- Planned
- Delayed
- Cancelled
A roadmap is not a guarantee.
Research should document:
- Sources
- Methodology
- Assumptions
- Limitations
- Findings
Unsupported conclusions should not be presented as established facts.
CeloHT may publish aggregated data when doing so improves accountability.
Personal or sensitive data should not be published merely for the sake of transparency.
Transparency and privacy must be balanced.
CeloHT should follow the principle:
Publish what people need to verify the project; protect what people need to keep private.
Some operational information should remain restricted.
Examples may include:
- Private keys
- Passwords
- Authentication secrets
- Unpatched vulnerabilities
- Sensitive infrastructure details
Security-sensitive information should not be published simply because transparency is desirable.
CeloHT should communicate its legal status accurately.
Where legal status is uncertain or evolving, the project should say so rather than making unsupported legal claims.
See:
LEGAL_STATUS.md
Where relevant, CeloHT should monitor applicable legal and regulatory requirements.
The project should avoid presenting legal or regulatory interpretations as professional legal advice unless provided by qualified professionals.
Public statements should be:
- Accurate
- Consistent
- Verifiable
- Clear
Marketing should not override factual accuracy.
Investor and grant materials should distinguish between:
- Historical results
- Current metrics
- Forecasts
- Goals
- Assumptions
Projected outcomes should never be presented as guaranteed.
Community members should have reasonable access to important project information.
Material updates may be communicated through:
- GitHub
- Website
- Community channels
- Reports
- Public announcements
CeloHT may publish periodic transparency reports.
A report may include:
Governance
Security
Treasury
Programs
Education
Agents
Environment
Technology
Partnerships
Risks
Future Priorities
As infrastructure matures, CeloHT may provide a public dashboard containing selected metrics.
Potential sections:
- Community
- Education
- Transactions
- Agents
- Treasury
- Environment
- Development
Dashboard metrics should link to definitions and sources where practical.
Blockchain transactions are inherently observable on supported networks.
CeloHT should recognize that:
- Transaction history may be public.
- Wallet addresses may be publicly visible.
- Smart-contract activity may be independently analyzed.
Users should receive appropriate education about blockchain transparency.
Transparency depends on reliable data.
Before publishing important metrics, CeloHT should verify:
- Source
- Calculation
- Date range
- Units
- Duplicates
- Assumptions
CeloHT welcomes appropriate independent review of:
- Open-source code
- Public documentation
- Published metrics
- Smart contracts
- Research
- Program results
Independent review can improve credibility.
Community members should have appropriate channels for:
- Questions
- Corrections
- Suggestions
- Concerns
- Governance proposals
Feedback should be evaluated according to the relevant process.
No transparency system can eliminate uncertainty.
Information may be incomplete because of:
- Early-stage development
- Limited resources
- Data availability
- Privacy requirements
- Security restrictions
- External dependencies
CeloHT should communicate these limitations honestly.
Transparency practices should evolve as CeloHT grows.
Future improvements may include:
- Better dashboards
- More detailed treasury reporting
- Expanded team profiles
- Security disclosures
- Program-level metrics
- Independent audits
- Public research
Transparency is not a marketing feature.
It is an accountability mechanism.
CeloHT aims to build trust by making important information understandable, verifiable, and accessible while protecting legitimate privacy and security requirements.
The guiding principle is:
Be open about what is known, honest about what is uncertain, clear about what is planned, and accountable for what has been done.
Document Status: Active / Evolving Maintained By: CeloHT Community Founder: Johnny Dubic Transparency Principle: Evidence, accountability, privacy, and security
© 2026 CeloHT - Open Source. Global Impact. Licensed under Apache.