№ 04·0204 · How WCN works4 min read · Section 2 of 4

4.2 The path from Node to Settlement

The full workflow, stage by stage: resource entry, Deal, Task, Proof, and Settlement — with timelines and exception handling.

Updated
4.2 · Full process

From Node entry to Settlement, every step carries an owner, a status, and an output.

This page connects WCN's modules in their actual running order — from the moment a resource enters the network to the moment value is settled. Each stage carries an expected timeline, defined outputs, and an exception path.

Process stagesResource entry → Deal and Task → Proof and Settlement
Typical cycleSimple loop 1–2 weeks, complex deal 4–8 weeks
TradFi referencePipeline management in PE and VC
The loop runs Node → Deal → Task → Proof → Settlement. A resource enters, work advances inside a Deal and its Tasks, evidence is verified, and value settles.

Stage one: a resource enters (Day 0–2)

The system does not start with a form or a page. It starts when a responsible node brings a real resource into the network.

Project nodeSubmits project information: product stage, funding need, token position, target region, and core team. The data enters Project Intake as a structured record.
Capital nodeRegisters investment preferences: stage (seed, A, B), track (DeFi, AI, RWA, Infra), ticket range, and region. Preferences enter the Capital Profile for matching.
Service nodeRegisters execution capability: legal, audit, security, branding, development, or research. The capability enters the Service Registry and a Deal can call it.
Regional nodeRegisters a local network: country and city coverage, industry relationships, regulatory awareness, and event access. This supports cross-border deals.

Industry reference. This stage mirrors CRM intake in PE and VC — the pipeline intake of tools like PitchBook or DealCloud. WCN differs in one respect: it sets up a multi-party collaboration structure from the first step, rather than one firm managing a pipeline internally.


Stage two: Deal and Task advance (Day 2–14+)

Once a resource enters, it must move from information to a workflow.

Deal Room createdThe system opens a Deal Room for the matched opportunity, naming the Deal owner, the parties, the bill of materials, and the milestones. This is not a group chat; every role is defined.
Tasks dispatchedSpecific Tasks go to human nodes or agents. Each Task carries an owner, a deadline, an output requirement, and acceptance criteria. No Task ships as a vague instruction.
Execution advancesMeetings, due diligence, document assembly, legal review, contract drafting, and growth work all occur or are recorded in the system. Agents assist with research, minutes, and reminders.
Status trackedEach Deal and Task carries a live status: in progress, awaiting reply, blocked, or complete. The Execution Agent detects stalls and raises an alert.

Timeline reference. A simple service match — for example, pairing an audit requirement with a provider — can complete in 3 to 5 days. A complex financing deal, with several meeting rounds, due diligence, and legal review, typically takes 4 to 8 weeks. WCN does not reduce the complexity of the business; it removes coordination friction. TradFi studies indicate that 30 to 40 percent of deal time is spent on information sync and chasing.


Stage three: verification and settlement (3–7 days after the result)

Once a result forms, the system switches from execution logic to proof logic.

Evidence packagedThe Deal owner submits the result evidence to the Proof Desk: agreement, payment record, deliverables, onchain hash, meeting minutes, and counterparty confirmation. The evidence required depends on the Deal type.
Review queueThe evidence package enters the reviewer queue. The reviewer checks completeness, authenticity, timeline consistency, and risk markers. Reviewers and Deal participants cannot overlap.
Attribution assignedAfter review passes, the system assigns attribution: who sourced, who advanced, who executed, and who reviewed, each as a share. Attribution rests on the evidence chain, not on negotiation.
Proof and SettlementOnce attribution is confirmed, the result enters the Proof ledger as a Verification Node and becomes settlement input. The periodic Settlement run distributes value to the participants.

A loop verifies only when four conditions hold: the result is externally observable, the evidence is verifiable, responsibility is traceable, and the process is re-reviewable. Reconciliation across the three ledgers produces the Verification Node.


Exception handling: when the process stalls

Real business does not always run cleanly. WCN designs a defined path for each failure mode.

Deal stalledIf a Deal has no status update past a set number of days, the Execution Agent notifies the Deal owner. A Deal that stays unresponsive is marked Stalled, which frees the attached nodes.
Task overdueIf a Task passes its deadline, the system escalates the notice. The Task owner must give a reason: delay, blocker, or cancellation. An unanswered Task affects the node reputation score.
Evidence insufficientWhen a reviewer finds the evidence incomplete, the package returns with a list of missing items. The Deal owner has a limited window to supply them. A package returned three times enters the dispute channel.
Attribution disputeWhen parties contest the attribution shares, the case enters arbitration. An independent review committee issues a Verdict on the evidence chain. The Verdict is recorded and sets a precedent.

Exception handling is not an auxiliary feature. A system that cannot resolve failure and dispute earns no trust in real business. WCN treats exception paths as first-class.


The full path, end to end

Resource entry (Day 0–2) → Deal Room created and matched (Day 2–3) → Tasks assigned and executed (Day 3–14+) → result forms (Day N) → evidence submitted to the Proof Desk (Day N+1) → review and attribution (Day N+3–5) → Verification Node generated (Day N+5) → periodic Settlement run.

The three stages form one value chain: resource entry, workflow advancement, then verification and settlement. Each stage has a defined input, an owner, a time expectation, and an exception path. This is not a framework on paper; it is a system that can be engineered and audited.