# Identity Attributes

Identity attributes define the compliance and eligibility profile of a DID. They determine **how**, **where**, and **under what conditions** a user or organization can interact with tokenized assets.

Attributes allow the Stobox DID system to enforce regulatory rules directly at the protocol level, enabling programmable compliance across jurisdictions and asset types.

Every programmable asset issued via STV3 references DID attributes to determine whether a transfer, redemption, governance action, or allocation is permitted.

***

### **What Are Identity Attributes**

Identity attributes are structured pieces of metadata associated with a DID.\
They may represent:

* legal status
* compliance requirements
* jurisdictional rules
* investor classification
* time-bound restrictions
* permissions or prohibitions
* attestations from verifiers

Attributes act as **programmable rules** that define who a DID represents and what that DID is allowed to do within a regulated ecosystem.

***

### **Types of Identity Attributes**

Attributes are highly flexible and customizable. Common categories include:

#### **Jurisdiction Attributes**

Define the country or regulatory framework applicable to the identity.

Examples:

* “US Investor (Reg D)”
* “EU Investor (MiFID)”
* “Restricted Jurisdiction”
* “Offshore Entity”

These attributes restrict or allow participation in specific offerings.

#### **Investor Type Attributes**

Classify participants according to financial regulations.

Examples:

* accredited investor
* institutional investor
* retail investor
* qualified purchaser
* professional client

Investor categories determine eligibility for securities, private placements, and structured products.

#### **Compliance & Sanctions Attributes**

Reflect risk screening and eligibility status.

Examples:

* AML/KYC passed
* sanctions check passed
* PEP (politically exposed person)
* blacklisted identity
* enhanced due diligence required

These attributes influence asset eligibility and transfer permissions.

#### **Access & Permission Attributes**

Define specific rights within the ecosystem.

Examples:

* allowed to receive distributions
* allowed to transfer tokens
* restricted from secondary trading
* governance voting permission
* allowed for conversion/redemption

These attributes can be asset-agnostic or asset-specific.

#### **Time-Based Attributes**

Contain validity periods or expiration dates.

Examples:

* KYC valid until 2026
* “lockup period until YYYY-MM-DD”
* vesting restrictions
* eligibility window for certain actions

This supports dynamic compliance that changes over time.

#### **Custom Attributes**

Enterprises can issue their own attributes to support:

* SPV-specific rules
* role-based governance
* corporate hierarchies
* on-chain whitelists
* performance-based access
* private network membership

Custom attributes extend Stobox DID to unique business requirements.

***

### **Attribute Structure**

Each identity attribute contains:

* **code / identifier** (unique key)
* **value** (e.g., “accredited”, “EU”)
* **status** (active, inactive)
* **issuer** (administrator assigning the attribute)
* **timestamp** (when created or updated)
* **expiration date** (optional)

This structure ensures attributes are:

* consistent
* readable
* auditable
* enforceable

***

### **Attribute Creation & Assignment**

Authorized administrators (WRITER\_ROLE) can:

* assign new attributes
* update existing attributes
* change attribute values
* set expiration dates
* deactivate outdated attributes

Every operation is recorded on-chain, ensuring full transparency.

On-chain events emitted:

* **AttributeAssigned**
* **AttributeUpdated**
* **AttributeRevoked**
* **AttributeExpired**

***

### **Attribute-Based Compliance Enforcement**

Attributes control what identities can or cannot do. During each action (e.g., token transfer), the STV3 validation engine queries the DID contract to verify:

* whether the identity meets asset-specific rules
* whether restrictions or limits apply
* whether required attributes are active
* whether any attributes block the action

Examples:

* A carbon credit cannot be transferred to a DID lacking environmental authorization.
* A security token transfer is blocked if the investor is not accredited under the issuing regime.
* A commodity token cannot be redeemed if the DID’s jurisdiction prohibits custody.
* A fund redemption is allowed only if the investor has valid KYC/KYB attributes.

Compliance becomes **deterministic**, not procedural.

***

### **Attribute Expiration & Renewal**

Attributes may expire for regulatory or operational reasons:

* KYC/KYB may require periodic renewal
* accreditation may expire annually
* lockup periods end automatically
* governance rights may be time-limited

When an attribute expires:

* its status becomes inactive
* the identity may lose certain permissions
* dependent actions become restricted
* automated compliance systems flag the identity

Expiration supports ongoing regulatory adherence without manual intervention.

***

### **Attribute Revocation**

Attributes may be revoked if:

* verification fails
* risk profile changes
* sanctions lists update
* investor becomes ineligible
* fraud or misconduct is detected

Revocation immediately affects the DID’s permissions.\
Assets relying on those attributes will automatically enforce updated rules.

***

### **Multi-Attribute Logic**

DIDs can hold multiple attributes simultaneously, and programmable assets can require combinations of attributes, such as:

* jurisdiction = EU
* investor type = professional
* KYC status = valid
* sanctions check = passed

This allows highly granular regulatory enforcement.

***

### **Auditability & Traceability**

Each attribute event is stored on-chain, enabling transparent identity reports:

* full history of attribute changes
* compliance audits
* identity lifecycle tracking
* forensic investigations
* regulatory reporting

Administrators can query the DID registry to verify whether identities met requirements at any point in time.

***

### **Summary**

Identity attributes are the core of Stobox DID’s compliance framework. They convert identity verification, eligibility, and regulatory rules into programmable conditions enforced on-chain by the STV3 Protocol.

Attributes enable deterministic compliance, dynamic permissions, multi-jurisdictional support, and transparent auditing — all essential for regulated institutions operating tokenized real-world assets.

***