Batch private disbursement
Confidential multi-recipient payments for payroll, contractors, marketplaces, and other disbursement programmes.
Roadmap: this capability is not currently available as a shipped product or public API. This page describes the intended product direction, not an implementation commitment.
Who this is for
- Employers and payroll platforms
- Marketplaces paying sellers or service providers
- Platforms paying contractors or affiliates
- Treasury teams coordinating recurring multi-recipient payments
The problem
Public batch payments can expose an organisation's entire disbursement graph. Depending on the programme, observers may infer:
- Recipient addresses and relationships
- Individual payment amounts
- Total programme expenditure
- Payment cycles and operational cadence
- Changes in workforce, supplier, or marketplace activity
Sending transactions from additional addresses does not create a dependable privacy boundary and increases operational complexity.
Intended direction
The proposed model extends Tenebrae private settlement from bilateral payments to organisation-initiated multi-recipient disbursement.
The intended flow is:
- The organisation funds settlement. A designated wallet deposits supported assets into Tenebrae Protocol.
- The organisation prepares a batch. The product validates recipients, amounts, available balance, and organisational policy.
- The Protocol creates private recipient value. Each recipient receives independently controlled private assets.
- Recipients discover their payments. Recipients use the supported client or integration flow.
- Recipients withdraw independently. Each recipient chooses when and where to return value to public rails.
The final design, transaction model, API, limits, recovery behaviour, and commercial availability remain subject to product, security, legal, and partner validation.
Potential applications
Payroll and contractor payments
An employer or payroll platform funds a disbursement cycle and creates private value for multiple workers or contractors.
Marketplace payouts
A marketplace settles with sellers or service providers without publishing a complete recipient and revenue graph.
Treasury distributions
An organisation distributes funds to subsidiaries, project wallets, grant recipients, or operating teams while reducing public disclosure of the allocation graph.
Design principles
Any production implementation should preserve the following properties:
- Recipient control: each recipient controls their own private asset and withdrawal.
- No silent capture: funding and disbursement require explicit authorised actions.
- Clear public boundaries: deposits and recipient withdrawals remain public.
- Policy enforcement: the organisation retains upstream recipient approval, screening, and payment controls.
- Failure isolation: one invalid recipient should not create ambiguous partial completion.
- Auditability: the organisation needs an appropriate private record of approvals, amounts, status, and reconciliation.
- Recovery: the design must account for expired or incorrect recipient material, lost access, and unclaimed payments.
Privacy boundaries
The intended privacy goal is to avoid publishing the recipient list and individual payment amounts as plaintext Protocol inputs. It would not make all programme information private.
| Information | Expected visibility |
|---|---|
| Organisation funding transaction | Public |
| Batch transaction sender and timing | Public or inferable |
| Recipient list and individual amounts | Intended to remain private at the Protocol data layer |
| Recipient withdrawals | Public |
| Employer, payroll, or marketplace records | Controlled by the originating organisation |
| Wallet, RPC, device, and application metadata | Outside the Protocol privacy boundary |
The final privacy properties must be reviewed against the implemented protocol before any production claim is made.
What must be resolved before launch
- Batch size, transaction limits, and proving performance
- Recipient discovery and invitation flows
- Partial failure and retry semantics
- Cancellation, expiry, and recovery
- Reconciliation and private audit records
- Fees and gas sponsorship
- Supported assets and networks
- SDK and API design
- Operational monitoring and support
- Security review and production deployment
- Jurisdiction-specific payroll, marketplace, and money-movement responsibilities
What is available today
Tenebrae currently supports evaluation of bilateral private transfers on supported testnets. Organisations interested in multi-recipient disbursement should treat the current product as a design-partner and workflow-validation surface, not as a batch payment API.