Introduction
Welcome to the official guide for deploying identity tokens in GRIDNET OS, the world’s first 100% decentralized operating system. This document will walk you through the process of creating your personalized identity token, allowing you to establish a user-friendly nickname instead of using a complex wallet address when interacting with the network. Identity Tokens and their properties can be easily browsed when viewing accounts/domains in the GRIDNET OS’ Blockchain Explorer UI dApp. In this UI dApp you can also search for accounts by Friendly Names associated with Identity Tokens.
The Rationale Behind Identity Tokens
Understanding Identity Token Types
In GRIDNET OS, identity tokens are fundamental building blocks that establish your presence in our decentralized ecosystem. Before diving into deployment steps, it’s essential to understand the various types of identity tokens available and why you might choose one over another:
Token Type | Description | Best For |
---|---|---|
Basic | Minimal functionality with limited features | Testing and development |
IdentityOnly | Provides identity verification without additional features | Privacy-focused users |
PoW (Proof of Work) | Requires computational work rather than financial stake | Resource-rich, capital-constrained users |
Stake | Requires sacrificing GNC cryptocurrency | Most users, provides best rewards |
Hybrid | Combines both PoW and Stake requirements | Maximum security and reward potential |
This tutorial focuses on deploying a Stake-based identity token, which requires sacrificing a certain amount of GNC cryptocurrency. This approach is recommended for most users as it provides optimal balance between ease of deployment and network benefits.
The Role of Stake in Preventing Sybil Attacks
Stake-based identity tokens play a crucial role in maintaining GRIDNET OS’s security and reliability. By requiring users to sacrifice GNC cryptocurrency, we create a financial barrier that thwarts Sybil attacks—where malicious actors create multiple fake identities to gain disproportionate influence over the network.
The stake mechanism ensures that creating numerous identities becomes prohibitively expensive, thereby preserving the integrity of:
- Voting mechanisms within the ecosystem
- Reputation systems built on top of GRIDNET OS
- Resource allocation algorithms
- Decentralized applications that rely on unique identity verification
Furthermore, higher stake amounts provide proportionally greater rewards as additional functionalities of GRIDNET OS are unveiled, particularly in the realm of crypto-incentivized, Sybil-proof data transmission protocols.
Practical Applications for Daily Users
Beyond security considerations, identity tokens serve several practical purposes that enhance your experience in the GRIDNET OS ecosystem:
Embedded Public Keys for Verification
Each identity token contains embedded public keys that enable instant verification of cryptographic signatures. This feature is critical for numerous use cases:
- Decentralized Social Media: When someone deploys a dApp similar to Twitter or Facebook on GRIDNET OS, the authenticity of all posts can be cryptographically verified against your identity token’s public key
- Secure Messaging: In decentralized email or messaging applications, recipients can verify both the integrity and authenticity of incoming messages
- Document Signing: Any document or content you create can be cryptographically signed and verified against your identity token
- Smart Contract Interactions: Automated verification of your identity in contract executions without requiring additional authentication steps
User-Friendly Domain Names
Perhaps the most immediately apparent benefit is the ability to claim a memorable nickname that serves as your domain within the GRIDNET OS ecosystem:
- Others can browse your decentralized websites by simply visiting your GRIDNET OS domain (e.g.,
visit HappyDuck
) - Value transfers can target your nickname instead of complex wallet addresses (e.g.,
send 5 GNC to HappyDuck
) - Applications can reference your identity using human-readable names rather than machine-oriented addresses
- Your personal data and applications become intuitively accessible under a consistent namespace
Permanent Ownership
Unlike traditional domain name systems, once registered, your GRIDNET OS domain name (established through your identity token) cannot be taken away from you:
- No renewal fees or subscription costs
- No central authority that can revoke or reassign your domain
- Truly permissionless ownership secured by cryptographic proofs
- Transferable only with your explicit cryptographic authorization
GRIDNET OS Domains vs. Traditional DNS Domains
When comparing GRIDNET OS domains to traditional DNS domain names, the advantages become clear:
Feature | Traditional DNS Domains | GRIDNET OS Domains |
---|---|---|
Registration Cost | Initial purchase fee | One-time sacrifice (investment) |
Renewal Fee | Annual renewal required | None – permanent ownership |
Central Authority | ICANN and domain registrars | None – fully decentralized |
Censorship Risk | Can be seized or blocked | Cannot be censored or revoked |
Identity Verification | Optional, separate process | Built-in cryptographic verification |
Transfer Mechanism | Administrative process | Cryptographic authorization only |
Resolution Security | Vulnerable to DNS attacks | Cryptographically secure resolution |
Value Integration | Separate from payment systems | Directly integrated with value transfer |
By establishing your identity token early in GRIDNET OS’s evolution, you secure your preferred nickname before others claim it. As the ecosystem grows and more services are built on this foundation, early adopters will benefit from having established recognizable identities in this new decentralized frontier.
Understanding GridScript Execution Context
Before deploying your identity token, it’s important to understand how GridScript instructions work in our ecosystem and the critical importance of execution context:
Concept | Description | Importance |
---|---|---|
State-Domain | The account-specific context for execution | Instructions are context-dependent and must be executed within the correct State-Domain |
Execution Context | The scope in which GridScript commands operate | GridScript engine needs to know which account is making the sacrifice or deploying tokens |
SSH Access | Remote access to decentralized nodes | No authentication required for SSH access, only for transaction commits |
DUI Access | Console access through graphical Terminal UI dApp | No authentication required, only for operations’ commits |
Execution Types
Execution Type | Purpose | System Impact | Authentication |
---|---|---|---|
Ephemeral | Real-time commands displayed in terminal or sent as encoded data to apps | No permanent change to system state | Not required |
Transactional | State-changing operations (like token deployment) | Permanent change to decentralized state machine | Required only at commit time (via mobile app) |
Transaction Confirmation Workflow
Execution of everything in GRIDNET OS usually boils down to Decentralized Processing Threads. Threads execute GridScript. Execution can be either ephemeral (code can cause computational effects – and data retrieval of data. A great example of this is the Blockchain Explorer UI dApp which invokes Blockchain Explorer JavaScript API. The in-web-browser sub-system of GRIDNET OS then formulated GridScritp instructions which are executed on remote nodes, remote nodes return BER encoded meta-data, which are onion routed and provided to instances of UI dApps).
But sometimes, what we call ‘kernel mode’ execution of a Decentralized Processing Thread is needed.
In such a case to put it simply – all GridScript code needs to be wrapped in a Begin Thread
(BT) and Commit Thread
(CT) code sequence.
Such a thread would be executed at full redundancy by the entire network, affecting the entire system,
All transactional operations in GRIDNET OS must be confirmed before proceeding to dependent transactions:
- Initial transaction must be committed and confirmed on the network
- Subsequent dependent transactions must wait for confirmation of prior transactions
- Each transaction requires its own Begin Thread (bt) and Commit Thread (ct) sequenceNote that in nomenclature of GRIDNET OS a ‘transaction’ is similar in its meaning known in relational database system. It not necessarily has anything to do with a value transfer.
Identity Token Deployment Process

