# Smart Contract Reference

The Stobox DID smart contract forms the on-chain identity layer for compliant tokenized asset operations. It manages decentralized identities (DIDs), linked wallets, identity attributes, and role-based permissions.

***

### **Contract Architecture Overview**

The DID contract includes the following components:

* **DID Registry** — stores and manages identity state.
* **Attribute Storage** — holds compliance attributes and metadata.
* **Address Linking Module** — associates user wallets with DIDs.
* **Role-Based Access Control** — defines who may perform administrative or read operations.
* **Event Layer** — logs all operations for full auditability.

These components form a unified identity system that STV3 assets query during compliance validation.

***

### **Data Structures**

#### **DID Record**

Each DID includes:

* unique DID identifier
* status (active, blocked, revoked)
* linked addresses
* attributes list

#### **Attribute Structure**

Attributes include:

* attribute key (identifier)
* attribute value
* timestamp
* expiration date (optional)
* active/inactive status
* issuer (administrator)

#### **Address Record**

For each address:

* linked DID
* activation status
* timestamp
* reference to issuer or admin role

These structures ensure precise, auditable identity tracking.

***

### **Roles & Permissions**

The DID contract uses RBAC (Role-Based Access Control) with several key roles.

#### **ADMIN ROLE**

Full control over:

* DID creation, blocking, revocation
* attribute assignment and modification
* wallet linking/unlinking
* contract configuration
* assigning other roles

#### **WRITER ROLE**

Allowed to:

* assign or update identity attributes
* link or unlink wallet addresses
* activate or deactivate wallets

#### **READER ROLE**

Allowed to:

* view DID status
* query attributes
* check wallet linkage

#### **EXTERNAL READER ROLE**

Time-limited permission for:

* auditors
* regulators
* partners requiring controlled access

This role expires automatically after a defined period.

***

### **Core Functions**

The following functions represent the most important developer-facing methods in the DID contract.

***

#### **DID Management**

**`createDID(address wallet)`**

Creates a new DID and links the provided wallet.

**`blockDID(did)`**

Disables all access for the DID and linked addresses.

**`unblockDID(did)`**

Reactivates a previously blocked DID.

**`revokeDID(did)`**

Permanently invalidates a DID, disabling all wallets.

***

#### **Wallet & Address Management**

**`linkAddressToDID(address wallet, did)`**

Associates a new wallet with an existing DID.

**`removeLinkedAddress(address wallet)`**

Unlinks a wallet from a DID.

**`activateAddress(address wallet)`**

Re-enables a previously deactivated wallet.

**`deactivateAddress(address wallet)`**

Temporarily suspends a wallet.

***

#### **Attribute Management**

**`addOrUpdateAttribute(did, key, value, expiration)`**

Assigns or updates an identity attribute.

**`deactivateAttribute(did, key)`**

Marks an attribute as inactive without deleting it.

**`updateAttributeExpiration(did, key, newExpiration)`**

Updates the validity period of an attribute.

***

#### **Query Functions**

These functions allow external contracts (e.g., STV3 tokens) to verify compliance.

**`getDID(address wallet)`**

Returns the DID associated with a wallet.

**`getAttributes(did)`**

Returns all attributes for the DID.

**`hasActiveAttribute(did, key)`**

Checks if the DID has an active attribute.

**`isAddressActive(wallet)`**

Checks if the wallet is active.

**`getDIDStatus(did)`**

Returns DID status (active/blocked/revoked).

***

### **Events & Audit Logging**

Events provide a transparent and immutable audit trail for compliance and identity operations.

Key events include:

* `DIDCreated`
* `DIDUpdated`
* `DIDBlocked`
* `DIDUnblocked`
* `DIDRevoked`
* `AddressLinked`
* `AddressActivated`
* `AddressDeactivated`
* `AddressRemoved`
* `AttributeAssigned`
* `AttributeUpdated`
* `AttributeRevoked`

Auditors and compliance systems use these event logs to reconstruct identity history.

***

### **Integration Notes for Developers**

#### **Compliance Modules Must Query DID**

Assets using STV3 validation must call DID query functions to:

* verify identity status
* check attributes
* validate wallet linkage
* enforce rules based on DID data

#### **Multiple Contracts Can Read DID State**

DID is designed as a global identity registry across:

* token contracts
* marketplaces
* custody systems
* corporate governance tools
* exchanges

#### **Use Events for Off-Chain Compliance Tools**

External services (KYC providers, admins, auditors) can subscribe to DID events to track updates.

#### **Access Control Must Be Respected**

Only administrator roles should manage DID states to avoid compliance breaches.

***

### **Error Handling and Edge Cases**

Developers should consider:

* expired attributes
* deactivated wallet addresses
* blocked DID states
* revoked DIDs
* invalid attribute combinations
* attributes that must be present for an action

A DID failure should result in the calling contract rejecting the transaction.

***

### **Summary**

The Stobox DID smart contract provides a complete, on-chain identity and compliance framework. Its clearly defined functions, roles, data structures, and events enable:

* deterministic compliance
* auditable identity management
* secure source-of-truth identity logic
* enterprise-level permission control
* seamless integration with programmable assets

This reference chapter enables developers and integrators to confidently build applications that depend on DID for identity validation and regulated workflows.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stobox.io/did/smart-contract-reference.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
