> For the complete documentation index, see [llms.txt](https://wageflow.gitbook.io/docs.wageflow/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wageflow.gitbook.io/docs.wageflow/where-liquidity-comes-from-the-role-of-defi-in-wageflow.md).

# Where Liquidity Comes From: The Role of DeFi in WageFlow

In the traditional EWA model, liquidity exists in a pre-committed form: the platform advances funds and waits for payroll settlement later.

WageFlow does not adopt this structure. When liquidity pre-committed under uncertain conditions, it inevitably leads to risk concentration.

**DeFi as a Conditional Participant, Not a Funding Pool**

In WageFlow’s design, on-chain liquidity does not automatically cover all settlement requests. Each settlement is an independent, rejectable participation event.

The participation of liquidity depends solely on the fulfilment of verifiable set of conditions, rather than the credit or commitment of any single entity.

**Settlement Requires Proof, Not Trust**

In WageFlow, every settlement or disbursement request must satisfy three minimal conditions:

1. Business performance metrics for the current cycle have been submitted and committed.
2. Request amounts and fund usage comply with protocol rules (e.g., exposure, utilization, concentration limits).
3. No freeze conditions are triggered (such as missing reports, metric breaches, or proof verification failures).

These conditions are submitted on-chain via zero-knowledge proofs (ZK proofs) or equivalent verifiable mechanisms, so the on-chain system only evaluates whether the constraints are met—it never accesses raw business data.

Most importantly, these conditions are not conveyed via declarations or signatures, but through cryptographically verifiable proofs submitted to the protocol.

                                INIT → COMMITTED → VERIFIED → SETTLED

For each organization and each cycle, there is a clearly defined state transition:

                                                           FROZEN

If the state fails to meet the constraints, it enters：

Settlement logic is allowed to execute only in the VERIFIED state. In the COMMITTED or FROZEN states, fund flows cannot be triggered.

Therefore, liquidity participation is “permitted,” not “requested.”\
Settlement logic is not triggered until proofs are verified; if proofs are missing or verification fails, the protocol directly rejects execution.

**No Proof, No Execution**

The preconditions for triggering a settlement include:

* Business performance metrics for the current cycle have been submitted and committed as a state commitment.
* The requested amounts comply with protocol rules (e.g., exposure and concentration thresholds).
* No freeze conditions are triggered (such as missing reports, metric breaches, or proof failures).

These conditions are not conveyed via declarations; they are submitted on-chain through verifiable mechanisms. The settlement logic can not be triggered until the proofs are validated. In the event of missing or failed verification, the system does not pause for manual intervention—it defaults to instant rejection.

This transforms liquidity participation from a “credit-based commitment” into “rule-driven execution.”

**Risk Management and Verifiable Safeguards**

In the wage settlement context, the most significant risk does not come from on-chain execution failures, but from off-chain state uncertainties being incorrectly propagated on-chain.

WageFlow’s technical design does not attempt to eliminate these uncertainties. Instead, it ensures that the system remains dormant until uncertainties are proven to be controllable.

**ZK(Zero-knowledge) Proof as a Risk Boundary, Not a Privacy Feature**

In WageFlow, the core role of zero-knowledge proofs (ZK) is not to hide data, but to answer a single question:\
“Given the current state, is this settlement allowed to execute?”

Each cycle, the statements verified by the protocol can be abstracted as:

* The current state is correctly derived from submitted metrics and rules.
* The state commitment matches the on-chain record.
* No freeze conditions or threshold limits are triggered.

These constraints are encoded in the ZK circuit, and the on-chain protocol only verify the proof, never accessing raw business data. The chain does not assess whether the business actually occurred, it evaluates whether the pre-defined constraints have been satisfied.

At the same time, ZK also provides disclosure consistency guarantees: the state summary presented by the SaaS layer to liquidity providers must match the on-chain state commitment. On-chain proof verification ensures that the state was indeed derived from enterprise-submitted metrics according to the established rules, preventing selective disclosure or backdated tampering.

**Risk Control Through Inaction**

WageFlow does not assume that the proofs will always be available. On the contrary, the system treats the following situations as explicit risk signals:

* Proofs are not generated within the required time window.
* Submitted proofs failed the verification.
* Off-chain state conflicts prevent a valid proof from being constructed.

In these cases, the protocol does not enter a “pause” or “manual intervention” mode. Instead, it directly rejects the relevant settlement request.

Non-execution itself is the protection mechanism.

**Risk Is Contained, Not Eliminated**

Unlike models that rely on post-settlement reconciliation, recovery, or capital replenishment, WageFlow’s risk control occurs before execution.

If a particular state cannot be proven, it does not produce a settlement outcome within the system logic.

This design sacrifices some immediacy, but in return, it establishes a safety boundary that holds even under extreme conditions.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wageflow.gitbook.io/docs.wageflow/where-liquidity-comes-from-the-role-of-defi-in-wageflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.