Hello!

My Vision: Why CRED Was Born We live in an age where the global economy has become a shared fiction—a perpetual bet on the future, propped up by unpayable debt and promises of value that don’t exist. Nations borrow from other indebted nations, fueling a spiral that has severed money from reality. And citizens pay the price of this illusion through inflation, instability, and a loss of real purchasing power.

I refuse to accept this.

I believe money must have meaning again. That value cannot be conjured out of nothing, but must be built with effort, time, and energy. That trust cannot be declared by decree—it must be earned, block by block, choice by choice.

From this realization, CRED was born.

Not as a commercial product. Not as a get-rich-quick token. CRED is a radical attempt to create something fair.

A network that asks no permission. A currency with no masters. A structure that cannot be corrupted, bought, or seized. A blockchain where anyone, even with a smartphone or an old PC, can participate. Where transactions cost nothing. Where value only exists if someone worked to create it.

My Vision for the World The world I envision is not ruled by central banks, opaque governments, or manipulated markets. It is made of distributed communities, radical transparency, and conscious choice.

A world where:

people understand what they use and why;

power is not concentrated but distributed;

debt is not a tool of control, but a rare and responsible exception;

privacy is not a luxury but a default right;

rules are clear, public, and immutable — written in code, not treaties.

I do not believe in violent revolutions. I do not believe in the salvation promised by big corporations or the next wave of “Big Tech.” I believe in silent, consistent, transparent work. And CRED is meant to be exactly that.

A small project—but an honest one. A minimal monetary system—but a real one. A concrete response to a global problem.

In Closing CRED is my personal answer to chaos. It’s my way of saying that even in the middle of the storm, it’s still possible to build something that holds. Something that lasts. Something that doesn’t demand trust—but earns it.

And if only a few believe in it, so be it. Because real strength doesn’t lie in numbers—it lies in consistency.

Welcome to the project. Or ignore it, if you wish. But know this: somewhere, someone really tried to change the rules. Not with words. With code.

— Mauro (skpoly)

I’m not capable of building this system on my own. I don’t have the technical skills—and maybe not even the time. But I do have a vision. One I believe is realistic, necessary, and urgent.

And I’d love for you, the person reading these lines, to help make it real.

If this resonates with you—if you, too, feel there’s something deeply broken in the current system—don’t stay on the sidelines. Reach out. Let’s talk. I’ll do everything I can, in my own small way, to support you.

I have nothing to sell. I ask for nothing. Just this: don’t let this possibility go unspoken.

And now... my idea:

ABSTRACT CRED Standard is a decentralized blockchain designed to serve as an accessible, secure, and sustainable digital store of value. The protocol is based on an ASIC-resistant Proof of Work algorithm, optimized for operation on consumer-grade hardware such as standard CPUs and GPUs, thus promoting true equity in mining participation. It supports lightweight nodes on smartphones via SPV, enabling widespread adoption and global decentralization. Transactions are free for users, thanks to a dynamic reward mechanism that incentivizes miners without direct user fees.

The tokenomics is built on slow, programmed scarcity, with no pre-mines, ICOs, or privileged distributions. The project rejects any form of centralized governance and promotes open-source code that is immutable and verifiable by anyone. In a context of increasing distrust and centralization, CRED Standard offers a simple, fair, and resilient alternative.

1. Blockchain Overview

2. Abstract

3. Introduction

4. The Problem

5. Proposed Solution

6. Technical Architecture
   6.1. Consensus Mechanism: Anti-ASIC Proof of Work
   6.2. Node Structure
   6.3. Security
   6.4. Transactions
   6.5. Transaction Lifecycle Example

7. Technical Summary for Developers

8. Protocol Technical Specifications
   8.1. Block Structure
   8.2. Transaction Format
   8.3. Consensus Algorithm
   8.4. Cryptography and Hashing
   8.5. Compatibility and Minimum Requirements
   8.6. Protocol Overview

9. Tokenomics
   9.1. Emission
   9.2. Scheduled Block Time Transition
   9.3. Incentives
   9.4. Sustainability

10. Competitive Advantages
    10.1. True Decentralization
    10.2. Free Transactions
    10.3. Long-Term Sustainability
    10.4. Modular Privacy
    10.5. Simplicity and Transparency
    10.6. Incentives for Light Nodes

