Back to Documentation

Decentralized Identity (DID)

Every company on FenixTrace receives a decentralized identifier (DID) anchored on-chain through the trace_shack::did_registry Move module on IOTA Rebased. The DID certifies the company's authenticity, is publicly verifiable in the scanner and forms the cryptographic foundation for transparent product traceability in the supply chain.

Move did_registry
IOTA Rebased
On-chain Verified
Server-signed
W3C-inspired
What is a DID?

A DID (Decentralized Identifier) is a unique digital identifier that does not depend on a central authority. Unlike a plain username, a DID is anchored on-chain and cryptographically verifiable by anyone. In the context of FenixTrace, the DID represents a company's verifiable digital identity in the supply chain, controlled by the company account.

FenixTrace uses an approach inspired by the W3C DID Core standard, implemented through a custom Move module on IOTA Rebased (trace_shack::did_registry). Each DID corresponds to a shared on-chain DidRecord object holding owner, company name, document hash and status. DID registration happens automatically when a company is onboarded and confirms its plan: the server creates and signs it on-chain, with no technical action required from the user.

The main advantage of an on-chain anchored identity is that every operation leaves a public, immutable proof: anyone can verify that a company's DID exists, who it belongs to and what its status is, without blindly trusting the platform. The status (active/suspended/revoked) is governed by the Super Admin only for compliance reasons, but the registration and history of the DID remain tracked on-chain in a transparent, verifiable way.

DID Technical Structure
FieldValueDescription
Method
did:iota
DID method specific to the IOTA network
Network
IOTA Rebased (Move L1)
IOTA Rebased network with Move execution
Format
did:iota:<network>:<object_id>
The suffix is the object id of the on-chain shared DidRecord
Module
trace_shack::did_registry
Move module that creates and updates the DidRecord
Standard
Inspired by W3C DID Core 1.0
Full integration with IOTA Identity Framework on the roadmap
Storage
Shared DidRecord object
Each DID lives as an on-chain shared object, inspectable via RPC or Explorer
Verification
Server signature + DidRegistered event
FenixTrace signs on-chain on behalf of the company account and emits a verifiable Move event
DID Example
did:iota:testnet:0xb9d955524372ca68dfa5222814cae5a50711df68d7b2feec5d94467c8dde9383

The DID consists of four parts: the "did" prefix, the "iota" method, the IOTA Rebased network ("testnet" or "mainnet"), and the object id of the shared DidRecord created on-chain by the did_registry module. You can paste the object id into the IOTA Explorer to see the full record.

Identity Lifecycle

The DID identity onboarding process on FenixTrace follows a 6-phase flow, from plan selection to full operation. Each phase involves verifiable on-chain interactions.

1
Email Onboarding

The company is onboarded on FenixTrace using only its business email. No wallet, seed phrase, browser extension or network selection is required: sign-in happens with email and an OTP code. On first login the company picks a plan (Base, Professional, Enterprise) that sets the number of registrable products and the available API keys.

Sign-in: email + OTP, no wallet
2
Company Account Creation

When the plan is confirmed, FenixTrace creates the company account and securely provisions — server-side — the on-chain key dedicated to that company. This key is held by the platform and used only by the server: the company never sees or manages it. The company account is immediately recognized as a registered company and eligible for DID registration.

Server-side: custodied company key, no user action
3
On-Chain DID Registration (automatic)

The server registers the DID on-chain automatically: it invokes the did_registry::register module with company name and document hash, signing with the custodied company key. The module creates a shared DidRecord object (owner, active status, timestamp) and emits a DidRegistered event with the object id. The final DID is did:iota:<network>:<object_id>, resolvable via RPC and visible on Explorer. The user signs nothing.

Move: did_registry::register • Format: did:iota:<network>:<object_id>
4
DID Notarization (automatic)

Still server-side, FenixTrace calls notarization::record with entity_type = did and an entity_reference that identifies the company. The module emits a NotarizationRecorded event that serves as a public receipt of the onboarding flow, indexable by any on-chain observer. This notarization is also performed and signed by the server, with no user intervention.

Move: notarization::record • Event: NotarizationRecorded
5
DID ↔ Company Linking

The backend reads the object id from the DidRegistered event and associates it with the company in the local registry. From that moment the public scanner, /api/companies and /api/public/companies return identityDid = did:iota:<network>:<object_id> that resolves on Explorer.

Status: identityStatus = "active" • didObjectId populated
6
Full Operation

The company can register products from the dashboard or through API keys for integrations (AgerLink, WooCommerce, PrestaShop, CRM/ERP). Every add_product emits a ProductAdded event and is notarized via notarization::record automatically by the server. The company appears in the public scanner with the active identity badge.

Dashboard: all features active
Identity Statuses

A company's DID identity can be in one of the following three states. The status is visible both in the admin dashboard and the public scanner, ensuring total transparency.

Active
ACTIVE

