Wage Protocol

Payroll obligations with automated split and audit state

Financial stateP1

Wage Protocol

Payroll obligations with automated split and audit state. Payroll workflows rely on batch files, delayed settlement, and post-hoc reconciliation between HR, payroll, tax, and payment systems.

Wage Protocol is strongest when treated as a governed state machine, not a static token. The object must carry enough identity to be trusted at mint, enough mutable state to reflect the real workflow, and enough audit history for a third party to decide whether the current state is reliable.

Strategic thesis

Why this wedge exists

Payroll becomes a governed obligation object with auditable split logic instead of a sequence of opaque file exports.

The first buyer is Payroll platforms, gig platforms, and finance teams. 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

Gross wages, deductions, tax status, benefit splits, payment release, and jurisdictional rules.

EarnedCalculatedWithholding AppliedApprovedDistributedReconciled

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

Immutable identityinstrument_id, issuer_id, counterparty_set, legal_wrapper_hash, created_at
Mutable statefunding_status, approval_status, accrued_amount, settlement_status, last_payment_at
Compliance rulesPayout requires all prerequisite evidence to be present. Transfer or payment can be blocked by role, jurisdiction, limit, or expiry. Every value change records actor, timestamp, and source event.
Event sourcespayment rail confirmation, bank or escrow status, approval workflow, invoice, claim, meter, or revenue event

Example object schema

{
  "template": "wage_protocol",
  "category": "Financial state",
  "immutable": {
    "instrument_id": "set_at_mint",
    "issuer_id": "set_at_mint",
    "counterparty_set": "set_at_mint",
    "legal_wrapper_hash": "set_at_mint",
    "created_at": "set_at_mint"
  },
  "mutable": {
    "funding_status": "updated_by_event",
    "approval_status": "updated_by_event",
    "accrued_amount": "updated_by_event",
    "settlement_status": "updated_by_event",
    "last_payment_at": "updated_by_event"
  },
  "rules": {
    "allowed_states": ["Earned","Calculated","Withholding Applied","Approved","Distributed","Reconciled"],
    "first_buyer": "Payroll platforms, gig platforms, and finance teams",
    "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: Earned

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

  2. 2

    Operator: Calculated

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

  3. 3

    Verifier: Withholding Applied

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

  4. 4

    Counterparty: Approved

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

  5. 5

    Auditor: Distributed

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

  6. 6

    Automation: Reconciled

    An event moves the object into "Reconciled", 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.

  • payment rail confirmation
  • bank or escrow status
  • approval workflow
  • invoice, claim, meter, or revenue event

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?

Traditional system

A payroll database can calculate values, but counterparties cannot independently verify state, split logic, or signed approval history.

That's acceptable when one organization owns the full workflow. It breaks down when multiple parties need to trust the same current state without relying on a single application owner.

Dual stateful object

Dual separates immutable identity, mutable lifecycle state, compliance checks, and event history. Participants can inspect the current object state, verify the transition path, and use the same state as input to payment, access, reporting, or downstream automation.

90-day MVP

One jurisdiction, one employer, one worker class, and a compliant gross-to-net split into worker, tax, and benefit destinations.

  • 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

  • Jurisdiction rule map
  • Gross-to-net event
  • Failed compliance check
  • Payment rail model

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

  • time to settlement
  • manual reconciliation avoided
  • dispute rate
  • approved value processed

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 Wage Protocol, the wedge is: test one payroll split. 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

  • legal treatment of the entitlement. Control: define the trusted source, log every mutation, and keep manual override paths explicit.
  • payment rail integration complexity. Control: define the trusted source, log every mutation, and keep manual override paths explicit.
  • counterparty onboarding friction. 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 Wage Protocol. Model immutable identity fields, mutable lifecycle state, compliance checks, and event inputs. Then emit one test object and move it through: Earned → Calculated → Withholding Applied → Approved → Distributed.

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

Use this as a scoped wedge: prove one governed state transition, one external event, and one audit query before expanding the workflow.

Start with the Dual quickstart →