Verification Checklist

  • ✓Do the proposal's "milestones" have verifiable objective standards (specific deliverables, queryable on-chain metrics) rather than vague phrases like "ongoing progress" or "made headway"
  • ✓Do the on-chain transfers' count, amounts, and timing intervals actually match the proposal's staged schedule, or were they paid out in full shortly after the vote passed
  • ✓Does the order of the vote-passage timestamp versus the first disbursement timestamp show funds moving while the proposal was still under discussion
  • ✓Does the grantee address's downstream fund flow stay with project-related addresses, or get moved to an exchange or split across many new wallets shortly after landing

1. "Milestone-based release" is a promise in the proposal, not an on-chain fact

Nearly every DAO grant proposal describes its disbursement method using some version of "funds released in stages tied to milestones" or "next tranche unlocks after completing the stage goal." The logic behind this design is straightforward: rather than paying the full grant amount up front and hoping the recipient delivers as promised, split the funds into tranches, each tied to a checkable stage goal, so the DAO retains the ability to pause future disbursements the moment a problem surfaces at any stage. That's a reasonable risk-control approach on its own — but it's worth clearly separating two things: the staged-release mechanism written into the proposal text is only a governance-level commitment and intent; whether it actually corresponds to a series of independent, paced transfers that really happen on-chain is not automatically the same thing. A proposal can be written with extreme rigor — three stages, acceptance criteria for each, a disbursement ratio for each — and still, at execution time, the treasury custodian or multisig holders retain the ability to transfer the full or majority amount to the grantee shortly after the vote passes. That action is fully observable on-chain, and fully worth verifying.

  • "Staged release" is a governance-level commitment in the proposal text, not the same as actual on-chain execution
  • A well-designed staged structure is meant to preserve the ability to pause future tranches at any stage
  • How rigorously a proposal is written and whether transfers actually stage on-chain are two separate things

2. Verify the milestone itself: an objective standard, or just a nice-sounding phrase

Before verifying whether disbursement followed the milestones, first verify what "milestone" actually means in the specific proposal. One kind is objective and verifiable: a testnet contract address deployed and audited, a feature live on mainnet with a corresponding transaction queryable on a block explorer, an on-chain metric reaching a specific value. What these standards share is that any third party can independently confirm them without relying on the grantee's own account. The other kind is vague and subjective: phrases like "the project is progressing steadily," "meaningful progress has been made," or "the team continues to invest in R&D." The problem with this language is that it can't be independently verified by a third party — whether the milestone was "achieved" ultimately comes down entirely to the subjective judgment of the fund custodian or proposal sponsor, and that judgment process itself is often opaque. When verifying a grant proposal, researchers should prioritize checking the specific definition of each milestone — and if a milestone's definition gets quietly softened or changed after the proposal passes (say, from "contract has completed an audit" to "contract code has been submitted"), that alone is a signal worth flagging.

  • Objective milestones: specific deliverables or queryable on-chain metrics a third party can independently confirm
  • Vague milestones: subjective descriptions relying on the grantee's own account, with no third-party verification path
  • Warning sign: a milestone's definition gets quietly softened or altered after the proposal passes

3. Verify the on-chain transfer cadence: how many payments, how far apart

Once the milestone definitions are confirmed to be clear enough, the next step is to check the actual transfer records the grantee address received, directly on a block explorer. The concrete method: find every transaction from the treasury or governance execution contract to that grantee address, log each one's amount and timestamp, and compare them one by one against the staged amounts and cadence promised in the proposal text. If the proposal specifies three tranches with at least a quarter between each, but the on-chain record shows all three transfers completed within two weeks, that tells you the staged release wasn't actually in effect at the execution level — regardless of whether anyone manually verified milestone completion in between, there was, at minimum by the time gap, no real window for "waiting on acceptance results." Another pattern worth flagging is a mismatch between the number of transfers and the number of stages in the proposal: three stages promised, but only a single transfer for the full amount on-chain — meaning the actual execution has already diverged from the mechanism the proposal text committed to, regardless of any explanation offered afterward.

  • Check the amount and timestamp of every transfer the grantee address received, comparing one by one against the proposed cadence
  • Too-short intervals between tranches mean there was no real window for waiting on acceptance results
  • A mismatch between transfer count and proposed stage count means execution has already diverged from the proposal text

