Statur
Overview
This documentation offers a comprehensive overview of Statur, also known as the Self-Sovereign Pseudonymous Reputational Model, and its components, which include Non-Transferable (Soulbound) Tokens and Dynamic Content NFTs.
The self-sovereign pseudonymous reputational model is a revolutionary solution that allows projects to gather, utilize, and disseminate information about their pseudonymous users, while preserving user data sovereignty. This concept employs two cutting-edge technologies: non-transferable (soulbound) tokens and dynamic content NFTs.
Non-Transferable (Soulbound) Tokens
Soulbound tokens are unique assets whose non-transferability is enforced by the validator logic of the reputation contract. Cardano does not have a protocol-level mechanism to prevent token transfers; instead, the reputation contract simply has no spend path that allows the token to leave the contract address. The token is minted directly to the contract address - never to a user's wallet - and the only way to remove it is to burn it.
These tokens facilitate the recording of a "soul point" within the reputation contract, which a user can either endorse or reject.
Soulbound Token Flow
- A Cardano-based project records a soul point within the reputation contract, linked to a user’s on-chain identity.
- A “basic” soul point is stored on-chain as a UTxO at the contract address containing pertinent data.
- The user can endorse the basic soul point or reject it.
- If the user opts to discard the soul point, the UTxO is consumed and the token is burned. The transaction history remains on the blockchain permanently (as is true of all Cardano transactions), but the active reputation anchor is removed and the underlying reputation data cannot be reconstructed from the on-chain hashes alone.
- If the user accepts the soul point, it is assigned a new “endorsed” signature.
- The user retains the ability to reconsider at any moment and burn the soul point.
Dynamic Content NFTs
NFTs are typically used to hold unique, static information on-chain. However, the capacity to dynamically update this data off-chain, without compromising the essential decentralization aspect, is highly desirable.
With our unique decentralized data storage network, an NFT can serve as a pointer to a file. The contents of this file are subject to change by users who hold certain access rights on the storage network.
Reputational Model
By integrating the eUTXO model with our decentralized storage mechanisms, we can accumulate reputational information about a user's wallet and store it on our decentralized storage network. The on-chain file index tied to a user's wallet functions as a pointer to data that projects can dynamically update with information regarding the user's participation and behavior.
End-to-End Reputation Flow
General Overview
The reputation contract system offers a straightforward yet effective mechanism for providing on-chain, verifiable reputation data. Users join the reputation system by entering into the smart contracts. A user's reputation data is then updated in real time using an off-chain database. Every user's on-chain data is periodically updated automatically using the off-chain data.
The goal of the system is to provide users with a cost-efficient and scalable method for storing and updating their reputation data. We opt for constant-cost and highly parallelizable smart contracts over variable costs and rigid solutions, resulting in a unique blend of on-chain and off-chain protocols. The final product is a system for storing reputations on-chain while updating them in real-time via an off-chain database.
Entering the Reputation Contract
Each user will have a single UTxO inside the reputation contract, holding a special and soulbound NFT. The token may not leave the contract due to validator logic. A user may remove their UTxO from the reputation contract at any time; however, this will result in the burning of the soulbound token. The token serves as a unique identifier of a user's reputation, which is stored on-chain as a hash in the datum. The full reputation data is maintained in an off-chain database to support large data structures.
The soulbound token, the datum (containing the user's identity and reputation hash), and the ADA value all live together inside a single UTxO at the contract address. This is what ties a user's on-chain identity to their reputation state - the token acts as a thread that follows the UTxO through every update, ensuring continuity across transactions. This is a well-established design pattern in Cardano smart contract development.
Users will contribute Lovelace to a fee contract for periodic updates. A special batcher uses the off-chain database and fee contract to perform reputation updates efficiently through transaction chaining.
Updating a User's Reputation
Reputation data is stored in an off-chain database. Storing complex data on-chain is limited by blockchain protocol constraints, so we only store a hash on-chain. Updates involve changing the hash of the off-chain data structure in a verifiable and reproducible way. These updates are efficient and allow for batch transactions. Users may also trigger updates independently if desired.
Off-Chain Reputation Database
The off-chain reputation database operates as an account-based state machine. Each update (or transition) to a user's reputation is signed by an authorized party and stored in a linear history. This ensures full traceability and allows users to reproduce and verify their reputation state independently.
Users can selectively authorize projects to update their data. For example, a user in the Iagon ecosystem may allow Iagon to track and update their data. Other projects cannot update a user's reputation without explicit permission. Thus, reputation is user-centric and ecosystem-specific.
The on-chain reputation data is stored as a Blake2b-256 hash of the canonical form of the user's reputation data. This allows for on-chain verification of off-chain data by reconstructing the hash step by step.
Reputation Scoring
Each user's reputation score is calculated as a weighted average of their active metric values within a given project:
score = SUM(value × weight) / SUM(weight)Each project defines its own metrics and assigns a weight to each one, determining how much influence that metric has on the overall score. Only active metrics with recorded values are included in the calculation.
When a user's membership in a project becomes inactive, an optional time decay can be applied. If the project has configured a decay rate, the score decreases exponentially over time following deactivation. Active memberships always use the base weighted average with no modification.
Scores are not stored in the database - they are calculated on demand from the current metric values. While the full data is off-chain, the on-chain hash ensures transparency and verifiability.
List of Reputation Metrics
Statur does not impose a fixed set of metrics. Each project defines its own metrics with its own value ranges and weights, tailored to what is meaningful within that project’s context. The system provides the scoring infrastructure; projects provide the domain knowledge.
The following table shows an example set of metrics as used by Iagon for evaluating node reputation within its decentralized storage network.
| Metric Name | Description |
|---|---|
| Read Speed | Average time taken by a node to retrieve stored data. |
| Write Speed | Average time required to write data to the node. |
| Download Speed | Download throughput measured during user data retrieval. |
| Upload Speed | Upload throughput measured during data storage to the node. |
| Uptime | Percentage of time the node remains online and available. |
| Pledge Amount | Total ADA pledged by the node operator. |
| Delegation Amount | Total ADA delegated by users to the node. |
| Number of Delegators | Number of individual delegators to the node. |
| Node Size | Total storage capacity available on the node. |
| Minimum Delegation | Minimum amount of ADA accepted by the node. |
| Maximum Delegation | Maximum amount of ADA accepted by the node. |
| Margin Percentage | Percentage of rewards taken as margin by the node operator. |
These metrics are specific to Iagon’s use case and illustrate how a project can define contribution, reliability, and performance measures within Statur’s framework.
INFO
This list is part of the first phase of development and may be revised or extended as the system evolves. Additional metrics may be introduced based on community feedback, new use cases, and technical requirements.