Knowledge Base

TRD Network is an AI-integrated DePIN ecosystem providing foundational infrastructure for a borderless digital future. The mission: empower individuals and businesses with secure, efficient, accessible decentralized-economy tools through intelligent, infrastructure-driven solutions.

AI acts as the intelligent layer for security and operational efficiency — real-time threat monitoring, optimizing the A-PoS consensus, and supporting cybersecurity and transactional execution across the infrastructure.

A-PoS is TRD's consensus mechanism. It combines traditional PoS with an AI layer that monitors validators, detects anomalies in real time, and optimizes block production — targeting sub-2-second finality and a self-healing security layer.

A distributed GPU cloud marketplace connecting users to idle GPU resources worldwide. Instead of renting from a centralised provider, you access compute contributed by a global network of verified hardware providers — at up to 90% less than traditional cloud costs, with A-PoS security backing every job.

Virtual Machines (GPU-accelerated, full OS control), Docker containers, Kubernetes clusters with auto-scaling GPU node pools, bare-metal servers, and Confidential Compute (hardware-encrypted enclaves via AMD SEV-SNP and NVIDIA H100 CC mode). Suitable for LLM training, inference, 3D rendering, and scientific computing.

Pricing is market-driven and per-second. Each GPU type (NVIDIA H100 SXM to RTX 4090 and AMD Instinct) lists a transparent hourly rate set by supply and demand. No hidden fees, no minimum commitment; billing stops when your workload ends. Live pricing is visible in the Marketplace before you deploy.

Jobs run in isolated environments with the A-PoS security layer monitoring the network. For maximum privacy, Confidential Compute uses hardware-level Trusted Execution Environments, so data and model weights stay encrypted even from the provider — suitable for HIPAA, GDPR, and SOC 2 Type II regulated workloads.

Autonomous, always-on AI programs running on TRD's decentralised infrastructure. Unlike agents on a single centralised server, they execute inside fault-tolerant distributed environments — no single point of failure, no third-party access to logic or data. They automate on-chain and off-chain tasks, interact with smart contracts, manage wallets, and respond to real-time triggers.

On-chain transaction execution and wallet management, DeFi yield optimisation, real-time market monitoring and alerting, autonomous support and workflow automation, cross-chain bridging, and custom user-defined logic. The runtime is powered by TRD's GPU compute layer.

AI Agents are in development and listed as Launching Soon on the roadmap. Early access opens to presale holders and waitlist registrants first. Register interest on the AI Agents page and follow @TRDN_AI for launch announcements.

Yes. $TRD pays for compute consumed by the agent, network fees for on-chain operations, and priority scheduling. Holding and staking $TRD unlocks discounted runtime rates and higher execution-priority tiers.

An encrypted data layer that distributes files across thousands of independent nodes worldwide. No central server to breach, no single company with access, and no risk of censorship. Integrity is verified through zero-knowledge proofs, and redundancy keeps files accessible even if multiple nodes go offline.

Files are encrypted client-side with AES-256 before leaving your device, then split into shards and distributed. Zero-knowledge proofs let the network verify storage without any node seeing your content. Only you, holding the key, can decrypt and reassemble the data.

Listed as Coming Soon on the roadmap (Phase 4). Early access is prioritised for presale holders and waitlist members. Register interest on the Decentralized Storage page to be notified when beta opens.

TRD Storage is built to integrate natively with TRD's AI security layer and compute infrastructure, so storage, compute, and agent tasks share the same A-PoS-verified network — enabling AI models that read and write directly to decentralised storage with hardware-level privacy. It also targets a consumer-grade UX.

A provider contributes idle hardware — GPU compute, CPU, storage, or bandwidth — to the network and earns $TRD rewards proportional to resources supplied and uptime maintained. It monetises underused hardware while powering the ecosystem.

For GPU compute: NVIDIA data-centre GPUs (H100, A100, A40, RTX series) and AMD Instinct, 8GB+ VRAM recommended. For storage: 1TB+ reliable NVMe/SSD. A stable connection (1Gbps recommended) and a machine running the TRD Provider Node software. Consumer rigs with RTX 3090/4090 are eligible.

Compensation is based on verified contribution. When a user rents your GPU or storage, you receive a share of the payment in $TRD, calculated per-second on actual utilisation. Higher uptime, faster hardware, and staked $TRD earn priority placement and boosted multipliers.

Use "Become a Provider" in Core Services or the Ecosystem section. Submit the onboarding form (name, email, GPU model/VRAM, CPU, RAM, bandwidth, storage). Applications are reviewed within 48 hours with setup instructions and the Provider Node software. No upfront cost.

$TRD is the economic backbone — staking rewards, governance voting, AI-driven security fuel, network fees, and access to premium services including GPU compute, storage, and TRD POS.