Deploying an identity token requires following key steps, each involving specific GridScript commands and proper context management:
Step 1: Access Your State-Domain
Command | Purpose | Example | Notes |
---|---|---|---|
ssh user@node.gridnet.org |
Access a decentralized node | ssh griduser@node7.gridnet.org |
No authentication required for SSH access |
cd ~/account |
Enter your account directory | cd ~/23ZBwZfGcwSykunTd6 |
Must access your specific State-Domain for context |
Step 2: Make a Sacrifice
The “sacrifice” is a fundamental concept in GRIDNET OS that ensures network integrity by requiring users to dedicate resources.
Command | Purpose | Example | Notes |
---|---|---|---|
bt |
Begin transaction | bt |
Initiates the sacrifice transaction |
sacrifice <amount> |
Dedicate GBU to the network | sacrifice 1 |
Minimum 1 GBU; higher sacrifices increase trust and potential rewards |
ct |
Commit transaction | ct |
Generates a QR code for authentication |
[Mobile app scan] | Authenticate and confirm | Scan with GRIDNET Token app | Generates a receipt ID for next step |
[Wait for confirmation] | Allow transaction to be confirmed | Check status with getstatus |
Must wait for network confirmation before proceeding |
Example Receipt ID: 43PLVuXvAz8thego8eQtYYEAeXQQddX4Z5CqzvAJLjYWwTRY7K
Step 3: Generate the Identity Token
Once your sacrifice transaction is confirmed, you can generate your identity token:
Command | Purpose | Parameters | Example |
---|---|---|---|
bt |
Begin new transaction | bt |
Note: A new bt command is required as this is a separate transaction |
genid |
Generate identity token | -p = public key<br>-f = friendly name<br>-r = receipt ID |
genid -p 23ZBwZfGcwSykunTd61CGzmkDuXdJTqf4AfBHpkpDXtKcwc7KN -f HappyDuck -r 43PLVuXvAz8thego8eQtYYEAeXQQddX4Z5CqzvAJLjYWwTRY7K |
ct |
Commit transaction | ct |
Generates a QR code for authentication |
[Mobile app scan] | Authenticate and confirm | Scan with GRIDNET Token app | Confirms token generation |
[Wait for confirmation] | Allow transaction to be confirmed | Check status with getstatus |
Must wait for network confirmation before proceeding |
Step 4: Register the Identity Token
After the token generation transaction is confirmed, you must register it on the network:
Command | Purpose | Notes |
---|---|---|
bt |
Begin new transaction | Required as this is a separate transaction package |
regid |
Register identity token | Must be committed in a transaction |
ct |
Commit registration | Generates a QR code for authentication |
[Mobile app scan] | Authenticate registration | Final security verification |
[Wait for confirmation] | Allow transaction to be confirmed | Check status with getstatus |
Step 5: Synchronize with the Network
After successful registration and confirmation, synchronize your changes with the network:
Command | Purpose | Notes |
---|---|---|
bt |
Begin new transaction | Required for sync operation |
sync |
Synchronize with network | Updates network to reflect your new identity |
ct |
Commit synchronization | Generates a QR code for authentication |
[Mobile app scan] | Authenticate synchronization | Finalizes the entire process |
Complete Deployment Example
Below is a complete script example for deploying the identity token “HappyDuck”, showing the proper sequence of transactions and confirmation waits:
# Step 1: Access your State-Domain
ssh griduser@node7.gridnet.org
cd ~/23ZBwZfGcwSykunTd6
#
# Step 2: Make a Sacrifice
bt
sacrifice 1
ct
# [Scan QR code with mobile app]
# [Wait for transaction confirmation]
# [Receipt ID received: 43PLVuXvAz8thego8eQtYYEAeXQQddX4Z5CqzvAJLjYWwTRY7K]
#
# Step 3: Generate Identity Token
bt
genid -p 23ZBwZfGcwSykunTd61CGzmkDuXdJTqf4AfBHpkpDXtKcwc7KN -f HappyDuck -r 43PLVuXvAz8thego8eQtYYEAeXQQddX4Z5CqzvAJLjYWwTRY7K
ct
# [Scan QR code with mobile app]
# [Wait for transaction confirmation]
#
# Step 4: Register Identity Token
bt
regid
ct
# [Scan QR code with mobile app]
# [Wait for transaction confirmation]
#
# Step 5: Synchronize with Network
bt
sync
ct
# [Scan QR code with mobile app]
Context-Dependent Execution
It’s critical to understand that many GridScript instructions are context-dependent. The engine needs to know:
- Who is executing the command (which account)
- Where the command is being executed (which State-Domain)
- What prior transactions have been confirmed
This is why you must:
- Always
cd
into your specific account/State-Domain - Wait for transaction confirmation between dependent operations
- Begin each new operation with a fresh
bt
command
Mobile App Integration
The GRIDNET Token mobile app is essential for secure authentication and transaction confirmation. Here’s what you need to know:
Feature | Description | Benefit |
---|---|---|
Wallet Setup | Generate new private/public key pair with fingerprint confirmation | Secure key management |
QR Code Scanning | Authenticate all transactions by scanning QR codes | Prevents unauthorized access |
Balance Reporting | Maintains connection with decentralized VM | Real-time account status |
Transaction History | Records all confirmed transactions | Audit trail for activities |
Advanced Topics
The Sacrifice Mechanism
The sacrifice mechanism serves multiple purposes in GRIDNET OS:
- Trust Establishment: Higher sacrifices indicate greater commitment to the network
- Resource Allocation: Ensures fair allocation of system resources
- Reward Potential: Sacrificed GBUs contribute to potential rewards in data exchanges
- Spam Prevention: Deters frivolous identity token creation
View Transaction Command
For transparency, you can use the vt
command to view the auto-generated GridScript source code:
bt
sacrifice 1
vt
This displays the bytecode that will be executed, allowing for verification before commitment.
Transaction Confirmation
Transaction confirmation is essential in GRIDNET OS’s decentralized architecture:
Command | Purpose | Example |
---|---|---|
getresult |
Check transaction status | getresult <tx_id> |
info |
see all high-level information associated with an account | info |
tx |
List all transactions associated with an account (execute while in scope of an account) | tx |
Issue | Solution |
---|---|
Insufficient Balance | Acquire additional assets |
Failed Transaction | Verify your network connection and try again |
Context Errors | Ensure you’re in the correct State-Domain directory |
Dependency Errors | Confirm previous transactions before proceeding to dependent ones |
Mobile App Connection Issues | Ensure proper mobile internet connectivity |
Unrecognized Identity Token | Complete all steps including final sync transaction |
Conclusion: Claiming Your Place in the Decentralized Revolution
By deploying your identity token on GRIDNET OS, you’re not merely creating a nickname—you’re staking your claim in humanity’s first truly decentralized digital frontier. This is more than a technical process; it’s your declaration of digital sovereignty.
Beyond Traditional Identity Systems
For too long, our digital identities have been controlled by centralized authorities who dictate the terms of our online existence. With GRIDNET OS identity tokens, we break these chains once and for all:
- True Ownership: Your identity belongs to you alone—not to corporations, not to governments, not to any central authority
- Unstoppable Presence: No entity can erase your existence from the GRIDNET OS ecosystem
- Value Integration: Your identity becomes a direct channel for value exchange without intermediaries
Join the Vanguard of Digital Freedom
Early adopters of revolutionary technologies have always shaped the future. By establishing your identity token today, you position yourself at the forefront of a movement that is redefining how humans interact with technology and each other:
- Be among the first to claim your preferred nickname before mass adoption begins
- Establish your presence in what will become the foundation of tomorrow’s decentralized internet
- Participate in building a more equitable, censorship-resistant digital world
The Power of Decentralized Identity
As more applications and services are built on GRIDNET OS, your identity token will become increasingly valuable—not just financially, but functionally. Imagine a world where:
- Your online interactions are verified without surveillance
- Your digital assets are truly yours, accessible through your immutable identity
- Your voice cannot be silenced by arbitrary platform policies
This isn’t just speculation—it’s the inevitable trajectory of truly decentralized systems. GRIDNET OS is building this future today, and your identity token is your passport to this new reality.
Take Action Now
Don’t wait for others to claim your digital identity. Follow this guide, deploy your identity token, and take your rightful place in the decentralized revolution. Your future self will thank you for having the foresight to establish your presence at the beginning of this transformative journey.
For those bold enough to see beyond current paradigms, GRIDNET OS isn’t just another platform—it’s the dawn of a new era in human technological progress. Your identity token is both your key and your flag planted firmly in this new territory.
Welcome to true digital freedom.