Concept

Pay by the second.
Show only the proof.

Placeholder only. This form does not send anything anywhere. Coming Soon.
// illustration · no real datapayer → recipients
VEIL PAYER ??? ??? ???
what it aims to do

Payroll that does not
publish the payroll.

Continuous streaming

Funds accrue to a recipient every second instead of in lump sums, so a contributor can be paid as work happens.

Shielded terms

The design goal is to keep the rate and the recipient set out of public view, so colleagues and competitors cannot read your payroll off the chain.

Payer stays in control

The payer can cancel or update a stream. The idea is that a settlement proof lets anyone verify the totals add up without seeing the terms.

how it works (design sketch)

A current with a curtain in it.

The intended mechanism, shown as an illustration. It describes a design we want to build, not something you can use today.

One stream, as an observer would see it

The bar below is a purely visual loop. It shows a stream filling over time. The numbers are deliberately hidden, and nothing here is real data.

accrued: recipient:

What a public record could show

The kind of fields the design aims to leave public. Placeholders, not real values.

stream exists<public>
rate per second
recipient
settlement proof<verifiable>
1

Fund

The payer escrows a budget into the stream program.

Funding tx visible
2

Veil the terms

Rate and recipient are committed, not written in the open.

Terms hidden
3

Accrue

Value accrues each second. The payer can pause, update or cancel.

Balance hidden
4

Claim & prove

The recipient claims with a proof. A settlement proof shows totals reconcile.

Proof public
privacy model

What is hidden. What is not.

Streamveil aims to reduce linkability between a payer and the people they pay. It does not provide anonymity, and it is not a way to avoid obligations such as tax or reporting.

Hidden by design goal

intended, unaudited, unbuilt
  • The amount streamed per second, and amounts accrued so far.
  • Which addresses are the recipients, and how many there are.
  • Which recipient a given claim belongs to (to the extent the design achieves it).

Stays public

on any Solana explorer
  • That a stream exists, and the payer's funding transactions.
  • A verifiable settlement proof that what was paid reconciles with what was funded.
  • Transaction times and fees. Timing patterns can still point back to people.
read this first

Known limitations — please read

  • Not built, not audited. Streamveil is an early idea. There is no deployed program, no audit and no working app. Do not use this page as a reason to move real funds.
  • Linkability, not anonymity. The aim is to make payment terms harder to read and link. It does not hide who you are. Funding transactions, fees, timing and off-chain context can still reveal a lot.
  • Claims can leak. When a recipient withdraws, the destination address and timing are visible. If funds are claimed to an address tied to a person, the link is back.
  • Small streams are easy to infer. If only a few streams exist, observers may guess who is paid by watching when funds move. A larger crowd would help, and none exists yet.
  • The payer holds power. Because the payer can cancel or update a stream, recipients rely on that design, and on correct code, for fair treatment.
  • Not a compliance tool. Employers and payers remain responsible for tax, payroll and reporting rules in their jurisdiction. Streamveil does not replace them.
  • Cryptography risk. Proof systems are subtle. A bug could expose terms or strand funds.