How Taskify works

Taskify is a bounty board built on Mezo. Owners post tasks and lock MUSD (or MEZO) in escrow, contributors apply and get paid on approval, and Patrons fund a shared grant pool and vote on which grant-funded tasks get built.

Every step that matters — escrow, experience gating, payout, voting weight — is enforced automatically by Taskify itself, not by a central party. Nobody, including the Taskify team, can move escrowed funds outside the paths the system allows.

There are two ways to sign in, and both end up as an ordinary Mezo wallet address:

• Email or Google— a wallet is created for you automatically (by Privy, the sign-in provider), so you need no extension or seed phrase. It's the easiest way to start; for larger balances, send your earnings to a wallet whose keys you control.
• An existing wallet — MetaMask, Rabby and other browser wallets, or any WalletConnect mobile wallet.

One identity, one account. Each Google or email identity can be linked to a single Taskify wallet. Gmail addresses are compared ignoring capitals, dots and plus-tags, so a.b+x@gmail.com and ab@gmail.com are the same identity. If you sign in with an identity that already belongs to another wallet, Taskify blocks the sign-in and points you to that wallet instead of opening a second account.

Email and Google sign-ins register with the identity they verified, with no separate Google step. Wallet sign-ins still connect a Google account when they register. New contributor wallets verified through Google also get a one-time BTC top-up so their first actions work. Email-only sign-ins can claim it too by linking a Google account on the registration page. See the FAQ for common questions.

Every task is one of two kinds, chosen at creation and fixed for its lifetime:

• Development — a single contributor applies, the Owner picks one assignee from the applicants, and the full escrow (minus fee) releases to them when their submission is approved. Gated by an experience-tier range the Owner sets.
• Community — open to any registered wallet, no experience gate. Anyone joins with a proof-of-participation link (a post, a write-up, a PR — whatever the task asks for). The Owner reviews submissions and picks winners, up to the limit set when the task was posted; the escrow splits evenly between them in one transaction.

Development tasks can be funded one of two ways:

• Self-funded — the Owner deposits the full bounty themselves at creation. 3% platform fee.
• Grant-funded — the Owner proposes the task with no upfront deposit. If patrons approve it by vote (see below), MUSD is drawn from the shared grant pool automatically. 5% platform fee.

Community tasks are always self-funded (3%) — grant-funded Community tasks aren't supported yet.

Every fee splits the same way: 60% to the Taskify treasury, 40% into the current wave pool.

A task moves through a fixed set of statuses. The exact path depends on how it's funded and what kind it is:

Development, self-funded:
Open → Assigned → In Progress → Submitted → Payment Released
(Open can also go to Cancelled or Expired; Submitted can go back to Open via a rejected submission.)

Development, grant-funded:
Grant Pending → (vote) → Open → Assigned → In Progress → Submitted → Payment Released
(Grant Pending resolves to either Open, on approval, or Grant Rejected.)

Community:
Open → Payment Released (winners are selected and paid in one step)
(Open can also go to Cancelled or Expired before any winners are picked.)

A creator can cancela self-funded task before it's assigned, refunded minus the fee. Anyone can mark a task expiredonce it's past its deadline and hasn't reached Submitted — this never touches work that's already been delivered or a grant proposal that was never funded.

Contributors declare a tier at registration (self-attested, changeable once a day). Development tasks set a minimum and maximum tier at creation — Taskify checks the match automatically the moment a contributor applies, not just in the interface.

Community tasks skip the experience gate entirely — anyone registered can join.

Taskify doesn't custody anything for governance. Voting weight is read live from your veBTC position on Mezo Earn — lock BTC there to mint veBTC, and pair it with a veMEZO lock via Mezo's Matching Market to boost weight up to 5x. It's completely decoupled from MUSD deposits: depositing into the pool funds grants and earns Patron tiers, but grants no votes on its own.

Each grant proposal opens a 3-day voting window and fixes a snapshot — both the timestamp and which veBTC source Taskify reads from — the moment it opens. Locking veBTC after a vote has started doesn't let you swing it, and the snapshot can't be affected by a later change to that source.

A proposal passes at 70% support of cast weight. Grant voting is currently in an invite-only pilot: holding real veBTC weight is necessary but not sufficient — only wallets the project owner has explicitly approved can cast a vote. Reach out via @taskifyhq if you hold veBTC and want to be considered.

Any registered wallet can deposit MUSD into the shared grant pool (minimum 50 MUSD), independent of role or voting status. Cumulative deposits unlock a tier:

Separately, every self-funded task's fee sends 40% into a rolling wavepool. Every 30 days, the wave closes and that pool splits among the wave's self-funded creators, proportional to how many tasks each one posted — a small ongoing incentive for creators who keep the board active. Grant-funded tasks contribute fees to the wave pool too, but don't count toward any creator's share.

Taskify's contract is upgradeable, so it matters a great deal who is allowed to upgrade it. Nobody holds that power alone. Ownership of the deployed contract sits with a 2-of-3 Safe multisig on safe.mezo.org — at least two of three independent signers must approve before any administrative change takes effect.

One of those three signers is a member of the Mezo g6 community, outside the Taskify team. That means the team cannot reach the threshold on its own: no upgrade, no treasury change and no voter approval can happen without someone independent signing it too.

