Token design principles
hazBase treats support, usage, achievements and participation as rights and records, including value that money alone does not capture. This guide connects what you value, who shares it and how it is used to token models and operating rules.
Start with value and participation
A token does not create value or revenue on its own. Ongoing support and participation depend on what holders can do, who fulfills that commitment and how usage or outcomes are verified. hazBase uses four perspectives as starting points for design.
Support
Record support and connect it to future activity reports and opportunities to participate.
Record support for a community activity and associate it with access to supporter briefings.
Explore the architectureUse
Define what can be used, how often and for how long, then link service usage to redemption.
Issue five facility visits and update the remaining entitlement after each visit.
Explore the architectureTrust
Identify who verified an achievement and use the record to check eligibility or qualifications.
Link an equipment inspection record to its verifier, equipment identifier and verification date.
Explore the architectureParticipation
Define how people can contribute, vote or authorize execution.
Define voter eligibility and vote counting for decisions about a community facility.
Explore the architectureFour decisions before implementation
Align business terms with the rules the system will execute. Starting with one right and one workflow makes the required capabilities easier to identify.
What does one unit represent?
Define the underlying asset or activity separately from the holder’s entitlement. An equipment identifier, a usage right and a contractual interest require different models.
Example: represent a contractual right in 1,000 units, rather than treating each unit as the physical equipment itself.
Who may receive or transfer it?
Distinguish personal credentials from transferable rights. Where transfers are allowed, define recipient eligibility and any required approval.
Example: approve counterparties with an effective agreement and select a configuration that allows transfers between eligible addresses.
How do quantities and expiry work?
Set the supply cap, decimals and conditions for further issuance. Treat redemption, expiry, repayment and correction of an erroneous issue as distinct operations.
Example: redeem one unit per visit. At the end of an agreement, reconcile the balance with the business settlement record.
Who can issue, change or pause it?
Map issuer and administrator permissions to business approvers. Identify which operations can be paused and which business activities continue during an incident.
Example: require business approval before additional issuance and record who authorized a pause or resumption.
Connect real-world rights to on-chain records
For RWA, map assets and agreements to on-chain holdings and transfers. Reconcile token movements with the business terms that define which rights change hands.
Maintain terms and evidence
Asset register, original agreements, identity checks, approvals and inspection or usage records, with appropriate access controls.
Record under defined rules
Supply, holders, balances, transfers and redemption, configured for the required operations and visibility.
Asset / agreement IDs ↔ chainId, contract address and tokenId where applicable. Operation ID ↔ transaction hash and event.
Transparency means deciding what can be verified and by whom. Keep personal data and agreement originals in access-controlled storage. Distinguish a correctly submitted record from a verified real-world asset or achievement, and retain the verifier and supporting evidence.
Choose a token model for the entitlement
Individually identified items and interchangeable quantities need different models. Use the following as a selection guide; each name links to operations, SDK support and source code.
| What to represent | Candidate component | Design consideration |
|---|---|---|
| Fungible units of a right | FlexibleToken | Supply cap, decimals, further issuance and transfer conditions; for example, units of equipment-related rights or points. |
| Receivables with distinct terms and issuances | BondToken | Separate terms by class and issuance units by nonce. Design coupon and redemption operations with DebtManager. |
| Individually identified assets or credentials | PrivilegeNFT | Holder and metadata per tokenId, such as equipment identifiers or individual memberships. |
| Multiple passes or benefits by type | PrivilegeEdition | Quantity and redemption per type, such as visit passes or tier-specific benefits. |
| Metrics and credentials | MultiTrustCredential | Authorized issuers and proof requirements, with assessment evidence linked to business records. |
An equipment identifier and contractual rights associated with that equipment can be represented separately. Composing distinct roles avoids forcing access, assessments and voting into a single token.
Separate holdings, approval and execution
Token holders, business approvers and contract operators are not necessarily the same people. Mapping application approvals to on-chain permissions makes operations transferable between team members.
Eligibility and transfer
Connect identity and eligibility reviews to permission updates. When using Whitelist, verify token-side integration and how granting or withdrawing eligibility affects holdings and transfers.
WhitelistVoting and execution
Treat voting eligibility separately from authority to execute an approved action. Define approval thresholds, the counting reference, execution delays and executor permissions.
Governance implementation patternPause and resume
Configure pause targets and permissions in advance. Verify each target’s state after a pause request and reconcile business records before resuming. Pausing does not reverse past transactions.
EmergencyPauseManagerExample: represent equipment rights in 1,000 units
This example uses FlexibleToken for contractual rights associated with delivery robot ROBOT-A-001, allocating the first 10 units to a counterparty. The following describes design decisions, not an API request format.
- Asset and right
- ROBOT-A-001 / agreement AGR-2027-001. The agreement defines the entitlement per unit and the party responsible for fulfilling it.
- Quantity
- Cap 1,000, zero decimals. Mint 10 units initially; total supply and the recipient’s balance both become 10.
- Recipient and approval
- Use a recipient with a verified effective agreement. An authorized issuer executes after the asset, agreement, quantity and recipient are approved.
- Completion and records
- Reconcile the confirmed issuance with 10 units in the register, linking the operation ID to the agreement, approval and transaction hash.
Turn the design into an implementation
Combine the required components around the right, quantity, eligibility, permissions and records you have defined. Implementation patterns provide data models, processing steps and SDK examples.