11. Roadmap

12. Team and Governance
    12.1. No On-chain or Off-chain Governance
    12.2. Anonymity and Open Contribution

13. Legal and Compliance Aspects
    13.1. No ICO, IEO or Public Sale
    13.2. Open Source, Neutral Protocol
    13.3. Global Compliance
    13.4. Disclaimer

14. Conclusion
    14.1. A Look Ahead: Credix

15. Long-Term Vision

16. Contributions and License

17. INTRODUCTION In recent years, the growing adoption of blockchain technologies has highlighted not only the extraordinary potential of this decentralized paradigm but also the structural and philosophical limitations of many existing implementations. These include issues of scalability, hidden centralization, high transaction costs, and general difficulty in reconciling privacy, transparency, and ease of use.

This whitepaper introduces a new blockchain designed to serve as a resilient, transparent, and independent digital store of value. The primary objective is to build a decentralized infrastructure that is accessible to anyone, inherently secure, and sustainable in the long term—placing a strong emphasis on the balance between technical efficiency, equitable access, and cryptographic robustness.

The protocol has been engineered to operate efficiently even on non-specialized hardware, including consumer-grade CPUs and mobile devices, to maximize decentralization and reduce both technical and financial barriers to entry. The network adopts a hybrid model, with full nodes on PCs and lightweight nodes on smartphones, ensuring interoperability and low overhead.

At the core of the design is a Proof of Work (PoW) consensus mechanism optimized to resist ASICs, thus promoting a fair distribution of mining power and mitigating centralization risks. The system is complemented by a tokenomics model based on slow, programmed scarcity—aimed at ensuring long-term value without compromising initial accessibility.

The name CRED Standard is a deliberate reference to the Gold Standard, the monetary system that for over a century tied the value of fiat currencies to a tangible and verifiable reserve.

Similarly, CRED Standard proposes itself as a new decentralized base for digital value, anchored to programmed scarcity, transparent code, and distributed trust.

“CRED” evokes credibility, trust, and social credit, while “Standard” reflects the ambition to offer a stable, verifiable, and shared measure of value—intended to endure over time and beyond speculative dynamics.

In a world increasingly dominated by inflation, monetary manipulation, and systemic distrust, CRED Standard aspires to be what gold once was to past economies: a solid and impartial foundation for economic freedom and global cooperation.

2. THE PROBLEM Despite the presence of many established blockchains, the sector still suffers from structural weaknesses that hinder its effectiveness as a genuine alternative to centralized financial and computing systems. The most critical issues include:

Mining centralization: The widespread adoption of ASICs and the dominance of large mining pools have concentrated computational power in a few hands, undermining the original promise of decentralization.

High transaction costs: On many established networks, per-transaction fees have become prohibitive, discouraging everyday use and financial inclusion.

Limited node accessibility: The increasing complexity and high hardware requirements for running full nodes have excluded average users from actively participating in the network.

Transparency vs. privacy conflict: Many public blockchains offer full transaction transparency but lack native mechanisms for selective confidentiality, making it difficult to balance privacy and accountability.

Opaque or ambiguous governance: Several projects lack clear, democratic governance models, opening the door to centralized or arbitrary decision-making.

Excessive complexity: The proliferation of non-essential features and the adoption of technically sophisticated yet opaque mechanisms make many blockchains difficult to audit, understand, and use by the wider community.

These limitations prevent many blockchains from serving as truly democratic, transparent, and lasting tools. The project presented here was conceived with the explicit goal of directly and systematically addressing these critical issues.

3. PROPOSED SOLUTION The proposed blockchain offers a concrete and targeted response to the key problems afflicting current distributed systems. It has been designed to serve as a digital infrastructure that is essential, robust, and durable—with the declared objective of becoming a decentralized, censorship-resistant, and globally accessible store of value.

The protocol is founded on the following pillars:

a. True Decentralization The system is designed to run on consumer-grade hardware, avoiding reliance on ASICs or specialized configurations. The network comprises:

Full nodes: Run on desktop PCs and standard servers, maintaining the full blockchain and actively participating in consensus.

Light nodes: Run on smartphones and low-resource devices, verifying only the latest part of the blockchain and relying on selected full nodes for validation while maintaining security via SPV (Simplified Payment Verification).

