Strategic thesis

The first buyer is Pharmaceutical manufacturers, wholesalers, and dispensers. They don't need a generic blockchain story; they need a way to reduce disputes, speed approval, and make the current status of a workflow independently checkable.

State Dual manages

Serialized drug custody, verification, temperature exceptions, quarantine, recall, and dispense state.

The important point is not the number of states. It's that each transition has an actor, an allowed action, evidence, and a durable audit record. That turns operational workflow into an inspectable object.

Token architecture

Example object schema

{
  "template": "pharmchain",
  "category": "Custody state",
  "immutable": {
    "asset_id": "set_at_mint",
    "issuer_id": "set_at_mint",
    "serialization_standard": "set_at_mint",
    "origin_proof_hash": "set_at_mint",
    "created_at": "set_at_mint"
  },
  "mutable": {
    "custody_holder": "updated_by_event",
    "location_status": "updated_by_event",
    "verification_status": "updated_by_event",
    "exception_status": "updated_by_event",
    "last_handoff_at": "updated_by_event"
  },
  "rules": {
    "allowed_states": ["Manufactured","Serialized","Packed","In Transit","Received","Verified","Quarantined","Dispensed"],
    "first_buyer": "Pharmaceutical manufacturers, wholesalers, and dispensers",
    "audit_required": true
  }
}

This schema is intentionally scoped. A credible first product should prove one object type, one core state machine, and a small number of high-value integrations before expanding into a platform.

User journey

1. 1

   Issuer: Manufactured

   The PharmChain object is created with immutable identity, owner, and rule metadata.

2. 2

   Operator: Serialized

   An event moves the object into "Serialized", preserving the previous state and the actor that triggered the change.

3. 3

   Verifier: Packed

   An event moves the object into "Packed", preserving the previous state and the actor that triggered the change.

4. 4

   Counterparty: In Transit

   An event moves the object into "In Transit", preserving the previous state and the actor that triggered the change.

5. 5

   Auditor: Received

   An event moves the object into "Received", preserving the previous state and the actor that triggered the change.

6. 6

   Automation: Verified

   An event moves the object into "Verified", preserving the previous state and the actor that triggered the change.

7. 7

   Administrator: Quarantined

   An event moves the object into "Quarantined", preserving the previous state and the actor that triggered the change.

Event model

Dual becomes useful when outside systems stop being passive records and start becoming evidence sources for state transitions.

• ERP or WMS shipment events
• scanner/NFC/serial verification
• inspection or authenticator attestation
• regulator or marketplace query

Each event should answer four questions: who produced it, which object it affects, which transition it requests, and which proof should be retained for audit.

Why not just a database?

90-day MVP

1,000 serialized units through manufacturer-to-dispenser transfer with one exception and one recall query.

• Define the template and allowed state transitions.
• Mint test objects with realistic identity and ownership data.
• Wire one external event source into the Event Bus.
• Trigger one successful transition and one rejected transition.
• Expose a query view that proves current state and transition history.

Proof assets required

• DSCSA data map
• Custody transfer event
• Temperature exception
• Recall query

These assets are the difference between a concept note and a buildable wedge. Without them, the page is only a narrative; with them, it becomes a product specification.

Operating metrics

• handoff latency
• exception rate
• audit response time
• percentage of objects with complete provenance

These are the metrics that should be visible in the pilot dashboard. They also give sales, implementation, and investor conversations a concrete way to judge whether Dual is improving the workflow.

Commercial wedge

The first commercial motion should sell a narrow operational outcome, not broad tokenization. For PharmChain, the wedge is: run custody transfer. Price around the workflow value: fewer disputes, faster settlement, cleaner audit, lower fraud, or lower manual reconciliation.

Expansion should follow the state graph. Once the first transition is trusted, add the next actor, then the next integration, then the next reporting surface. That keeps the product grounded in workflow proof rather than speculative asset creation.

Risks and controls

• bad upstream data at mint. Control: define the trusted source, log every mutation, and keep manual override paths explicit.
• participants resisting shared custody proof. Control: define the trusted source, log every mutation, and keep manual override paths explicit.
• physical/digital mismatch if scanning controls are weak. Control: define the trusted source, log every mutation, and keep manual override paths explicit.

Implementation playbook

1. Map the workflow: identify the actor responsible for each state and the evidence required for each transition.
2. Create the template: split data into immutable identity, mutable state, and compliance rule fields.
3. Mint sample objects: use realistic IDs, timestamps, owners, and source-system references.
4. Connect one event: choose the event that makes the state change economically valuable.
5. Reject one bad action: demonstrate that Dual blocks invalid transitions before downstream settlement.
6. Expose audit: show current state, previous state, actor, timestamp, evidence hash, and rule result.

Build prompt

Create a Dual template for PharmChain. Model immutable identity fields, mutable lifecycle state, compliance checks, and event inputs. Then emit one test object and move it through: Manufactured → Serialized → Packed → In Transit → Received.

Include:
- object schema
- transition rules
- event payload examples
- one rejected transition
- audit query output
- MVP dashboard fields