lucentFinancier
Defines and funds the budget.
THE PROTOCOL · PROPOSED DESIGN
Clear conditions.
Visible commitments.
Lucent reserves a project budget and releases each payment after an agreed delivery is approved.
This is an interactive product prototype. No contracts have been deployed, no security audit is claimed, and no real money can be deposited here.
Three roles. One agreement.
Project team / recipient
Submits the work and receives approved payments.
Independent approver
Evaluates each delivery against the agreement.
How the workflow works
Each vault has a named recipient and a different approver, a fixed set of milestones, amounts and deadlines. This workspace uses USDG-denominated simulated units.
The entire budget must be reserved before a delivery can be submitted. Submission places a milestone in review. The approver may approve it or request revision. Only an approved milestone can be released, and a released milestone cannot be paid twice.
Role switching lets you try both sides of this process. It is not authentication and does not represent the permissions of a deployed contract.
What still needs a decision
Refunds & expiry
Who may recover unspent funding, under which conditions, and after what waiting period? Deadlines are informational in this workspace.
Disagreement
How can a team challenge a rejection? Who arbitrates, and what happens to reserved funds during a dispute?
Inactive reviewers
What happens when the approver disappears? Replacement permissions and time limits are not finalized.
Relationship with pons
Lucent is an independent concept intended to help projects organize milestone funding. The first proposed version uses direct deposits. Receiving launch fees from pons is a future integration that needs contract-level validation.
No partnership or endorsement is implied. A role for a Lucent token has not been defined, and no token is required to explore this workspace.
Read the pons v2 documentation ↗Transparency has a limit.
A contract can enforce payment rules.
It cannot decide whether a delivery is good.
Approver selection, clear acceptance criteria and tested dispute rules are essential before this design handles real funds.
Explore the workflow ↗