b. Anti-ASIC Proof of Work Consensus The protocol uses a Proof of Work algorithm specifically designed to resist ASIC optimization, thereby promoting fair participation by users equipped with standard CPUs and GPUs. Block time is set to 2.5 minutes, balancing efficiency and security.

c. Free Transactions with Dynamic Reward per Transaction The system imposes no fees on users, instead employing a mechanism called dynamic reward per transaction:

Each transaction included in a block generates a small additional reward for the miner, calculated at the protocol level.

This incentive comes directly from monetary issuance—not from user fees.

In case of network congestion, users may include optional fees to increase priority, maintaining universal accessibility.

The mechanism also acts as an anti-spam measure, as each transaction carries a computational cost.

d. Programmed Scarcity The tokenomics is structured to favor long-term appreciation, with an initial block reward of 50 units, halving every 500,000 blocks. This model slows the emission curve compared to other cryptocurrencies, encouraging holding and reducing inflation. e. Modular Privacy The protocol includes optional mechanisms for selective transaction confidentiality, allowing users to choose whether to make certain transaction details public or anonymous—respecting legality and controlled transparency.

f. Simplicity and Auditability The blockchain code will be open source, readable, and documented—ensuring public auditability, continuous community review, and ease of adoption by independent developers. 4. TECHNICAL ARCHITECTURE The architecture of the proposed blockchain is designed to ensure robustness, scalability, accessibility, and security. Every component is built around principles of essentiality, auditability, and sustainability.

4.1. CONSENSUS MECHANISM: ANTI-ASIC PROOF OF WORK The protocol adopts a Proof of Work algorithm specifically designed to resist ASIC-based optimization, favoring the use of consumer-grade CPUs and GPUs. The algorithm is characterized by high memory intensity and computational variability, making the development of dedicated hardware economically disadvantageous, thus preserving fair mining distribution.

Average block time: 2.5 minutes

Proposed algorithm: [Name TBD] – derived from or inspired by RandomX/ProgPoW (customizable)

Difficulty target: dynamically adjusted every N blocks to maintain average block intervals

4.2. NODE STRUCTURE The network is composed of two distinct but interoperable categories of nodes:

a. Full Nodes Store the complete blockchain history

Perform full validation of transactions and blocks

Participate actively in consensus (via mining or passive validation)

Require moderate disk space and computational resources

Form the foundation of network security and integrity

b. Light Nodes Store only the headers of the last 2048 blocks to minimize resource usage on mobile devices

Verify transactions using SPV (Simplified Payment Verification), through cryptographic proofs provided by full nodes

Do not directly participate in consensus, but allow users to independently verify the legitimacy of their own transactions

Can interact with multiple full nodes, using a quorum-based model to enhance trust and mitigate censorship Note: While light nodes do not receive direct rewards from the consensus protocol, they may benefit from external incentive systems such as: – Integrated rewards in mobile wallets – Micropayments for relaying, validation, or network support – Airdrops or cashback for active users

These mechanisms, implementable at higher layers (apps, network services, Layer 2), aim to:

Promote widespread deployment of light nodes

Incentivize active participation even from non-technical users or those without specialized hardware

Maximize network decentralization, making the blockchain truly global, distributed, and censorship-resistant

4.3. SECURITY Security is ensured by a synergistic set of components:

Immutability: Each block is cryptographically linked to the previous one via hash, ensuring chain integrity

Geographic distribution of nodes: The ease of running nodes on generic hardware reduces the risk of centralized attacks

Double-spending protection: Ensured by the PoW mechanism and full node synchronization

Light node validation: Although they do not hold the full chain, they can independently verify transaction legitimacy, ensuring local trust

4.4. TRANSACTIONS Minimal format: input, output, timestamp, digital signature

Support for multi-output and multisig transactions

Optionally private transactions: via selective techniques (e.g., commitments, stealth addresses, ring signatures)

Automatic prioritization: based on mempool entry time and optional fee presence

Dynamic transaction reward: each transaction includes a bonus for the miner, funded from the issuance, not the user

4.5. TRANSACTION LIFECYCLE EXAMPLE The following steps describe the complete lifecycle of a user transaction on the CRED Standard network:

Transaction Creation The user opens their mobile wallet (light node), selects the recipient and amount. The wallet digitally signs the transaction and formats it according to protocol standards.

