Token design principles https://docs.hazbase.com/en/know-overview/ TOKEN DESIGN 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 architecture Use 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 architecture Trust 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 architecture Participation Define how people can contribute, vote or authorize execution. Define voter eligibility and vote counting for decisions about a community facility. Explore the architecture Four 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. 1 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. 2 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. 3 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. 4 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. Business system Maintain terms and evidence Asset register, original agreements, identity checks, approvals and inspection or usage records, with appropriate access controls. Smart contract Record under defined rules Supply, holders, balances, transfers and redemption, configured for the required operations and visibility. The connecting identifiers 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. Whitelist Voting 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 pattern Pause 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. EmergencyPauseManager Example: 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. Define quantity and payment calculations separately Here, 10 units equal 1% of the 1,000-unit cap, but that alone does not entitle the holder to 1% of equipment revenue. If distributions apply, separately define eligible revenue, costs, reference date, qualifying balances and payment method, then connect issuance and distribution records. Equipment and robotics architecture Allocation and reconciliation operations 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. Explore a similar use case Review workflows and token roles for equipment, passes, memberships and community activities. Explore use cases Build the required capability Integrate architectures and code for assets, access, governance and evidence into your application. Explore implementation patterns Start with a sample Review contract specifications