Built By DAO
Engineering the Built By DAO Dashboard
The engineering behind reviewed work, scoped permissions, transaction states and credit whose source determines what it can do.
An Application With Several Kinds of Completion
The dashboard uses React, Express and PostgreSQL to coordinate member work, credit, governance and treasury. Its engineering has to preserve the steps between a person’s request and an authorized, confirmed result.
A reviewer can accept work before credit is confirmed. A vote can pass before its action is executed. Those intermediate states affect what a member should understand and what the application can treat as complete.
The dashboard is live. The v2 contract integration remains prepared rather than deployed in production. The integration model below describes the rules and states those actions require.
Dashboard Previews
Task Details
Task scope, deliverables and review states in the dashboard preview.View Full Preview
Dashboard
The desktop dashboard preview with sample data.View Full PreviewReview Acceptance and Confirmed Settlement
Review establishes that the work and its evidence meet the task’s expectations. Issuing contribution credit also requires an authorized funded project release, good standing and confirmed execution. The accepted result and the credit outcome therefore need to remain identifiable separately.
The platform integration requires idempotent indexing of work settlement. Processing the same confirmed event again must not count the settlement twice. That requirement matters when an application reads an event more than once: repeating the read must not create another contribution in the indexed history.
Authorization Includes Role and Resource Scope
A membership credential supplies identity, rank and standing. It does not by itself authorize every protected action. The relevant contract role and the dashboard’s narrower resource authorization must both allow the action.
For a credential change such as promotion, the member being changed, organizational scope and authorized role all matter. The transaction experience also carries the connected address and network. Keeping that context beside the action explains what is being changed and under which authority.
Transaction Progress and Read-State Accuracy
The transaction model separates intent, authorization, submission and confirmation. Failure and replacement also need explicit states. A member should be able to understand where the action stands instead of interpreting every submitted request as finished.
Read-only data has a status too. Stale or unavailable data is not a confirmed zero balance or empty history. Missing dependencies produce pending or unavailable states instead of simulated results.
Intent
The action and its consequences are presented with address, network, role and resource scope.
Wallet Authorization
The transaction can be prepared while still awaiting the member’s wallet confirmation.
Broadcast
Submission is visible before the transaction has been confirmed.
Confirmation
The confirmed result establishes the outcome, with explorer evidence when available.
Failure or Replacement
The action has an explicit outcome when it fails or is replaced, rather than appearing complete.
Credit Source Matters to Governance
Contribution EQTBLT records eligible, reviewed work. It is earned, cannot be bought, sold or transferred, has no member cash-out and is not pay, legal equity or a direct property share. The integration identifies work settlement as WORK. Housing credit carries RENT provenance, tied to qualifying rent and its lease-term rate.
That source affects governance: rent-derived credit does not enter Contributor power. Governance previews must follow the same category, eligibility, voting and execution rules as the contracts. Displaying a combined balance would not make every part of it eligible for the same action.
Treasury views likewise need balances, allocations, policy limits and required roles. The product has to retain enough context to explain both the value displayed and the action permitted. These rules make the member’s task, review and confirmed outcome understandable across the application.