Transmission to Full Nodes The wallet sends the transaction to one or more selected full nodes via SPV channels. The full blockchain is not downloaded locally—only recent block headers are stored to validate node responses.

Mempool Verification The full node checks the transaction’s validity (signature, funds availability, format, privacy flags) and adds it to the mempool. Optional fees affect transaction priority.

Inclusion in Block A miner selects transactions from the mempool to build a new block, including the user’s transaction. Upon mining, the block assigns to the miner:

The base reward (e.g., 50 CRED)

A dynamic reward proportional to the number of transactions (not charged to users)

Propagation and Confirmation The block is propagated across the network. Once verified by nodes, the transaction is confirmed. The user’s wallet displays the status as “completed” after the first confirmation, with optional additional confirmations for higher security.

SPV Verification The light node verifies block inclusion via Merkle proofs provided by the full node, confirming transaction legitimacy even without access to the full blockchain.

Final State The recipient’s balance is updated. If the transaction was private (e.g., with stealth address or hidden output), only sender and recipient know the real details. The network still retains overall integrity and immutability. 5. TECHNICAL SUMMARY FOR DEVELOPERS This section provides a concise overview of the core technical elements relevant to developers and contributors interested in implementing, running nodes, or verifying the source code of CRED Standard.

Consensus Algorithm Proof of Work based on Yespower, designed to resist ASIC optimization. Memory-hard and CPU-friendly, compatible with consumer-grade hardware.

Implementation Language Core written in C++ (compatible with Bitcoin Core derivatives)

REST interfaces and extendable APIs

Lightweight components (e.g., light wallet) written in JavaScript / TypeScript, with mobile versions (Android/iOS) supported via native libraries

Distribution and Client Availability The codebase will be hosted on GitHub under an open-source license (MIT). Distributed components include:

CLI executables for Linux/Windows/macOS

Official Docker images for full node deployment

Mobile light wallet (planned for a subsequent phase)

Minimum Requirements for Full Nodes 64-bit dual-core CPU

4 GB RAM

50 GB disk space

Stable internet connection with a public IP (recommended)

Project Structure bash Copia Modifica /src → core source code (C++)
/docs → technical documentation
/scripts → CLI tools, build scripts, node management utilities
/wallet-light → JS/TS codebase for light wallet
/api → REST endpoints and OpenAPI documentation
/docker → Dockerfile and docker-compose files
/test → unit and integration test suite
This structure will be supported by a README.md guide, complete technical documentation (docs/spec.md), and quick installation instructions (install.md).

6. PROTOCOL TECHNICAL SPECIFICATIONS CRED Standard is designed to be easily verifiable, structurally robust, and consistent with principles of accessibility and transparency. Below are the core technical specifications. 6.1. BLOCK STRUCTURE Each block contains:

Version: block version number

Previous Block Hash: hash of the previous block (links the chain)

Merkle Root: root of the transaction tree

Timestamp: date and time of block creation

Difficulty Target: current difficulty level

Nonce: variable value used to find a valid hash

ExtraNonce: open field used for optional signatures or metadata

Transactions: list of all included transactions 6.2. TRANSACTION FORMAT Each transaction includes:

Input[]: references to previous outputs (as in Bitcoin)

Output[]: new recipients and amounts

Locktime: optional, for time-locked transactions

Signature: cryptographic signature from the sender

Optional Flags: indicate selective privacy features (e.g., stealth addresses, ring signatures)

Transactions can be categorized as:

Standard: fully transparent

Selective Privacy: with masked amounts, addresses, or structure

6.3. CONSENSUS ALGORITHM Type: Proof of Work (PoW)

Algorithm: Yespower (or derived, configurable via build parameters)

Difficulty: dynamically adjusted every N blocks to maintain a 2.5-minute average

ASIC Resistance: high (memory-hard algorithm, anti-parallelization)

6.4. CRYPTOGRAPHY AND HASHING Transaction Hashing: double SHA-256

Merkle Tree: SHA-256 leaf nodes, recursively hashed binary tree

Address Generation: based on ECDSA keys (secp256k1 curve)

Stealth Addresses (optional): support for one-time keys and anonymous receipt

