Create Native Currency with Chaincode

This is the second post of The Complete Guide to Hyperledger Fabric. The first post includes 5 steps to set up the blockchain network..

Step 1: Open Docker Desktop, to let the Docker Daemon runs

Step 2: Clone the Hyperledger Fabric Sample repository, pull down the Docker images, and download the platform-specific binary

Step 3: Add the bin sub-directory into the PATH environment variable

Step 4: Bring up the network

Step 5: Create a channel

Don't move on to Step 6 until you finish the setup with the first post: Set up the Blockchain Network.

Step 6: Choose an asset model

You will design a chaincode that acts as the central bank and ledger for your currency. And the Fabric supports major models for defining assets:

The UTXO (Unspent Transaction Output) Model: Like Bitcoin, where ownership is proven by referencing past transaction outputs.
The Account Model: Like Ethereum, where balances are stored directly in an account's state. This model is typically more straightforward for a native currency.

To follow the finance industry standard and the core principle of User Center Design. Let's couple the code you're going to write with the account model.

Step 7: Create smart contract to manage the currency's lifecycle

The essential functions include:

InitLedger or CreateCurrency: To set up the initial supply and distribution (e.g., minting initial tokens to a founding organization).
Transfer(from, to, amount): The core function to transact currency between accounts.
BalanceOf(account): To query the balance of any account.
TotalSupply(): To query the total amount of currency in circulation

Write your first function, unless you cannot find the native function to call from the Fabric framework.

Step 8: Integrate with transaction flow

To achieve the "native" attribute where the currency is involved in every transaction, there are two potential approaches:

Direct: Structure your application so that every business transaction on the network includes a call to your currency's Transfer function to pay for transaction fees or as part of the contract.
Composite: Develop your main application chaincode so that it internally calls the functions of your separate currency chaincode. Fabric supports cross-chaincode communication.

There is no universally "better" approach; Both approaches have pros and cons. It depends on your project's goals and long-term vision.

📊 Comparative Analysis: Direct vs. Modular Integration

Aspect	Option A: Direct Integration (Currency logic in main chaincode)	Option B: Modular/Composite Design (Separate Currency Chaincode)
Performance & Transaction Throughput	✅ PRO: Generally Higher. A single transaction executes one chaincode. Less overhead, lower latency, and simpler endorsement.	❌ CON: Generally Lower. Requires cross-chaincode calls, adding internal network overhead and complexity to the endorsement process.
Code Management & Modularity	❌ CON: Tight Coupling. Currency logic is fused with business logic. Updating currency rules requires upgrading every application chaincode.	✅ PRO: Clear Separation. Currency logic is a dedicated, reusable service. It can be upgraded, versioned, and bug-fixed independently.
Security & Consistency	❌ CON: Riskier. A bug in the business logic could corrupt the currency state. All logic shares the same data namespace, increasing risk.	✅ PRO: More Robust. The currency contract is an isolated "vault." Applications can only interact with it via its defined public interface.
Development & Testing Complexity	✅ PRO: Simpler to Develop Initially. No need to manage multiple chaincodes or cross-chaincode calls during initial development.	❌ CON: More Complex to Set Up. Requires understanding of chaincode namespaces and invocation patterns. Testing must cover interaction between systems.
Flexibility & Future-Proofing	❌ CON: Inflexible. Creating a new asset requires copying logic or building another monolithic chaincode. Hard to adapt.	✅ PRO: Highly Flexible. New asset types can be built as separate, modular chaincodes. The system easily scales to a multi-asset platform.

Since the intended audience for this tutorial are programmers. We'll follow the engineering best practice to organize the codebase in modular fashion from the architectural point of view.

Therefore, instead of building a simple, closed-loop system where the native currency exists solely to enable one specific application. We are building a platform or ecosystem where the native currency is a common utility accessible to multiple, potentially future, applications (e.g., a trade finance network where a "BankCoin" is used across various loan and letter of credit applications).

Step 9: Deploy, invoke the Chaincode (Smart Contract), and Interact with the Network