The Safe itself is 0xcfeC02DfC63FcA293b5F9c2856bb1370965D2a31. You don't have to take any of this on trust: read getOwners() and getThreshold() on that address, then read CONTRACT_OWNER() and treasuryAddress() on the Taskify contract (0x02548E2071b2Fc6Cc2f34E7a8eFD88e0Fd792A8D), and confirm all three match.

What the multisig can and cannot do

To be clear about the tradeoffs, here is the full extent of the privileged powers:

• Upgrade the contract (upgradeToAndCall) — this is the significant one. A UUPS upgrade can change any of the rules described on this page, including the rules that govern escrowed funds. It is what lets security fixes ship quickly, and it is also the power you are trusting the signers with.
• Change the treasury address (setTreasuryAddress) — where the protocol's fee share is sent.
• Set the veBTC / veMEZO escrow sources (setVeBTCEscrow, setVeMEZOEscrow) — which Mezo contracts voting weight is read from.
• Approve pilot voters (setApprovedVoters) — the invite-only grant-voting allowlist.
• Hand over ownership (transferOwnership, then acceptOwnership by the new owner) — a two-step transfer, so ownership can never be sent to an address that can't claim it.

And what it cannot do, by construction:

• It cannot withdraw, move or release escrowed task funds. There is no function that lets any owner touch a task's escrow — release happens only through the normal lifecycle (creator approval, cancellation or expiry).
• It cannot spend the grant pool outside an executed, community-approved grant.
• It cannot change the outcome of a vote, or vote on your behalf.
• It cannot redirect the payment tokens — the MUSD and MEZO addresses are immutable and fixed at deployment.
• It cannot stall wave rewards — advanceWave is permissionless by design, so anyone can close a wave if the signers go quiet.

Honest limitations

Two of the three signers are Taskify team members, so this is a meaningful reduction in centralisation rather than its elimination. There is also currently no timelock: once two signers approve an upgrade, it takes effect immediately, with no enforced delay in which users could exit first. Adding a timelock on upgrades is on the roadmap. Until it ships, please size your exposure with that in mind — and see the Terms for the formal statement of this risk.

The contract has been through three security reviews. Every finding raised across all three has been resolved. Start with the caveat, though, because it matters more than the rest of this section: none of these was a professional third-party audit. Two were internal reviews by the team, one was an external automated scan. A paid audit by an independent firm is planned before the contract holds larger sums, and until it happens you should size your exposure accordingly.

The September 2026 review in detail

This is the round worth reading, because it is the one that produced the multisig described above. It deliberately targeted what the earlier rounds could not have covered: the contract had become upgradeable, and it had gone live on mainnet holding real funds. Reviewed at main @ e13205d; findings were confirmed by execution rather than by reading alone (45 Foundry tests passing; 5 purpose-written proof-of-concept tests executed).

Note that the first of those was never a flaw in the code — the upgrade gate was implemented correctly. It was an operational problem with who held the key, and it was closed by an on-chain transaction rather than a code change. The remaining three were latent: none was exploitable by an outside attacker, and each would have bitten during a future upgrade or ownership change. All three are now fixed in the deployed implementation.

Also tested and found sound

Knowing what was checked and held is part of the result, so these are recorded too:

• Wave reward over-payment — tested and disproved
• Escrow commingling between tasks and the wave pool — tested and disproved
• Upgrade initialisation front-running — blocked, covered by tests
• State continuity across an upgrade — confirmed intact
• Token approval scoping — no admin function can touch a third party's allowance

What is still outstanding

• No professional third-party audit yet. The most important gap, and the reason to treat everything above as necessary but not sufficient.
• No timelock on upgrades. Recommended by the September review and still open — see Governance & contract control.

One recommendation from that review has since been completed beyond what it asked for: it suggested moving the 2-of-2 Safe to 2-of-3 for key-loss redundancy, which has been done, with the third signer drawn from the Mezo community rather than the team. The full write-ups for the first two rounds live in TASKIFY_SECURITY_AUDIT.md in the repository.

The Wallet page (linked from your dashboard) shows your MUSD, MEZO and BTC balances and lets you send MUSD or MEZO to any other address. It works from every kind of wallet, including one created by an email or Google sign-in.

• Send— choose the token, enter a recipient and amount (or Max), review, and confirm in your wallet. The review step shows the full address in groups of four characters so you can check it. The transfer is a standard token transfer signed by you; it doesn't pass through Taskify.
• Protections — the form rejects invalid or bad-checksum addresses, your own address, the zero address, and the MUSD, MEZO, BTC and Taskify contracts, where funds would be lost. Other smart-contract recipients need an explicit acknowledgement.
• Fees — Taskify charges nothing. The network fee is paid in BTC and is a small fraction of a cent, so the sending wallet needs a little BTC.
• History — transfers in and out, with task payouts and refunds labelled, each linking to the Mezo explorer.

Transfers are final: Taskify can't reverse or recover one, so send a small test amount to a new address first.

Funds move only through Taskify itself: MUSD or MEZO locks in at task creation and only leaves escrow when the Owner approves submitted work, a task is cancelled before assignment, or a task expires past its deadline. There's no intermediary holding funds at any point, and Taskify only ever requests an approval for the exact amount about to be escrowed — never unlimited.

For wallet setup and phishing-safety guidance, and how sending works, see the Wallet safety section of the FAQ.