WORKED EXAMPLE · TOKEN ENGINEERING
Simple Token Design Lifecycle Example
This example shows how a token-based system moves from a first client requirement to a precise specification, validation, implementation handoff and post-launch review.
The mechanism is simple on purpose. Atlas runs a workshop for 30 persons. Atlas wants each registration to receive a digital access pass. A holder can transfer the pass to another person before check-in. A pass admits one person one time only.
We use one pass, Ticket 7, to trace the complete lifecycle. Anna owns Ticket 7 first. She transfers it to Ben before the workshop. Ben then uses it to enter. A second use of the same pass must fail.
The purpose is not to propose a complex token model. The purpose is to make the token engineering process visible with a mechanism that all persons can follow. Each phase shows the information that enters, the decisions that occur, the artifact that the phase produces and the conditions that permit the work to continue.
The example is fictional. It follows the five phases of the standard token design lifecycle.
ENGAGEMENT FLOW
-
1
Discovery→ 30 seats and one entry per ticket
-
2
Design→ Rules for issue, transfer and use
-
3
Model and test→ Worked cases and checked results
-
4
Implement and launch→ Tested ticket and door application
-
5
Monitor→ Entry log and improvement decision
A failed test returns the work to Design. A live issue returns the work to the relevant rule or test.
TRACE TICKET 7 THROUGH THE LIFECYCLE
| Concrete state | Rule | Action | Result |
|---|---|---|---|
| Ticket 7 owned by Anna | Transfer permitted before 17:30 | Anna transfers to Ben at 16:00 | Ben becomes owner |
| Ben arrives at 17:35 | Current owner may enter one time | Ben authorizes; Mei submits check-in | Ticket 7 becomes Used |
| Ticket 7 is presented again | Used tickets cannot authorize entry | Repeat check-in request | Request rejected |
DISCOVERY & REQUIREMENTS
Objective: define the access right, the system constraints and the responsible actors.
| Input | Specified value |
|---|---|
| Event | Atlas Workshop 01 · 14 November 2026 |
| Capacity and access | 30 seats; one pass admits one person; registration is free |
| Token definition | Atlas Workshop Pass (AWP); token IDs 1–30 |
| Check-in window | 14 November 2026, 17:30:00–18:00:00 UTC; 18:00 excluded |
| Actors | Nora issues passes; Anna and Ben hold passes; Mei operates check-in |
| Initial state | Ticket 7 is Active and owned by Anna |
| Client requirement | A holder can transfer the access right directly to another wallet before check-in |
| Acceptance criteria | Maximum 30 admissions; no pass used two times; all valid scripted cases succeed |
Responsibility map. Each actor holds one right. The ticket record holds the owner and the status of every pass.
Method: trace Ticket 7 from Anna to Ben. Define who can issue, transfer and check in a pass.
Output: agreed requirements and responsibility map.
MECHANISM DESIGN & SPECIFICATION
Objective: change the approved requirements into deterministic rules. Input: the Phase 1 brief and the start state of Ticket 7.
State diagram. Ticket 7 moves from Anna to Ben with a transfer. The ticket keeps one identity. A check-in sets the state to Used. The 18:00 cutoff sets every remaining Active ticket to Expired.
| Rule | Specified behavior |
|---|---|
| R1 Issue | Only Nora may issue tickets, and only before 17:30. Each ID from 1 to 30 permits one issue. A consumed ticket does not restore the issue capacity. |
| R2 Transfer | The owner or an authorized transfer operator may transfer an Active ticket before 17:30. Transfers stop at 17:30. |
| R3 Consume | From 17:30 inclusive to 18:00 exclusive, Mei may submit the signed approval of the current owner. A successful check-in sets the ticket to Used and removes it from circulation. |
| R4 Reject invalid action | A wrong owner, an unauthorized operator, an invalid time or a status that is not Active causes a rejection with no state change. |
| R5 Close | At 18:00, each remaining Active ticket becomes Expired. Used and Expired tickets cannot transfer and cannot authorize entry. This pilot has no override. |
Method: define the permitted state transitions and the conditions for each transition. A transfer changes the ownership and keeps the total supply.
Output: agreed rules and state diagram.
MODELING & VALIDATION
Objective: show that the rules keep the capacity and give the expected result for valid, invalid and boundary cases. Input: rules R1–R5, 30 issued tickets and Ticket 7 owned by Anna.
REFERENCE TEST CASES
| Test | Input | Expected result |
|---|---|---|
| T1 Capacity | Issue ticket 31 after IDs 1–30 | Reject; the lifetime issued count stays at 30 |
| T2 Transfer | Anna → Ben, ticket 7, 16:00 | Allow; Ben owns ticket 7 |
| T3 Former owner | Anna signs for ticket 7 at 17:35 | Reject; Anna does not own the ticket |
| T4 Single use | Ben signs; Mei submits at 17:35 | Allow; ticket 7 becomes Used |
| T5 Replay | Repeat ticket 7 at 17:36 | Reject; no second admission |
| T6 Boundaries | Transfer at 17:30; use at 17:29:59 / 17:59:59 / 18:00 | Reject; reject / allow / reject |
| T7 Operator permission | Omar submits instead of Mei | Reject; no state change |
State trace from the reference model. The total stays at 30 tickets at each point in time. At the close, 24 tickets are Used and 6 tickets are Expired.
Method: run the defined test cases and state transitions in a small Python reference model. The model checks the specification and the accounting logic, not the production code.
Output: test results and a state trace that shows 24 Used tickets and 6 Expired tickets, with a total issued supply of 30.
IMPLEMENTATION & LAUNCH
Objective: change the accepted specification into production behavior. Input: rules v1.0 and tests T1–T7.
↓ result of the three checks ↓
Ben signs the approval. Mei submits it. A screenshot gives no entry. The application shows Admit only after the network accepts the check-in transaction.
DEVELOPER HANDOFF EXAMPLE
| Item | Specified behavior |
|---|---|
| Action | Check in ticket 7 for Atlas Workshop 01 at 17:35 UTC |
| Pre-state | Owner = Ben; status = Active; authorized operator = Mei |
| Authorization | Ben signs an approval that binds the event, the ticket, the owner, the operator, the deployed contract and the network. The approval expires at 18:00. |
| Success transition | Set the status to Used; remove the circulating ownership; increase the used count; emit a check-in record for ticket 7. |
| Failure behavior | No state change; the application displays Denied; the operator does not admit the guest. |
| Implementation constraints | Apply the same time boundary to every transfer path; limit the lifetime issuance to 30; make the consumption and the use record atomic. |
Method: implement and test the contract and the application logic. Review the custom authorization and signature flows. Rehearse the check-in process. ERC-721 and OpenZeppelin give the base components. The event rules go on top of that base.
Output: reviewed release, test evidence, deployment record and operator instructions.
MONITORING & ITERATION
Objective: show that the live operation agrees with the specification. Input: the deployed release, the check-in records and the Phase 3 accounting invariant.
EVENT REVIEW EXAMPLE
| Metric | Observed record | Assessment |
|---|---|---|
| Tickets issued | 30 | Inside the lifetime issuance limit |
| Successful unique uses | 24 | 24 admissions recorded |
| Unused at the close | 6 Expired | 24 Used + 6 Expired = 30 |
| Duplicate requests | 2 rejected; 0 successful | The single-use constraint held |
| Closing boundary | 18:00 UTC; 0 later successes | No admission at or after the cutoff |
Monitoring decision path. A duplicate admission stops the door and returns the work to Phase 4. A rule change returns the work to Phase 2 and needs new validation in Phase 3.
Method: reconcile the recorded check-ins with the physical admissions. Review each rejected or unmatched attempt.
Output: event review and a recorded decision about mechanism changes.
Example decision: keep the single-use rule. Six unused tickets alone do not justify a change to the entry window. First find why those attendees did not check in.
END-TO-END TRACEABILITY
Each requirement maps to a design rule, a model test, an implementation instruction and a live control.
| Requirement | Design rule | Validation | Implementation control | Live control |
|---|---|---|---|---|
| Maximum 30 seats | R1: lifetime issuance ≤ 30 | T1: ticket 31 rejected | Limit the total issuance, including consumed tickets | Issued count ≤ 30 |
| Transfer the access right | R2: transfer before 17:30 | T2–T3: Ben gains the ownership; Anna loses it | Resolve the current owner at execution | Check-in approvals match the current owner |
| One admission per ticket | R3–R4: consume one time | T4–T5: the first use succeeds; the replay fails | Consume the ticket and record the use atomically | 0 duplicate successful uses |
| Close at 18:00 | R5: expire the remaining Active tickets | T6: 17:59:59 succeeds; 18:00 fails | Use one UTC cutoff on all paths | 0 successes at or after 18:00 |
| Only Mei may check in | R3–R4: authorized operator only | T7: Omar rejected | Verify the operator permission and the owner approval | Mei submits every successful check-in |
CLIENT OUTPUTS BY PHASE
PHASE 1
Requirements brief and responsibility map.
PHASE 2
Agreed rules and state diagram.
PHASE 3
Reference tests and results.
PHASE 4
Developer handoff and, inside the agreed scope, release evidence.
PHASE 5
Operating review and final decision record.
A standard token design engagement covers Phase 1 to Phase 3 and a defined developer handoff. Production development, independent security review, deployment, application development and live operations have a separate scope.