The problem Onscript solves

Onscript makes life a lot easier for creators because it helps you focus on what really matters — creating. Instead of worrying about timing, metrics, or losing track of ideas, you can use it to:

Onscript is built for creators, founders, and communities who want to work smarter, not harder.

Plan & Schedule → Draft ideas and schedule posts ahead of time, so you stay consistent without burning out.

Track Metrics → Know what works with onchain analytics, giving you clarity and safer decisions backed by data.

** Onspcase (Workspace Sharing)** → Seamlessly share and collaborate in workspaces that are easy to navigate and fully onchain — no clutter, no confusion.

**Automated DMs **→ Safely connect with your audience or community at scale without spamming or manual stress.

**Streaks **→ Stay motivated and accountable with streaks that reward you for showing up daily.

Basically, Onscript takes away the stress of managing content so you can pour your energy into creating — while still staying consistent and growing.

Challenges I ran into

Challenges we ran into (and how we overcame them)

Building Onscript uncovered gaps across integrations, messaging APIs, and gas/cost assumptions. We hit technical blockers (automated DMs, limited third-party APIs, incomplete prototypes), leaned on community help (DeFi DevRel), brought in a developer to finish the work, and solved the funding gap by adding a premium option that covers connection/gas fees and paid API features.

1) The main bugs / hurdles

• Automated DM limitation — we discovered the Neynar API cannot send DMs on a user’s behalf. It’s useful, but it doesn’t provide the one-click “send as me” automation we expected.

• No reliable external API — there wasn’t an obvious public API that lets us fully automate secure DMs for user accounts the way we wanted. We tried several approaches and hit dead ends.

• Prototype vs product gap — “vibe coding” with Ohara produced a working prototype, but it lacked critical real-world functionalities (retries, queueing, UX edge cases, error handling).

• Gas / cost assumptions — we assumed automation would be free to connect, but discovered that automating on-chain actions (or having relayers execute signed txs) can require gas or costs that someone must cover. That introduced a pricing question we hadn’t planned for.

2) Who helped / how we got unstuck

• Documentation — the public docs for Farcaster, XMTP, and other tools helped identify the intended flows and limitations. They saved a lot of time clarifying what’s possible vs. what’s not.
• DeFi DevRel community — the DevRel folks helped us brainstorm alternatives, suggested design patterns (timelocks, relayer models, meta-transactions), and pointed out security pitfalls. Their guidance was critical in choosing safe approaches.
• Ohara (vibe coding) — Ohara built a rapid prototype that proved the concept was feasible. It was a great MVP for demos, but it didn’t include production features like retries, rate limits, queueing, or proper error handling.
• Bringing in a developer: Wahala Dev — to move from prototype → production we hired/contracted a developer who implemented the missing functionality and hardened the system (queue worker, DB persistence, retries, DLQ, monitoring).

3) Specific technical issues we faced

• DM automation: Neynar doesn’t send DMs on behalf of a user. We needed an approach that respects privacy & signatures while still automating messages.
• No turnkey API: There isn’t a single, reliable API that performs the exact DM automation we wanted without either (a) requiring user-side signing for each message, or (b) requiring elevated privileges we don’t want to hold.
• Edge-case failures: prototypes failed silently on API rate limits and transient network issues — we had to build robust queuing + dead-letter handling.
• Gas & relayer model: automating on-chain interactions (scheduling posts that execute on-chain) implies a relayer or a user-pay gas model; we didn’t initially budget for relay gas.

4) How we overcame these problems

• Premium model to cover costs: to cover Neynar paid features and gas/relayer costs we:

  • Added a premium tier where users pay the connection/gas fee for automated on-chain posting and paid Neynar features.
  • Offered free limits for basic functionality and a paid upgrade for reliable, fully automated flows.

• Monitoring & observability: we added Sentry/winston logs and a queue+DLQ dashboard so failures are visible and actionable.

• Fallback behavior: when DM automation or posting fails, we queue and retry; if it still fails, we notify the user with a clear action (manual retry or refund/credit where applicable).

5) Money / API costs — the reality

• Neynar: some features require paid access. To unlock the Post Schedule experience we had to integrate paid Neynar endpoints — which increased our costs. And we also had to pay for some people's gas
• Farcaster / on-chain automation gas: automating posts that require on-chain txs can require gas payment (depending on the method: relayer, meta-tx, or direct user tx). There is no free lunch.
• Our product decision: we surface this cost to users as part of the premium/connection fee (transparent: you pay the gas/connection cost so we can perform your scheduled on-chain actions reliably).

6) Outcome & how it works now

• The scheduler works with a reliable retry/queue system and clear UX for queued / failed / posted states.
• Onspcase (workspace) and streaks are working with on-chain proof recording; campaign payouts use escrow logic and premium covers gas for automated relays.
• We have admin tooling to inspect the queue, replay failed jobs, and manually intervene (important for early-stage trust).

Smart Contract Address(es)

0xE364Df5A6197d16615631C60Daa63A6d42077eE3

Other Onchain Proof

https://github.com/samuelkime267/onscript-contracts