How Decrow uses Cloak for private USDC payroll

Payroll privacy is not just a nicer way to send money. It is the difference between paying people on a public ledger and running a payroll process that respects compensation, vendor pricing, treasury controls, and auditability.

That distinction matters for Decrow. We are building private USDC payroll for global web3 teams, and the product has two jobs that have to work together. Decrow manages the payroll operation: recipients, approval steps, treasury signing, execution state, retries, reconciliation, and audit history. Cloak provides the confidential execution layer on Solana, so payout details are not simply broadcast as public explorer data.

This article explains how those pieces fit together, what Cloak does, what Decrow does, and why both layers are needed for stablecoin payroll to feel usable by a real team.

Why public transfers are not enough for payroll

A raw USDC transfer is fast and useful. But payroll is not a raw transfer. Payroll is a recurring business process with sensitive information attached to it.

When a team pays contributors, vendors, grantees, or contractors from a public treasury wallet, the public chain can expose:

who received money from the treasury;
how much each person or vendor received;
when each payment cycle happened;
how payments changed over time;
which addresses are tied to recurring contributors;
how large a team or program may be based on payout volume.

For some treasury activity, public visibility is acceptable. For compensation and vendor pricing, it usually is not. A team's contributors should not need to accept public compensation data just because the team prefers stablecoin settlement. Finance should still have records, recipients should still receive funds, and authorized reviewers should still be able to inspect the run. The public internet does not need the full payroll feed.

That is the core design principle behind Decrow's privacy model: keep payroll accountable to the right people without making compensation public by default.

Where Cloak fits

Cloak describes itself as a privacy stack on Solana built around a shielded UTXO model and zero-knowledge proofs. Its platform has three main surfaces: the TypeScript SDK, the Shield Pool program for on-chain verification, and circuit artifacts for proof generation and verification (Cloak platform overview).

For Decrow, the important part is that Cloak gives us a confidential execution layer. Instead of treating the public transfer as the entire payroll event, Decrow routes execution through Cloak-backed settlement. Cloak's docs describe private treasury flows, withdrawals, transfers, swaps, compliance-aware scanning, viewing keys, and nullifier-based spend protection. Decrow uses that privacy infrastructure for payroll execution, while the payroll product manages the operational context around it.

In simpler terms:

Decrow knows what payroll run the team is trying to execute.
Decrow knows which recipients are ready.
Decrow knows which approvals are required.
Decrow knows whether the run is draft, in review, executing, completed, or blocked.
Cloak handles the confidential Solana transaction path that keeps payout details from being plainly readable on a public explorer.

That separation is important. Cloak is not a payroll app. Decrow is not trying to rebuild a privacy protocol. The product combines both layers: payroll workflow plus confidential settlement.

How the execution model works at a high level

Cloak's production SDK path is the UTXO API. The docs describe APIs such as transact, transfer, partialWithdraw, and fullWithdraw, all exported from @cloak.dev/sdk (Cloak UTXO transactions).

The transaction semantics matter:

a positive external amount represents a deposit into the shielded pool;
a negative external amount represents a withdrawal;
a zero external amount represents a fully shielded transfer.

Under the hood, the SDK builds a zero-knowledge proof and public inputs, then submits the resulting on-chain transaction. Cloak's transaction flow documentation describes proof bytes, public inputs, roots, nullifiers, commitments, mint data, and chain note hashes as part of the runtime path (Cloak transaction flows).

For a payroll operator, none of that should feel like a protocol dashboard. Inside Decrow, the operator is thinking in payroll terms:

Build a payout run.
Confirm recipients.
Route review and approval.
Sign from the treasury.
Execute confidentially.
Reconcile what happened.
Keep an audit history.

The Cloak layer is doing privacy and settlement work under that surface. Decrow presents the operational workflow around it.

What stays private

The most important privacy goal is simple: compensation details should not be public by default.

In a public transfer model, an observer can inspect treasury activity and follow payment amounts to recipient addresses. With Cloak-backed execution, payout settlement goes through a shielded path. Cloak's own site describes confidential transfers where senders, recipients, amounts, and history are hidden from public explorers while zero-knowledge proofs preserve validity (Cloak).

For Decrow's payroll use case, that means the public ledger should not become the team's payroll spreadsheet. The team can still run USDC payroll on Solana, but payout details do not need to be broadcast in the same way a plain SPL transfer would broadcast them.

That is especially important for recurring payroll. One public payment may be a small leak. A monthly payroll cycle becomes a data set. Over time, people can infer contributor rosters, compensation bands, grant sizes, vendor pricing, team growth, and churn. The privacy risk compounds because payroll repeats.

What remains visible to the workspace

Privacy cannot mean losing control of the business process. If a payment is confidential but nobody can answer who approved it, what changed, or whether it reconciled, the system is not suitable for payroll.

Decrow keeps operational records around the confidential execution layer. The workspace can still track:

recipient readiness;
run status;
who submitted a run for review;
who approved the run;
execution state;
blocked or retryable items;
reconciliation state;
audit activity.

