When communities want to build together, they need more than chat rooms and likes. They need tools for trustless collaboration — systems that can reward creative input, recognize talent, and document contributions onchain.
This is exactly what Zero Authority Bounties were designed to do.
In this post, we’ll walk through:
The vision behind onchain bounties
A real-world case from Arkadiko Finance
The smart contract architecture
How developers can build with it today
Why Bounties?
We saw a need across decentralized communities:
“Communities and creators needed a way to run giveaways, host design challenges, and showcase reputation — without relying on off-chain promises or intermediaries. They wanted ownership over their contributions, meaningful participation, and real rewards for open, verifiable collaboration.”
Traditional tools like Google Forms or Discord DMs aren’t trustless or scalable. DAO contributors need a better primitive:
✅ Transparent
✅ Fair
✅ Onchain
✅ Verifiable
Enter: Bounties on Zero Authority
Arkadiko’s Mascot: A Case Study
The new ArkadikoFinance mascot began as a bounty posted to the Zero Authority platform. The process was:
✨ Open to everyone — anyone could submit a design
🧾 Transparent — submissions were timestamped and verified onchain
🧑🎨 Merit-based — winner earned funds and reputation, not just likes
🔐 Trustless — token payout was automated, with no centralized decision-making required
🌐 View the bounty
📦 Onchain TX Proof
This isn’t just art. It’s a new model for onchain creative coordination.
Smart Contract Overview
Let’s break down how this works on the smart contract level (built in Clarity on Stacks):
✅ SIP-010 Token Support
We use a trait for fungible tokens:
(use-trait token '...sip-010-trait...)
This ensures all bounties are funded with compliant, transferable tokens.
🔁 Bounty Lifecycle
Each bounty moves through a few key states:
(define-constant BOUNTY_OPEN u1)
(define-constant BOUNTY_PAUSED u2)
(define-constant BOUNTY_WINNER_SELECTED u3)
(define-constant BOUNTY_CANCELLED u4)
These states control who can interact with the bounty and what actions are allowed.
💸 Creating a Bounty
(define-public (create-bounty ...))
Creator deposits tokens into the contract
Metadata like title and ID is stored onchain
Validation checks:
UUID must be 36 chars
Token must be whitelisted
Token transfer must succeed
🧾 Submitting an Entry
(define-public (submit-entry bounty-id))
Each wallet can only submit once
Bounty must be open
Stores the
burn-block-height
for timestamping
This ensures submissions are recorded transparently and can be verified later.
🏆 Selecting a Winner
(define-public (accept-submission bounty-id submitter token))
Only the bounty creator can select a winner
Funds are transferred automatically
Winner is recorded onchain
Safety checks:
Bounty must be open or paused
Token used must match
Must be a valid submission
🛑 Pause or Resume
(open-close-bounty bounty-id)
Let creators temporarily pause a bounty, then reopen it later.
🔄 Redeem If Cancelled
(redeem-fund bounty-id token)
If a bounty ends with no winner, the creator can withdraw the funds.
🔍 Read-Only Access
These functions help frontends and indexers fetch bounty data:
(get-submission bounty-id submitter)
(get-bounty-details bounty-id)
No hidden data. Everything is visible onchain.
🧪 Code Snippets
Here’s a few critical enforcement rules that protect the system:
(ERR_ALREADY_SUBMITED) ;; Prevents duplicate entries
(ERR_UNAUTHORIZED) ;; Only creators can select winners or redeem
(ERR_WRONG_TOKEN) ;; Ensures token consistency
(ERR_NO_SUBMISSIONS) ;; Requires at least one submission before selecting a winner
🧬 The Future Is Onchain
By turning bounties into smart contracts, we unlock verifiable collaboration.
No spreadsheets. No backroom decisions. Just open, auditable, reward-driven participation.
🛠 Explore live bounties or launch your own:
👉 zeroauthoritydao.com/bounties
👁 View the contract on-chain and start building.
This is just the beginning of what onchain coordination looks like.