$TRD is available during the live presale. Visit presale.trdn.io and follow @TRDN_AI for real-time stage announcements.

50% of supply is locked until 2030 via verified PinkSale lock contracts on Ethereum. All allocations follow strict vesting schedules with on-chain transparency.

Never share your seed phrase or private key. Contact [email protected] immediately — the TRD team will never ask for your private keys. We can assist with token claims in some scenarios, but lost funds cannot be recovered.

Open verify.html or POST to api.dcslabs.ai/v1/credentials/verify with a cid or full receipt. No login, no key. The result is a four-state verdict (verified / invalid / revoked-or-suspended / unknown). Source: verify-site verify.html + docs.html quickstart (R5-4)

A small JSON object: id, cid, issuer (did:web), subject payload, optional status, and an Ed25519 signature. The cid is computed over the canonical UNSIGNED form (RFC 8785 JCS + SHA-256), so the signature never affects the cid. Source: docs.html receipt-format (R5-4); R-Series CID rule

So the content ID is stable regardless of signing. Verification recomputes the cid from the unsigned canonical bytes, then checks the signature separately. This is the CID-rule fixed across the issuer modules. Source: R-Series CID-rule fix; docs.html receipt-format

Add the badge.js script and a span with data-cid. The badge resolves the cid against the public verify endpoint and shows verified/revoked/unknown, linking to verify.html for independent re-checking. Source: docs.html badge-embed; badge.js (R5-4)

Yes. It's a PWA with a manifest.json, a full icon set, and a service worker. On Android/desktop Chrome it installs via the Download button; on iOS Safari use Share to Add to Home Screen. Source: PWA install pass (R4-1); install-flow-QA.md

The app shell loads offline and a dedicated offline page is served for failed navigations. Verification itself always needs the network — results are never served from cache. Source: sw.js offline fallback (R6-3); offline.html

sw.js uses a single bumpable SW_VERSION constant; the cache name derives from it and the activate step deletes every non-current cache. Bump the version per deploy and the old shell is purged. Source: sw.js cache versioning (R4-1)

POST /v1/credentials/verify, GET /v1/credentials/{id|cid}, GET /v1/status/{listId}, POST /v1/verify/universal, GET /v1/registry, GET /v1/explorer/stats, plus issuer Bearer endpoints for issue and lifecycle. Source: docs.html API reference (live api.dcslabs.ai)

An open formula: reliability 30, longevity 20, volume 20, audit 20, federation 10. Every registry response includes the inputs so anyone can recompute the number. No pay-to-rank. Source: docs.html Info; registry

Revocation is permanent by design; suspension is reversible. Status lists are anonymous public bitstrings, so checking status reveals nothing about who is asking. Source: docs.html status semantics

Each issuer is a did:web bound to its domain. The DCS signing key is published at dcslabs.ai/.well-known/did.json, so verifiers fetch the key directly from the domain. Source: docs.html Info; did:web

Optionally. A credential's hash can be anchored in Base mainnet calldata; anyone can check the anchor on basescan.org. Anchoring is optional and never required to verify. Source: docs.html; Base anchoring

The issuer offering: provision an issuer ID + API key, issue signed receipts, manage their lifecycle (revoke/suspend/reactivate), embed badges, and appear in the public registry. Verification stays free for everyone. Source: docs.html trust-SKU integration (R5-4)

POST your email to /v1/auth/signup for a rate-limited free key, then call /v1/credentials/issue with a Bearer token. Verification never needs a key. Source: docs.html quickstart

The R+2 standard is open and MIT-licensed (spec, conformance vectors, reference verifier on GitHub), using RFC 8785 canonical JSON, Ed25519 signatures, Bitstring status lists, and W3C VC / Open Badges inbound verification. Source: docs.html Info; R+2 standard repo

Yes — an honest build-time snapshot of the API, verify site, R3 issuer, and compute API, with an outage-comms template. It does not fake live polling; it shows when the snapshot was built. Source: status.html (R5-5)

Every page is linted for language attribute, zoomable viewport, image alt text, labelled form fields, and named buttons. Findings are fixed in the same pass. Source: a11y-lint (R4-3); a11y deep pass (R6-8)

An offline performance lint checks font-display, image sizing, and render-blocking scripts; render-blocking CSS was moved to a non-blocking preload, and a critical-core snippet is inlined on new pages. Source: perf-lint (R5-6); critical-css (R6-1)

A staged consolidation kit prepares path-preserving 301 redirects from trdn.io (and legacy hosts) to trdn.ai, flipped from a single canonical-host constant. It is staged, not yet executed. Source: trdn.ai consolidation kit (R5-1); CUTOVER.md

Hosting plans are presented on the VM page with transparent monthly pricing; the exact prices are being finalized. (A clean-removal path also exists if the product is consolidated into GPU compute.) Source: vm both-ways pack (R5-2)