This is the difference between private and unaccountable. Decrow's position is that payroll should be private externally and accountable internally. The public explorer should not be the source of truth for compensation, but the company still needs a clean operational record.

Why viewing keys and compliance matter

Good privacy infrastructure needs a path for authorized visibility. Cloak's documentation covers viewing keys and compliance flows. Users derive viewing material client-side, transactions include encrypted chain notes, and history scanning can reconstruct transaction history from on-chain data using the viewing key. The docs also note that SDK transaction flows enforce viewing-key registration by default and that clients should never log raw viewing keys or decrypted note payloads (Cloak viewing keys and compliance).

That model is important for Decrow because payroll has legitimate review needs. Finance, admins, or authorized operators may need to understand what happened. The answer should not be "everything is public forever," but it also should not be "nobody can ever inspect anything." The right model is controlled visibility: the workspace keeps the operational record, and privacy infrastructure supports authorized history and compliance paths rather than public-by-default exposure.

This is why we talk about confidential execution, not disappearing money. Payroll still needs records. Payroll still needs review. Payroll still needs reconciliation. Privacy changes who gets to see sensitive data by default.

Security and reliability boundaries

Cloak's security documentation describes the trust boundaries between the on-chain program and the client SDK. The program verifies proofs, enforces nullifier uniqueness, validates roots, and applies transfer invariants. The client SDK derives keys, builds witness and proof inputs, and enforces registration paths by default (Cloak security).

For Decrow, these boundaries shape the product in practical ways.

First, Decrow treats privacy-sensitive material carefully. Raw UTXOs, private keys, viewing keys, seed material, and decrypted note payloads are not things that should appear in logs. Transaction signatures and short redacted public identifiers may be useful for support, but sensitive recovery material belongs in guarded flows, not general observability.

Second, Decrow treats on-chain confirmation as part of the payroll state machine. A run is not simply "done" because a UI button was clicked. Execution has to land, be confirmed, and be reconciled into the payroll record.

Third, recovery matters. Cloak's docs describe stale-root retries and recovery behavior in the runtime. Decrow wraps that kind of execution reality in payroll language: a recipient item can be executing, paid, blocked, retryable, or in need of manual review. The operator should not have to debug a protocol state just to understand whether payroll finished.

How this maps to Decrow's product flow

A Decrow payroll run starts before Cloak execution. That is intentional. Most payroll mistakes happen before money moves.

Recipients need payout details. A run needs amounts and labels. The team may need approval before treasury signing. The run may have readiness checks or missing details. These are product-level controls, not protocol-level controls.

Once the run is ready, the treasury signs. Decrow is non-custodial: the company's treasury wallet remains in control of funds. Decrow does not need to become the custodian to add payroll workflow. The product coordinates the run; the treasury signs execution.

Then Cloak-backed settlement handles the confidential Solana execution path. In Decrow's codebase, the Cloak integration lives behind a dedicated library surface and proxy path. The app maps payroll amounts into Cloak asset amounts, calculates withdrawal amounts, prepares executable recipient addresses, submits Cloak transactions through the SDK, and validates confirmed Cloak transactions before marking payout items as paid.

After execution, Decrow brings the result back into payroll state. A completed run is not just a signature. It is an operational record that answers:

which run was executed;
which recipients were included;
who approved the run;
whether the execution settled;
what failed or retried;
what remains available for audit.

That is the product value: Cloak makes private execution possible; Decrow makes private payroll operable.

Why we do not just use fresh wallets or manual splitting

Some teams try to solve payroll privacy with operational tricks: fresh wallets, multiple transfers, manual splitting, or spreadsheet-only reconciliation. Those patterns may reduce obvious visibility for a moment, but they do not create a reliable payroll system.

Fresh wallets still create trails. Manual splitting adds error risk. Spreadsheets do not enforce approvals. A group chat does not become an audit log. And every workaround becomes harder when the team has more recipients and the cycle repeats every month.

The better model is explicit: use privacy infrastructure for the settlement layer, and use payroll software for the payroll process.

What this means for teams paying in USDC

If your team already pays contributors or vendors in USDC, the question is not whether stablecoins can move money. They can. The question is whether the process around those transfers is ready for real operating volume.

A serious private payroll flow needs:

non-custodial treasury signing;
recipient readiness before execution;
approvals before funds move;
confidential settlement;
retries and recovery;
reconciliation;
audit history.

Decrow is built around that full workflow. Cloak is the confidential execution layer that lets Decrow keep payroll details private on Solana without turning the entire product into a raw protocol interface.

The bottom line

Stablecoin payroll has two separate problems. The first is settlement: how does money move quickly, globally, and cheaply? USDC on Solana addresses that. The second is operations: how does a team run payroll without exposing compensation, skipping approvals, losing history, or debugging failed payouts by hand?

That second problem is what Decrow exists to solve.

Cloak gives Decrow the privacy rail for confidential execution. Decrow wraps that rail in the product layer payroll teams need: recipients, approvals, treasury signing, retries, reconciliation, and audit history.

Private payroll is not just a private transfer. It is confidential settlement inside an accountable workflow.