Related Documentation:
- API Standards - API endpoints and data formats
- Security - Security considerations for onchain operations
- Operations - Performance requirements and monitoring
A snapshot represents a configuration for calculating reputation scores at a specific point in time.
draft: Initial state, can be modified and executed multiple timescommitted: A workflow's results have been committed, making the snapshot immutable
- Create snapshot in
draftstate - Execute multiple workflows for testing while in
draft - User selects a specific workflow's results to commit
- Onchain commitment is made for the selected workflow's results
- Snapshot becomes
committedand immutable - No further workflows can be executed for this snapshot
{
"id": "snap_123",
"name": "Q1 2025 Governance Snapshot",
"status": "draft",
"created_at": "2025-06-01T12:00:00Z",
"commit": {
"workflow_id": null, // ID of the workflow whose results were committed
"timestamp": null, // When the commitment was made
"transaction": null, // Transaction ID of the onchain commitment
"block_number": null, // Block number of the commitment transaction
"merkle_root": null // Merkle root hash of the committed scores
},
"strategies": [
{
"strategy": {
"name": "token-weighted-voting",
"version": "1.0.0",
"hash": "0x1234..." // Keccak-256 hash of strategy code
},
"weight": 1.0,
"parameters": {
"start_block": 0,
"end_block": 12345678,
"min_balance": 100
}
}
]
}The system uses Temporal for workflow management, leveraging its robust workflow engine and state management capabilities. Each snapshot has a single main workflow that orchestrates the execution of child workflows for each strategy.
- Workflow states and status are managed by Temporal
- Workflow execution history is stored in Temporal
- Workflow progress and status are tracked by Temporal
- Workflow timeouts and retries are handled by Temporal
- Child workflows execute strategies in parallel
- Only one workflow can be committed per snapshot
Custom search attributes are used to link workflows with snapshots:
{
"snapshot_id": "snap_123" // Custom search attribute to link workflow to snapshot
}The workflow API proxies requests to Temporal, allowing querying of all workflows associated with a snapshot.
-
Main workflow (snapshot):
- Orchestrates the execution of child workflows
- Manages the overall snapshot lifecycle
- Handles commitment process
- Tracks progress of all strategies
-
Child workflows (strategies):
- Execute individual strategy calculations
- Run in parallel for better performance
- Report progress to parent workflow
- Handle strategy-specific errors
Each snapshot can have multiple workflow executions while in draft state. Once a workflow's results are committed, the snapshot becomes immutable and no further workflows can be executed.
Scores represent the calculated reputation values for subjects, tied to specific workflow executions.
{
"workflow_id": "work_123",
"snapshot_id": "snap_123",
"sub_id": "0x123...",
"strategy_scores": [
{
"strategy": {
"name": "token-weighted-voting",
"version": "1.0.0",
"hash": "0x1234..."
},
"score": 85.0,
"rank": 42,
"child_workflow_id": "work_124" // ID of the strategy's child workflow
}
],
"weighted_score": 87.1,
"weighted_rank": 35,
"calculated_at": "2025-06-01T12:00:00Z"
}- Calculate final scores for all subjects
- Generate Merkle tree of scores
- Submit root hash to smart contract
- Verify onchain commitment
- Update snapshot status to
committed
-
Score Finalization
- All child workflows must complete successfully
- Scores are aggregated and weighted
- Final scores are sorted and ranked
-
Merkle Tree Generation
- Each subject's score is hashed
- Leaves are sorted by subject ID
- Tree is built bottom-up
- Root hash is generated
-
Onchain Submission
- Root hash is submitted to smart contract
- Transaction is monitored for confirmation
- Commitment is verified onchain
-
Verification
- Merkle proofs can be generated for any score
- Proofs are verified against onchain root
- Historical commitments are preserved
interface IReputationSystem {
function commitSnapshot(
bytes32 snapshotId,
bytes32 merkleRoot,
uint256 blockNumber
) external;
function verifyScore(
bytes32 snapshotId,
address subject,
uint256 score,
bytes32[] calldata proof
) external view returns (bool);
}- Semantic versioning (MAJOR.MINOR.PATCH)
- Code hashing using Keccak-256
- Version registry in smart contract
{
"name": "token-weighted-voting",
"version": "1.0.0",
"hash": "0x1234...",
"parameters": {
"start_block": "uint256",
"end_block": "uint256",
"min_balance": "uint256"
}
}- Parameters are validated against strategy schema
- Type checking is enforced
- Range validation for numeric parameters
- Required parameters must be provided
- Default values are applied when appropriate
- Strategy execution errors are captured
- Failed strategies are retried automatically
- Maximum retry attempts are configurable
- Error details are logged for debugging
- Parent workflow is notified of failures
-
Snapshot Creation
- User creates snapshot with strategies
- System validates configuration
- Snapshot stored in
draftstate
-
Execution
- User triggers execution
- System creates workflow
- Strategies execute in parallel
- Progress tracked per strategy
- Scores calculated and stored
-
Commitment
- User reviews results
- System generates Merkle tree
- Root hash committed onchain
- Snapshot becomes immutable
-
Verification
- Anyone can verify scores
- Merkle proofs generated on demand
- Smart contract verifies proofs
-
Main Workflow
- Validates snapshot configuration
- Creates child workflows for strategies
- Monitors child workflow progress
- Aggregates results
- Handles commitment process
-
Child Workflows
- Execute strategy calculations
- Report progress to parent
- Handle retries on failure
- Store intermediate results
- Clean up temporary data
-
Error Recovery
- Automatic retries for transient failures
- Manual intervention for persistent issues
- Error reporting and logging
- State recovery mechanisms
-
Workflow Data
- Stored in Temporal
- Includes execution history
- Contains progress information
- Preserves error details
-
Score Data
- Stored in database
- Indexed by snapshot and subject
- Includes Merkle proof data
- Preserves historical records
-
Commitment Data
- Stored onchain
- Includes Merkle roots
- Preserves transaction details
- Enables verification