🕒Different Time Fields
BitBadges uses various time-related fields to manage permissions, timelines, transfers, and ownership. Understanding these fields is crucial for effectively managing collections and badges.
Time Representation
All times in BitBadges are represented as UNIX time, which is the number of milliseconds elapsed since the epoch (midnight at the beginning of January 1, 1970, UTC).
Time Field Types
1. permanentlyPermittedTimes
Purpose: Defines the times when a permission will always be executable.
Usage: Setting allowed periods for specific actions.
2. permanentlyForbiddenTimes
Purpose: Defines the times when a permission will always be forbidden.
Usage: Setting restricted periods for specific actions.
3. timelineTimes
Purpose: Specifies when a field is scheduled to have a specific value in a timeline-based field.
Usage: Scheduling changes to collection or badge properties over time.
4. transferTimes
Purpose: Defines when a transfer transaction can occur.
Usage: Setting periods when badges can be transferred between addresses.
5. ownershipTimes
Purpose: Specifies the times that a user owns a badge.
Usage: Defining the duration of badge ownership for users.
Important Note
The timelineTimes
in permissions correspond to the updatability of the timeline, while timelineTimes
in the actual timeline represent the actual times for the values.
Examples
Example 1: Presidential Election Badges
Scenario: Users participate in a US presidential election by casting votes through badge transfers.
T1: Conclusion of voting
T2: Start of presidential term
T3: End of presidential term
Setup:
transferTimes
: [{ start: T1, end: T2 }] (President badge can be transferred after voting concludes)ownershipTimes
: [{ start: T2, end: T3 }] (Defines the presidential term)
Example 2: Managing Collection Archival
Scenario: A collection can be optionally archived by the manager from T1 to T2, but is non-archivable at all other times.
Before archiving:
After archiving for all times:
Example 3: Permanently Locking Permissions
Scenario: Continuing from Example 2, the manager wants to permanently lock the permission.
Final state:
Best Practices
Clear Timelines: Always define clear and non-overlapping time ranges for each field to avoid confusion and conflicts.
Permission Management: Carefully consider the implications of setting
permanentlyPermittedTimes
andpermanentlyForbiddenTimes
, as these can significantly impact the flexibility of your collection.Timeline Planning: When using
timelineTimes
, plan your collection's lifecycle in advance to minimize the need for frequent updates.Transfer Windows: Use
transferTimes
to create specific windows for badge transfers, which can be useful for time-limited events or phased distributions.Ownership Tracking: Leverage
ownershipTimes
to create badges with time-bound ownership, useful for temporary privileges or rotating responsibilities.Permission Locking: Be cautious when permanently locking permissions (as in Example 3), as this action is irreversible and may limit future flexibility.
Time Synchronization: Ensure all systems interacting with your BitBadges collection are properly time-synchronized to avoid discrepancies in time-based operations.
By understanding and effectively using these time fields, you can create sophisticated and dynamic badge systems in BitBadges, enabling complex scenarios from voting systems to time-bound privileges and beyond.
Last updated