6.5. COMPATIBILITY AND MINIMUM REQUIREMENTS Full Node Requirements: dual-core consumer CPU, 4GB RAM, 50+ GB disk

Light Node Requirements (SPV): smartphone or browser with minimal storage, no full chain required

Communication Protocol: TCP/IP using a classic P2P structure with SPV extensions

These specifications will be further detailed in the official technical documentation and implementation files.

6.6. PROTOCOL OVERVIEW The following table summarizes the core protocol specifications of CRED Standard:

Component Specification PoW Algorithm Yespower (memory-hard, ASIC-resistant, optimized for consumer CPU/GPU) Average Block Time 2.5 minutes (up to block 2,499,999), then 5 minutes Difficulty Adjustment Dynamic, every N blocks Block Structure Header (version, prevHash, merkleRoot, timestamp, difficulty, nonce) + transaction list Transaction Format Input[] – Output[] – Digital Signature – Locktime – Optional Privacy Flags Privacy Support Stealth addresses, ring signatures, selective commitments (optional) Hashing Double SHA-256 (transactions, blocks, Merkle tree) Cryptography ECDSA – secp256k1 curve for signatures and addresses Address Format crd1... (custom base32 prefix for CRED Standard) SPV Support Via block headers + Merkle proofs Light Node Stores headers of the last 2048 blocks, validates using full node quorum

7. TOKENOMICS The native asset of the blockchain is called CRED. It represents the unit of value within the network, used for transactions, mining, and incentive systems.

The tokenomics of CRED is designed to ensure programmed scarcity, fair distribution, and long-term sustainability—without pre-mining, private sales, or privileged allocations. All circulating CRED is created exclusively through mining, in exchange for actual computational work.

7.1. EMISSION Initial block reward: 50 CRED

Halving: every 500,000 blocks

Minimum guaranteed reward: 1 CRED per block, starting from the sixth halving cycle (~12 years)

Emission mechanism: asymptotic; total CRED supply tends toward a limit over time, but without a hard cap

Distribution: 100% of CRED is issued via mining; no pre-mine, ICO, reserved funds, or initial allocations are planned

7.2. SCHEDULED BLOCK TIME TRANSITION To balance early adoption with long-term sustainability, the protocol includes a scheduled block time change:

Initial Phase (blocks 0–2,499,999): average block time = 2.5 minutes

Subsequent Phase (from block 2,500,000): average block time = 5 minutes

This transition is intended to:

Accelerate early issuance and incentivize network activity in the early years

Gradually slow down the emission rate over the long term

Improve network efficiency and stability

7.3. INCENTIVES Miners: receive the block reward plus a dynamic transaction reward, proportional to the number of transactions included in the block, drawn from the emission, not from users

Light nodes: do not participate in monetary creation but may benefit from external incentive mechanisms (e.g., cashback, micropayments, wallet-integrated rewards) to promote network expansion

7.4. SUSTAINABILITY The model is designed to be:

Predictable: emission is public, codified, and immutable without collective consensus

Distributed: anyone with consumer hardware can contribute to mining and earn CRED

Free from centralized interests: no entity controls the currency—neither at inception nor in the future

8. COMPETITIVE ADVANTAGES CRED is built with the ambition to become a decentralized, sustainable, and truly accessible store of value. The project stands out in the blockchain landscape through a combination of technical and philosophical features that enhance its uniqueness and integrity.

8.1. TRUE DECENTRALIZATION No pre-mine, private sales, or privileged allocations

PoW algorithm resistant to ASICs, optimized for consumer-grade CPUs and GPUs

Dual-layer architecture with light nodes on smartphones to maximize global network distribution

8.2. FREE TRANSACTIONS No mandatory fees: transactions are accessible to everyone without economic discrimination

Dynamic transaction reward integrated into the protocol to incentivize miners without burdening users

8.3. LONG-TERM SUSTAINABILITY Asymptotic monetary issuance with a guaranteed minimum reward: mining remains incentivized

Scheduled block time adjustment to align the network with project evolution

No reliance on transaction fees as the sole means of securing the network in the future

8.4. MODULAR PRIVACY Users can choose to make certain aspects of their transactions public or private, respecting legal frameworks while maintaining personal control over data exposure.

8.5. SIMPLICITY AND TRANSPARENCY Open source code: readable, documented, and auditable by the community

