Conductor

• 

  Home

Inspiration

Let's be blunt: for a chain built for serious finance, the operational tooling on Algorand is very... DIY. We saw good projects - legitimate, revenue-generating businesses, wasting engineer-hours on brittle Python scripts and manual CSV exports just to handle routine payouts. Founders take on massive operational risk for a task that should be trivial.

This isn't a problem you solve with a persona. It's a systemic friction point. The gap between Algorand's powerful L1 capabilities and the clumsy, high-risk operational reality for the businesses building on it is massive. Conductor was built to fill that gap. We weren't inspired to "delight users"; we were inspired to eliminate a pattern of professional inefficiency that's holding the ecosystem back.

What it does

Conductor fixes the broken, high-risk process of mass payouts. It’s a sharp, focused tool that does one job exceptionally well.

Before Conductor:

• Manual export (🤮) of holder lists from an indexer.
• Tedious spreadsheet calculations, prone to human error.
• Executing a custom script, praying it doesn't fail mid-way.
• Zero verifiable, on-chain audit trail of the payout's intent.

After Conductor:

• Define the Rule: You create a simple, human-readable rule (Pay X to holders of Y) which is anchored on-chain as an immutable record.
• Simulate the Run: You see an exact preview of the execution (total cost, recipient count) before moving a single cent. This is our trust mechanism.
• Execute: One click triggers the entire batched execution. Conductor handles all the complexity of transaction grouping behind the scenes. The result is a clear, auditable history.

How we built it

Our architecture is a direct reflection of our philosophy: security through simplicity, and flexibility through abstraction.

The Vault: A Minimalist Smart Contract. Our on-chain footprint is intentionally tiny. The TEAL contract is a simple, non-upgradable vault. Its only logic is is_sender_creator(). Any complexity added to a smart contract exponentially increases its attack surface; for a treasury holding user funds, that’s an unacceptable trade. All the "heavy thinking" happens off-chain.

The Engine: Off-Chain & Opinionated. We used Bolt to build the core engine. A server-side Python function performs the real work: fetching holders from an indexer, calculating the payout, and intelligently batching transactions into atomic groups. This off-chain approach means we can update our logic, integrate new indexers, or add complex features without ever putting funds at risk through a contract upgrade.

The Bridge: Algorand Indexer API. We treat the indexer as our single source of truth for ownership. No internal databases to sync, no risk of stale data.

Challenges we ran into

The "Domino Problem." A single failed transaction in a multi-batch payout (e.g., one recipient's account is closed) can't be allowed to create chaos. Our first naive implementation would just stop, leaving the operator to manually figure out who was paid and who wasn't.

This was a nightmare scenario that defeated the entire purpose of the app.

The fix was to build idempotency and robust state tracking into the core execution job. The engine now treats a payout as a single mission. It logs the status of every single transaction group. If a group fails, it can be safely retried without risk of double-payment. The system is designed to complete its mission, even if it hits turbulence, and to provide the operator with a precise, actionable report if manual intervention is ever required.

Accomplishments that we're proud of

The 'Boring' Architecture. Our proudest accomplishment is a design that many would call boring. We actively resisted the temptation to build a "super-contract." Choosing to keep our smart contract dumb and our off-chain logic smart is a trade-off we'd make 100 times over for security and maintainability.

Nailing the Trust-to-Action Ratio. We realized the "Simulate" button isn't a feature; it's the entire product's trust mechanism. That pre-flight check is what gives an operator the confidence to perform the irreversible action of executing a payout. Getting that right was everything.

Making a Hard Constraint Invisible. Algorand's 16-transaction limit is a fundamental reality. We're proud of how cleanly we abstracted that away. To the user, a 300-person payout feels like a single operation, not 20.

What we learned

Building with an LLM-powered tool like Bolt taught us something fundamental about product development: Your product spec is only as good as your understanding of the user's emotional state.

Initially, our prompts were sterile: "Build a modal to confirm the transaction." The AI gave us exactly that: a sterile, functional modal.

The breakthrough came when we changed the prompt's intent: "Design a confirmation step that assumes the user is about to perform an irreversible action with $100,000 and is terrified of making a mistake." The resulting design was fundamentally better: clearer warnings, explicit numbers, and a much more deliberate flow. It proved that to build great tools with AI, you can't just specify features; you have to specify the feeling you want to create or eliminate.

What's next for Conductor

We started by solving one critical job-to-be-done. The roadmap is about moving up the value chain from a sharp tool to an indispensable operations platform.

Programmable Payouts: Moving beyond "per-holder" logic to support tiered rewards (e.g., based on loyalty NFTs), time-locked vesting schedules, and other complex distributions.

Automated Triggers: Integrating cron-like scheduling for true "set-it-and-forget-it" payroll and dividend runs.

DAO & Treasury Management: Expanding from simple payouts to a control panel for DAO treasuries, integrating grant distribution, contributor payments, and governance reward mechanisms.

Built With

• algorand
• bolt
• python