Onscript
Automate smart, Automate onchain
About
The problem it 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. Smart Contract Address(es) 0xE364Df5A6197d16615631C60Daa63A6d42077eE3 Other Onchain Proof https://github.com/samuelkime267/onscript-contracts
How it's made
Challenges we 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).