Identity is verified and fully operational. The company signs in with email and OTP and can register products, generate API keys for integrations, and its products are visible in the public scanner with the "Verified Partner" badge. FenixTrace confirms on-chain that the DID matches the company account: the authenticity proof is recorded automatically by the server, with no signature from the user.

Effects:

Full dashboard access • Products visible in scanner • Green "DID active" chip • Can generate API keys

Suspended
SUSPENDED

Identity is temporarily suspended by the administrator. The company can still access the dashboard in read-only mode but cannot register new products or generate new API keys. Already registered products remain visible in the scanner but with a suspension notice. This action is reversible: a Super Admin can reactivate the identity at any time.

Effects:

Dashboard read-only • No new registrations • Yellow "DID suspended" chip • Products visible with notice

Revoked
REVOKED

Identity has been permanently revoked. This is an irreversible action performed only in severe cases (fraud, terms of service violation, illegal activity). The company account loses dashboard access and its products are marked as "Identity Revoked" in the scanner. Any associated API keys stop working. To operate again on the platform a new onboarding is required, with a new account and a new DID identity.

Effects:

No dashboard access • API keys disabled • Products marked "DID revoked" • Red chip in scanner • Requires new onboarding

Administrative Actions (Governance)

Platform-side DID status governance is reserved for the Super Admin, who also signs in via email and OTP. Every status change is logged as an anomaly record and stored in the audit log, and the related on-chain operations are signed automatically by the platform system wallet. The on-chain shared DidRecord stays associated with the company account: its history is public and immutable, and reactivation is always possible except in cases of permanent revocation.

Identity Reactivation
Super Admin

A Super Admin can reactivate a previously suspended identity. The action restores all company functionalities: full dashboard access, ability to register new products, generation and use of API keys. The scanner badge returns to "DID Active" (green). Reactivation is immediate and does not require re-notarization.

When: after investigation completed, issue resolved
Identity Suspension
Super Admin

A Super Admin can temporarily suspend an identity for compliance reasons, investigation of reports, or at the company's own request. During suspension, the company retains read access to the dashboard but cannot perform write operations (new products, new API keys). Existing products remain in the scanner with a notice.

When: ongoing investigation, compliance request, company request
Identity Revocation
Super Admin

Irreversible action reserved for severe cases. The Super Admin permanently revokes a company's DID identity. The company account is blocked and its API keys disabled, the DID is marked as "revoked" on-chain, and all company products are marked with a warning badge in the scanner. The company can no longer access the platform with the same account.

When: confirmed fraud, TOS violation, illegal activity
Public Scanner Visibility

FenixTrace's public scanner is the main access point for identity verification. Every registered company is visible with the following identity information:

"Verified Partner" Chip

Indicates the company has an active, on-chain verified DID

DID status chip

Shows the current status (DID active / suspended / revoked) with the matching color

"On-chain proofs" card

Owner, contract, full DID and DID transaction digests — each with a copy button and an Explorer link

DidRecord object id

The DID suffix is the shared DidRecord object id; clicking it opens the on-chain object

Registration date

Derived from the company creation event or the plan notarization

DID transactions

Digests of the did_registry::register and notarization::record transactions, opened on Explorer

All this information is accessible without authentication, ensuring maximum transparency. The scanner's public APIs also allow programmatic access to this data.

Frequently Asked Questions

No. On FenixTrace you sign in only with email and an OTP code: there are no wallets to install, no seed phrases to safeguard and no signatures to approve. Your company's on-chain key is generated and securely held by the server, which signs blockchain operations on your behalf. If you lose email access you recover it like any account: contact support — your DID identity and already registered products stay intact on-chain.

Yes. The DID in the form did:iota:<network>:<object_id> is exposed both in the public scanner and via /api/public/companies, and the shared DidRecord is readable by anyone via IOTA Explorer or an RPC client. The status (active/suspended/revoked) tracks the on-chain DidRecord and is reflected in the chip shown on the company page. You never have to manage or display any address: the identity is verifiable by anyone, but its control stays tied to the company account.

DID registration is included in the subscription cost. There are no additional costs for DID creation and you never have to worry about any gas fee: all on-chain transactions (DID registration, notarizations, product registration) are executed and covered by FenixTrace server-side. For you the only cost is your chosen plan.

Each company account maps to a single DID identity resolved by the platform. If you need multiple identities (e.g., for different branches or legal entities), create a dedicated company account for each, with its own plan: FenixTrace will generate a separate DID for every one, always automatically server-side. To bring in products from external management systems or e-commerce you do not need extra identities: the API keys generated from the dashboard are enough.

When the subscription expires the on-chain shared DidRecord stays where it is — nobody can delete it — but dashboard functionalities become limited. Already registered products remain visible in the scanner together with their on-chain proofs. To restore full functionalities just renew the subscription from the Pricing page.

Verify Identities

Visit the public scanner to verify the DID status of any company registered on FenixTrace. You can also use the public APIs to integrate verification into your system.