4. Timing verification: was the money already moving before the vote passed

A more concerning anomaly than transfer cadence is when the governance proposal's vote-passage timing and the actual disbursement transaction's timing are inverted. Normally, the causal chain for a grant disbursement should be: the proposal passes in a governance forum or on-chain vote, and only then does the treasury executor initiate a transfer based on that outcome. The verification method is to directly compare two timestamps: the proposal's execution time as recorded by the on-chain voting contract (or the voting deadline), against the time the grantee address received its first payment. If the first transfer's timestamp predates the vote-passage time — or even predates when the proposal was formally published for discussion — that indicates the actual movement of funds may not have waited on the governance process's outcome at all, and the vote itself functions more like a rubber stamp after the fact than a real gate determining whether funds get released. This kind of timing inversion is objectively recorded on-chain and can't be argued away after the fact, making it a key entry point for verifying whether a grant proposal's governance process is what it claims to be.

  • Normal causal chain: proposal vote passes first, treasury transfer executes after
  • Verification method: directly compare the vote-execution timestamp against the first-transfer timestamp
  • A transfer predating vote passage suggests the governance process may just be a rubber stamp after the fact

5. After the money lands: tracking the grantee address's downstream flow

Verifying whether a disbursement is legitimate shouldn't stop at confirming funds reached the grantee address on the right schedule and in the right order — it should continue by observing where the funds go afterward. A reasonably healthy pattern is funds flowing gradually and in a dispersed way toward expenses actually tied to running the project: multiple small transfers paying developer salaries, transactions purchasing on-chain services or infrastructure. Patterns worth flagging include: the full amount getting moved to a centralized exchange deposit address shortly after landing (say, within 24 hours) — a pattern that's hard to square with the stated purpose of funding long-term project development — or funds getting rapidly split across multiple new addresses with no prior history and no obvious connection to each other, a splitting pattern that on-chain analysis typically treats as a signal of attempted tracking evasion. A single transfer to an exchange isn't necessarily equivalent to misuse, of course, but if it becomes a grantee's consistent pattern after receiving funds, it's worth factoring into how the next disbursement request gets reviewed.

  • A reasonably healthy pattern: funds flow gradually and dispersedly toward real project-operations spending
  • A pattern worth flagging: the full amount moved to an exchange deposit address shortly after landing
  • Another pattern worth flagging: funds rapidly split across multiple unconnected new addresses

6. Common misconceptions and methodology boundaries

Two common misconceptions are worth flagging. First, seeing "released in stages tied to milestones" in a proposal's text and assuming that mechanism will definitely be enforced strictly, without checking whether the on-chain transfer record actually happened in stages and at the proposed cadence — how rigorously a proposal is written and how rigorously it's actually executed are two things that need separate verification. Second, treating confirmation that funds "arrived" at the grantee address as the endpoint of verification, without continuing to track where the funds go afterward — overlooking that a grant is a complete journey from governance vote, to on-chain transfer, to eventual use, and any link in that chain can show an anomaly worth flagging. A methodology note: this piece discusses only the abstract verification methods around DAO grant disbursement mechanisms — it does not name any real DAO, grant program, applicant, or individual. Time intervals and ratios cited are illustrative examples only, do not constitute an accusation against any specific grant, and are not investment advice.

  • Misconception 1: assuming a proposal's staged-release commitment will be enforced strictly without checking the on-chain record
  • Misconception 2: verifying only that funds arrived, without tracking where they went afterward
  • Methodology boundary: abstract verification methods only, no real entities named, not an accusation or investment advice