Streamlined protocol: designed to be understandable and verifiable by anyone, not just technical experts

8.6. INCENTIVES FOR LIGHT NODES Can be implemented in mobile wallets or higher-layer services

Designed to promote widespread and incentivized participation, even without computational power

This combination of accessibility, sustainability, transparency, and inclusivity makes CRED a blockchain designed not only to endure but to thrive in a decentralized, equitable, and global ecosystem.

9. ROADMAP The CRED roadmap is structured to ensure progressive, transparent, and verifiable growth. Each phase aims to consolidate the network, test its resilience, and encourage adoption without compromising the principles of decentralization, security, and sustainability.

Phase 1: Research and Design (Completed / Ongoing) Define strategic objectives and core blockchain features

Draft and review the whitepaper

Conduct comparative analysis with other PoW protocols

Model tokenomics and reward mechanisms

Phase 2: Core Protocol Development Implement core blockchain components: mining, consensus, transactions, validation

Create initial reference full node (CLI + API)

Support light nodes and SPV architecture for mobile devices

Private testnet for early technical validation

Phase 3: Public Testnet Launch an open testnet for developers and early adopters

Conduct stress testing, bug bounty campaigns, and community audits

Test difficulty adjustment, node synchronization, and security mechanisms

Perform A/B testing on reward dynamics and block timing

Phase 4: Mainnet Launch Launch the main blockchain (mainnet) with an initial reward of 50 CRED/block

No pre-mine; all blocks mined publicly from genesis

Release official clients: full node, light node, and mobile wallet

Monitor network activity and provide updates as needed

Phase 5: Ecosystem and Adoption Integrate hardware and multi-chain wallets

Provide development tools (SDKs, API documentation, libraries)

Offer light node installation incentives via wallet campaigns and partnerships

[Optional but strategic] Develop an open-source, lightweight mobile wallet to operate light nodes, manage CRED, and display rewards

Involve the community in building user-friendly interfaces

Architect support for Layer 2 services (micropayments, secondary tokens, reputation, DEX): not a priority in the early phase but fully compatible with protocol evolution

Phase 6: Distributed and Adaptive Governance Study and potentially implement an on-chain proposal and voting system

Transparent mechanisms for future updates, parameter changes, and use of community funds (if introduced)

Monitor the balance between decentralization, security, and performance

The roadmap is modular and adaptive: each phase begins only after full validation of the previous one. Transparency in development and communication will be a constant foundation of the project.

10. TEAM AND GOVERNANCE CRED is conceived as a fully decentralized, neutral, and manipulation-resistant blockchain. For this reason, the project does not implement any form of active or centralized governance—neither temporary nor permanent.

10.1. NO ON-CHAIN OR OFF-CHAIN GOVERNANCE No voting systems, protocol control mechanisms, or direct interventions from developers, organizations, or founders.

The source code is public, immutable, and subject only to network-wide consensus: no changes can be enforced without voluntary updates by participants.

Future improvements may be proposed publicly, but adoption will only occur through voluntary software upgrades by users (as in Bitcoin).

10.2. ANONYMITY AND OPEN CONTRIBUTION CRED has no identified founders: anyone may contribute, build tools, propose improvements, or fork the protocol.

The codebase will be hosted in open-source repositories, community-supervised without hierarchies or central committees.

11. LEGAL AND COMPLIANCE ASPECTS CRED is a decentralized, open-source protocol without legal entity, corporate structure, or centralized management. It does not engage in fundraising, privileged distributions, or direct asset sales. As such, it falls outside traditional financial regulatory frameworks.

11.1. NO ICO, IEO, OR PUBLIC SALE CRED has never conducted, nor will it ever conduct, an Initial Coin Offering (ICO), Initial Exchange Offering (IEO), or any paid initial distribution.

All circulating CRED is issued exclusively via Proof of Work, through an equitable and accessible process.

11.2. OPEN SOURCE, NEUTRAL PROTOCOL The source code is publicly available and can be inspected, used, copied, or modified under the chosen open-source license (e.g., MIT, GPL, or similar).

No part of the protocol requires users to provide personal data or collects sensitive information.

CRED does not provide financial services or act as an intermediary for any regulated activity.

11.3. GLOBAL COMPLIANCE As a decentralized network without centralized management, legal responsibility for use rests entirely with individual participants.

