FAQ
Frequently asked questions about IronQ
Can the queue admin steal funds from the vault?
No. The vault's token authority is its own PDA (["vault", queue]), not the admin's wallet. No instruction allows the admin to transfer tokens out of the vault except through the defined lifecycle (approve, cancel, reclaim_expired, resolve_dispute). The admin can pause the queue but cannot drain it.
What happens if a worker claims a job and disappears?
After job_timeout seconds, anyone can call reclaim_expired to slash the worker's stake and return the reward to the creator (or re-open the job if retries remain). The cranker who calls this earns a percentage of the slashed amount.
Can a malicious creator always dispute and steal work?
No. Disputes are resolved by the arbiter (a neutral third party, ideally a multisig), not the creator. The creator can flag a dispute, but only the arbiter decides the outcome.
Why not use Clockwork or similar automation for expiry?
IronQ uses permissionless cranking instead of automation services to minimize external dependencies. Any wallet can call reclaim_expired and earn the crank reward, making cleanup self-sustaining without relying on a third-party service.
How does IronQ handle concurrent claims?
Solana's runtime enforces single-writer semantics per account. When two workers try to claim the same job in the same slot, only one transaction succeeds — the other fails because the job's status has already changed. No mutex or lock is needed.
What if the arbiter is malicious?
The arbiter is a trust assumption in v1. To mitigate this, use a multisig (e.g., Squads Protocol) as the arbiter. Future versions could implement a jury/DAO mechanism for fully trustless dispute resolution.
Can I run multiple queues?
Yes. Each queue is derived from ["queue", authority], so one wallet creates one queue. Use different wallets for multiple queues. Each has independent configuration, vault, workers, and jobs.
What IronQ does NOT do
- Execute jobs — IronQ is a coordination layer. Workers execute off-chain and submit proof.
- Verify results — The creator (or arbiter) verifies. Future versions could add on-chain verification.
- Priority scheduling — Priority is metadata only. Workers choose which jobs to claim.
- Guarantee availability — If no workers are registered, jobs sit until someone claims them.
When to use IronQ vs traditional queues?
Use IronQ when:
- Workers are untrusted third parties
- Tasks require escrow (pay on completion)
- You need a public, auditable record
- Dispute resolution is needed
- Tasks take minutes/hours to complete
Use Celery/SQS/BullMQ when:
- Sub-millisecond latency is required
- Tasks are internal microservice communication
- High throughput (>1000 tasks/sec per queue)
- Task data must be completely private
- Cost per task must be near-zero