Initial developers have no control over the CRED supply or network after launch.

CRED usage must comply with each user's local laws.

11.4. DISCLAIMER CRED is not an investment product nor a promise of return.

No guarantees are made regarding value stability, technical continuity, or future network adoption.

12. CONCLUSION CRED is a blockchain designed to embody the foundational principles of decentralized networks: fairness, accessibility, security, and independence. In a landscape increasingly dominated by complex, centralized, or profit-driven systems, CRED stands out as an essential, lean, and sustainable tool—built to last.

The network is designed to:

Be truly decentralized, via an accessible PoW algorithm and light nodes operable even on smartphones

Offer free transactions without compromising system security, thanks to the integrated dynamic reward

Ensure stable and transparent tokenomics, with no pre-mines or privileged issuances

Evolve without imposition, through an immutable, public protocol with no centralized governance

CRED does not promise quick profits or superficial revolutions. It offers a solid, verifiable, and accessible foundation for those who wish to build, exchange, store, or simply participate in a free global network.

In an age of distrust, complexity, and manipulation, CRED proposes a different path: essential, concrete, and open.

12.1. A LOOK AHEAD: CREDIX While CRED Standard is designed as a decentralized store of value, the project includes a future extension: Credix, a derivative currency pegged to CRED and intended for everyday use and microtransactions.

Credix will be divisible into familiar, stable, and spendable units (e.g., down to cents), but always backed by reserves.

It will not be listed or freely traded: its sole purpose is to provide usage stability without compromising the scarcity and durability of CRED.

This duality—CRED as a reserve and Credix as a spending tool—represents a broader vision: to create a complete, decentralized, transparent, and accessible monetary infrastructure based on the principle of the CRED Standard.

13. LONG-TERM VISION CRED Standard was created to address urgent issues related to centralization, inflation, and the erosion of trust in traditional economic systems. However, its essential and scalable architecture is designed for longevity, adapting to evolving social, technological, and regulatory contexts.

In the long term, CRED Standard aims to:

Become a stable and verifiable reference for digital value, akin to gold in legacy monetary systems

Support a mixed decentralized economy, where CRED functions as a store of value and unit of account, while derivative currencies like Credix serve as daily spending instruments

Foster global inclusion, enabling users without technical skills or financial means to participate via light nodes and mobile wallets

Evolve without centralized governance, through public code, immutable without network consensus, and voluntary community updates

Remain true to its founding principles: no centralized control, no monetary manipulation, no economic discrimination

Ultimately, the goal is to provide a shared, transparent, and resilient monetary foundation capable of supporting new forms of cooperation, saving, and exchange in an increasingly interconnected and unstable world.

14. CONTRIBUTIONS AND LICENSE The CRED Standard project is developed under an open-source model, without hierarchies, central committees, or proprietary control. Anyone can contribute code, propose improvements, or fork the protocol, in line with community guidelines.

How to Contribute All source code will be publicly available on GitHub

Detailed instructions will be provided for node setup, testing, and submitting pull requests

Voluntary participation is encouraged through development, testing, documentation, translation, or outreach

Technical discussions will take place via issue trackers, developer forums, and optionally on federated platforms like Mastodon or Matrix

License CRED Standard will be released under the MIT license: one of the most permissive open-source licenses, compatible with both commercial and non-commercial projects

Users are free to use, copy, modify, distribute, or fork the code, provided the original copyright and license are preserved

Ethical Clauses While not legally binding, contributors are encouraged to:

Uphold the principle of decentralization as a core value

Refrain from using CRED Standard for activities contrary to freedom, transparency, and economic justice

Participate in a collaborative spirit, free from short-term speculative motives

Join the CRED Signature Movement

If you believe in the vision of CRED — an ethical, minimal, decentralized monetary system — you can now sign the Manifesto cryptographically.

No registration, no tracking. Just one command.

Sign with SHA256

echo "I trust CRED." | sha256sum > hash_<yourname>.txt

Then submit your hash file via GitHub Pull Request to the /signatures/ folder, or simply email it to the maintainer.

Example

echo "I trust CRED." | sha256sum > hash_skpoly.txt

This proves you’ve read and acknowledged the intent of the project.

---

signatures/

This folder will collect all submitted hashes — a decentralized proof of support.