[Final Report] Sippy: WhatsApp Stablecoin Payments for Latin America

Sippy: WhatsApp Stablecoin Payments for Latin America

Update, August 17: Following DAO feedback, we clarified the definitions and evidence behind volume, activation, transaction reliability, uptime, NPS, M3 timing and the B2B2C direction. Unless stated otherwise, the figures below refer to the August 15 grant-close snapshot. The live dashboard continues to update.

1. Executive Summary

Project: Sippy
Questbook application: Approved proposal
Website: sippy.lat
Live metrics: sippy.lat/stats
X: @SippyLat
Technical documentation: docs.sippy.lat
Public grant workspace: Milestones, evidence, testimonials and live-event material

Sippy gives people a non-custodial smart wallet and lets them receive, hold and send USDC through a simple chat experience. During this $25,000 grant, we moved from a working prototype to a production product with fiat onramps, gas-sponsored transactions, security controls, monitoring, legal and technical documentation, and live community testing.

At grant close, Sippy had 291 registered users, 458 qualifying onchain transfers, $87.8K in gross throughput ($45.2K on-ramped and $42.0K sent onward), and 47% activation. The NPS result was +80 from 10 respondents, so we treat it as directional feedback rather than a representative product-wide score. The product was tested in Colombia and internationally, including 51 live demo transfers at ETHGlobal Lisbon, where Sippy was selected as one of four Spotlight teams.

The grant made this progress possible. It funded the engineering and legal work needed to operate a real product, helped us test it with people outside the crypto-native audience, and gave us the runway to learn what drives both activation and retention. Most importantly, we learned that receiving money is Sippy’s strongest use case. Recurring use is more likely when the payments themselves recur, and that insight is guiding our next phase.

2. Performance Against KPIs

Milestone 1: Production Ready

All ten planned M1 deliverables were shipped. The full evidence tracker is available in the public grant workspace.

KPI Projected Actual result Status
Fiat onramp Functional end to end COP onramp launched for Colombia, with Coinbase Onramp and later Mt Pelerin covering additional regions Met
Security hardening Features implemented and tested Transaction confirmation, self-send prevention, velocity and spending limits, privacy controls, passkey login and step-up confirmation shipped Met
Dual-currency display Live USD plus local-currency display and sends supported across 26 LATAM currencies Met
Legal entity Established SIPPY, S.A. DE C.V. incorporated on March 20, 2026 Met
Monitoring Active PostHog analytics and error tracking, health endpoint, Alchemy indexer, admin dashboard and Zoho support live Met
Closed beta 50 testers with successful transactions 55 users, 52 of whom transacted at M1 close Exceeded
Organic volume More than $10K USDC $20.8K USDC moved at M1 close Exceeded
Launch readiness Ready for public launch Production number, complete user flow, legal pages and monitoring launched Met

Milestone 2: Public Launch

KPI Projected Actual result at grant close Status
Onchain transactions 200 to 400 458 qualifying transfers, including 51 disclosed Lisbon demos. Excluding every demo leaves 407 transfers. Exceeded
USDC volume $50K to $100K $87.8K gross throughput: $45.2K on-ramped and $42.0K sent onward Met on the gross-throughput definition used in M2
Monthly active wallets 75 to 100 13 at close. The sequence was 13 on July 11, 24 after Lisbon on July 29, and 13 on August 15. Not met
Transaction success More than 98% 131 of 131 monitored sponsored sends landed. Across all 227 sponsored operations (131 sends, 74 wallet setups and 22 savings operations), 226 landed; one wallet setup expired. 99.6% in the monitored post-migration period
System uptime More than 99% No user-facing outage was recorded by health checks, PostHog or Zoho. An exact historical uptime percentage was not measured. Exact KPI not measured
Bug resolution Less than 48 hours One event-day wallet-setup issue was identified and resolved promptly, with no funds-safety impact. One case is not enough to establish a program-wide SLA. Limited evidence
NPS More than +40 +80 from 10 of 291 registered users: 8 promoters, 2 passives and no detractors Directional sample
Documentation Published Technical documentation, two blog posts, Terms, Privacy Policy and disclosures published Met
DAO report Delivered Living milestone report completed and this final report prepared for the DAO forum Met
Legal coverage of user flows 100% Terms, disclosures and consent at signup, plus fee, gas and irreversibility information before each send Met
Third-party integrations 100% contractually scoped and documented All active providers documented with role and agreement basis in the integration register Met

Measurement notes

  • Activation: 136 of 291 registered users had sent at least $1 to another wallet or completed an offramp. Receive-only activity, self-sends and sub-dollar transfers do not count. This measures first use, not return activity.
  • Reliability: Full outcome monitoring began with Pimlico-sponsored sends on June 25 and expanded to wallet setup on July 6. We can report a reliable rate for that post-migration period, but not for the earlier legacy flow. The Pizza Day gas issue affected wallet setup, not a transfer or user funds, and helped drive the migration from the legacy gas flow.
  • Retention: At close, 4 of the 16 wallets active in the previous 30-day period were active again, or 25%. We do not have a complete cohort-retention curve and are not presenting consumer retention as proven.
  • Sippy Quest Season 1: The usage leaderboard made genuine activity more visible, but it did not materially improve retention.

We exceeded the transaction goal and met the volume goal using the gross-throughput definition reported throughout M2. Gross throughput is not revenue, unique capital or send-only volume, so the table now shows both components. Recurring usage fell well short of the 75 to 100 monthly active wallets we targeted. Events produced strong first-use moments, but not a lasting payment habit on their own.

Milestone 3: Growth Tracking and Final Report

M3 had no additional KPI target. Its deliverables were a growth report with onchain-verifiable metrics, post-launch traction analysis and lessons learned. The report was due around September 5 and was submitted on August 17, after Lisbon became our final activation. The milestone payment was requested after submission, and no M3 deliverable remains incomplete.

Since the M2 snapshot, registered users grew from 231 to 291, gross throughput increased from $50.8K to $87.8K, and qualifying onchain transfers increased from 357 to 458. The live dashboard links individual transfers to Arbiscan, and the M3 section contains the final snapshot and Lisbon coverage. Submitting early gave us a shorter observation period after Lisbon, but the dashboard and measurement will continue as part of the product.

3. Qualitative Impact and Community Feedback

The most significant non-quantitative result was seeing people use a blockchain product without first having to learn blockchain concepts. At the Cartagena launch, Pizza Day, the TechX ColCaribe session at Universidad del Norte and ETHGlobal Lisbon, new users could open a wallet, receive USDC and send it through chat without handling gas, seed phrases or wallet addresses.

Three pieces of feedback capture the experience:

“My grandparents understood digital dollars so easily. I send them money every now and then, and they are building an alternative savings through Sippy.”
Bettina

“It felt so good to receive my freelance payment directly as a WhatsApp text.”
Hernan

“When we helped the pizzeria receive its money after the event, they could not believe how simple and cool it is to have their money available.”
Juan David

We also saw a clear pattern: people enjoyed receiving money, but many moved it to an exchange when they needed local currency. Sippy has an offramp, but its current UX is still too complicated for our standard of simplicity. The recipient experience performed well during live activations; the next step is to test whether organizations making recurring payouts can create a reason to use it repeatedly.

Social and event evidence

4. Financial Summary

The grant totals $25,000. At the time of this report, the M1 and M2 allocations have been spent. The M3 deliverables were submitted on August 17, and its allocation supports continued product operations, measurement and reporting after grant close:

Grant stage Amount Share of grant Status and use
Milestone 1: Production Ready $12,000 48% Spent on product and engineering, legal setup, infrastructure, security, monitoring and the closed beta
Milestone 2: Public Launch $9,250 37% Spent on continued product work, legal documents, infrastructure, support, community activations and public launch execution
Milestone 3: Growth Tracking and Final Report $3,750 15% Deliverables submitted; allocated to continued product operations, growth tracking and reporting after grant close
Total $25,000 100% $21,250 spent through M1 and M2; $3,750 allocated to continued M3 product and measurement work

The main budget change was events and travel. Representing Sippy at ETHGlobal Lisbon, alongside the Cartagena launch and Pizza Day activation, cost more than the original community and travel allocation. Grant spending remained focused on the product, legal, infrastructure, support and user-testing work in the proposal. The founders reduced part of their planned compensation and contributed additional time and costs to cover the difference. The M3 allocation was not used to cover that overrun.

5. Future Plans and Continued Ecosystem Alignment

Sippy’s next phase is focused on testing whether the recipient experience that performed well during live activations can support a repeatable business. Our B2B2C hypothesis is that an organization making recurring payouts can give recipients a reason to use Sippy more often. We are still working through the legal setup, technical scope and pilot design. We have started early conversations, but nothing is signed and we are not presenting them as traction.

If there is interest in continuing, we would propose a gated pilot:

  1. Finish the pilot specification and secure a written commitment. This stage would not require DAO funding.
  2. Launch the pilot and measure payout completion and recipient activation.
  3. Complete a repeat payout cycle and establish a path to paid continuation.

For a follow-on pilot, we would track failed attempts, uptime and cohort retention from the start, with the targets agreed in advance.

Sippy currently runs on Arbitrum One, where the activity reported during this grant settled. We plan to keep sharing what we learn with the ecosystem and to participate in relevant opportunities as the product evolves.

The grant also delivered passkey login, step-up confirmations, sponsored ERC-4337 operations and savings v1. These additions do not change the retention result, but they give us a working base for the next pilot. We think this is a reasonable basis for considering a focused pilot, which would still have to prove the model before any broader support.

6. Additional Remarks

We are grateful to the Arbitrum DAO, the Domain Allocator team, Questbook, Chilla, the program managers, and every user who trusted an early product with a real transaction. The grant helped turn a hackathon project into a production product, gave us room to test it in public, and showed us clearly what to build next.

The complete evidence base, including milestone reports, live metrics, testimonials, documentation and event coverage, remains available in our public grant workspace.

We are closing the grant with a real product, public results and a clearer path forward. Thank you for the role the Arbitrum community played in Sippy’s development.

5 Likes

@mateo Thank you to the Sippy team for a genuinely transparent final report. Flagging the MAW shortfall openly, tying every headline figure to a public, on-chain-verifiable dashboard, and being candid about the budget overrun and its resolution set a strong bar for accountability in this program. The honest read on user behavior — people love receiving funds but often cash out rather than recirculate — is exactly the kind of clear-eyed learning a grants program should produce, even when it complicates the growth story. Appreciate the work, and the straightforwardness in reporting it.

Strengths

• Verifiable on-chain claims. Volume and transaction counts are traceable to Arbiscan via a public dashboard — better than most reports that state figures with no audit trail.

• Milestone-by-milestone KPI table with projected vs. actual is genuinely useful for governance review; most projects don’t self-report shortfalls this explicitly (e.g., admitting the MAW miss).

• Self-reported budget overrun disclosure (events/travel) with founders covering the gap from their own comp — a positive transparency signal, though see concerns below.

• Honest strategic reflection: they flag that recipients often cash out to an exchange rather than holding/recirculating, and use that to justify the B2B2C pivot rather than spinning the number as a win.

Governance concerns:

1. Monthly Active Wallets — the headline miss, softened by placement

Target was 75–100 MAW; actual is 13 (an ~83% shortfall against the low end). This is the closest thing to a “did the product achieve product-market fit” metric, and it’s buried mid-table as “Not met” with no dedicated discussion in the qualitative section. Given 291 registrations but only 13 active in the trailing 30 days (~4.5%), this is a retention crisis, not a rounding miss. Worth asking directly why this wasn’t elevated to a primary narrative point.

2. Selective sampling on “success rate”

The 98%+ transaction success KPI is reported as “55 of 55 monitored sponsored ERC-4337 operations” succeeded — but total qualifying transfers were 458. Why was success monitored on only 12% of transactions? Is this a genuine full-population metric that got mislabeled, or a curated sample? This needs clarification before accepting “Met.”

3. NPS +80 from n=10:

Out of 291 registered users, only 10 responded to the NPS survey (~3.4%). An NPS of +80 is an exceptional score, but on this sample size it’s not statistically meaningful and is likely subject to response bias (happy power users respond; churned users don’t). Presenting it flatly as “Exceeded” without a caveat overstates confidence.

4. Uptime claim isn’t actually measured:

“Close to 100% observed availability… no unplanned outages reported through support or error tracking” is an absence-of-complaints metric, not uptime monitoring data (no mention of a status page, synthetic checks, or SLA tooling). This should be flagged as self-attested rather than instrumented.

5. Final report submitted with M3 deliverables still pending:

The M3 tranche ($3,750, 15% of grant) is explicitly for growth tracking that is described as happening “over the upcoming months” — i.e., after this final report is filed. Governance question: is DAO fund release for M3 being requested before the deliverable it funds is complete? Worth confirming the disbursement mechanics here.

6. Silent scope pivot:

The original grant was for a consumer WhatsApp stablecoin wallet. The report closes by redirecting toward a B2B2C payout product for organizations/apps/AI agents — a meaningfully different business model and user base. Not disclosed as a risk or explicitly flagged as a pivot from the funded thesis; it’s framed purely as “next steps.” Reasonable evolution given the retention data, but a grants committee should treat this as a material change, not a footnote.

7. No opening grant thread:

They note “No opening thread was published” for grant announcement — a transparency/process gap on their side, acknowledged but unexplained.

Questions I’d put to the team before renewal:

1. Why is the success-rate metric based on 55 transactions rather than all 458 — is broader monitoring data available?

2. What does “activation” (47%) mean operationally, and over what cohort/window?

3. Is the 13 MAW figure trending up, flat, or down over the grant period — is there a cohort retention curve?

4. Was the M3 fund release contingent on M3 deliverables being complete, or is it being requested pre-completion?

5. Given the pivot to B2B2C payouts, does the team consider this grant’s KPIs (consumer wallet adoption) still the right ones to judge, or should future funding be re-scoped around pilot-org metrics?

Overall opinion:

This is a reasonably transparent report by grant-report standards — it doesn’t hide the retention miss, and volume/transaction figures are independently checkable. But it’s not “renewal-ready” as written: the flagship engagement metric (MAW) badly missed target, the two headline quality metrics (NPS, transaction success) rest on small or unexplained samples, and the team is quietly changing the product thesis mid-report. I’d treat this as conditional — worth a renewal conversation, but only after the team addresses retention data transparently and clarifies whether they’re asking the DAO to fund the original consumer thesis or a new B2B2C thesis, since those have very different success metrics.

3 Likes

@Arb_Junior Thanks for the close read and for being specific about what needed clarification. We have updated the original report with a visible August 17 note and corrected the KPI table and supporting sections. The figures below refer to the August 15 grant-close snapshot; the live dashboard continues to update.

At a glance:

  • We exceeded the transaction target and missed the monthly active wallet target.
  • Throughout M2, we reported volume as gross throughput. At close, that was $87.8K: $45.2K on-ramped and $42.0K sent onward. The updated report now shows both parts clearly.
  • We recorded no user-facing outage, but did not measure an exact uptime percentage.
  • NPS was +80 from 10 of 291 users, so it is now labeled as directional feedback.

The approved milestones did not include an opening X announcement, but we agree that we should have published one. We disclosed the omission and published a completion thread.

1. Why was success based on 55 operations rather than all 458?

These numbers measure different things. The 458 counts completed transfers. A success rate needs a dataset that also records failed or expired attempts.

The 55 was the monitored count from our July 11 M2 report. Reusing it in the final report was a mistake. We have now recounted the full monitored period through August 15:

  • 131 of 131 sponsored sends landed.
  • Across all sponsored operations, 226 of 227 landed, a 99.6% monitored success rate.
  • The only non-landed operation was one wallet setup that expired.

Full outcome monitoring began with Pimlico-sponsored sends on June 25 and expanded to wallet setup on July 6. We can report a reliable rate for that period, but not for the earlier legacy flow.

The 458 transfers include 51 disclosed Lisbon demos. Even excluding all of them, 407 transfers remain, still above the 200–400 target.

The only reproducible UX issue happened during Pizza Day and involved gas during wallet setup. No user funds were affected. That experience contributed to our move from the legacy gas flow to Pimlico-sponsored account abstraction.

2. What does 47% activation mean?

At the August 15 snapshot, 136 of 291 registered users had sent at least $1 to another wallet or completed an offramp. Receive-only activity, self-sends and sub-dollar transfers do not count.

This shows that they used the core product at least once. It does not show that they returned. We also tested Sippy Quest Season 1 to encourage repeat activity. It made genuine usage more visible, but did not materially improve retention.

3. Is MAW trending up, flat or down?

MAW went from 13 on July 11, to 24 immediately after Lisbon, and back to 13 by August 15. The target was 75–100, so this KPI was clearly not met.

Our acquisition was event-led. After the initial Cartagena launch, we ran activations at Pizza Day, Universidad del Norte and ETHGlobal Lisbon. Each event produced a visible increase in activity, but the increase did not continue afterward.

Lisbon was a late opportunity outside the original plan. We chose to take it after Sippy was selected as one of four Spotlight teams. It also contributed to the disclosed budget overrun, which the founders absorbed.

The offramp is another part of the problem. It works, but the experience is still too complicated for Sippy’s standard of simplicity, so some recipients move funds through external exchanges.

At close, 4 of the 16 wallets active in the previous 30-day period were active again, or 25%. We do not have a complete cohort-retention curve and are not presenting consumer retention as proven.

4. Was M3 requested before its deliverables were completed?

No. We requested M3 after submitting the deliverables.

The report was due around September 5. We submitted it on August 17 after Lisbon became our final activation, then requested the milestone payment.

Submitting early gave us a shorter observation period after Lisbon, but no M3 deliverable remains incomplete. The dashboard and measurement will continue as part of the product.

5. How should the B2B2C direction be evaluated?

The original consumer KPIs remain the correct scorecard for this grant. We are not asking the DAO to replace the MAW result with a new thesis.

B2B2C comes from what we learned. The recipient experience performed well during live activations, but individual users did not have enough reasons to transact regularly. An organization making recurring payouts could provide that frequency using the same infrastructure.

We are still working through the legal setup, technical scope and pilot design. We have started early conversations, but nothing is signed and we are not presenting them as traction.

If there is interest in continuing, we would propose a gated pilot:

  1. Finish the pilot specification and secure a written commitment. This stage would not require DAO funding.
  2. Launch the pilot and measure payout completion and recipient activation.
  3. Complete a repeat payout cycle and establish a path to paid continuation.

For a follow-on pilot, we would track failed attempts, uptime and cohort retention from the start, with the targets agreed in advance.

The grant also delivered passkey login, step-up confirmations, sponsored ERC-4337 operations and savings v1. These additions do not change the retention result, but they give us a working base for the next pilot.

We think this is a reasonable basis for considering a focused pilot. The pilot would still have to prove the model before any broader support.

3 Likes

Thanks for being open about the results. It is interesting that users liked receiving USDC but often cashed out instead of using it again. Did users share why? Was it mainly because they needed local currency, or because there were not many places to spend USDC?

I help with support at Gem Wallet, so this kind of user feedback is helpful.

2 Likes

@mateo This is a strong follow-up — substantively better than most grantee responses to governance pushback.

Well resolved:

• Success rate: Recounting to 226/227 (99.6%) across the full monitored period, and transparently admitting the original 55-count reuse was a mistake, is exactly the right move. Disclosing the monitoring start dates (June 25/July 6) rather than papering over the gap is good practice.

• Volume breakdown: Splitting $87.8K into $45.2K on-ramped / $42.0K sent onward adds real clarity that was missing before.

• NPS relabeled as directional rather than a headline KPI — appropriate given n=10/291.

• Opening thread omission: owned plainly, no deflection.

• M3 sequencing: Clear answer — deliverables were submitted before the payment request, timeline explained. This resolves the concern.

• B2B2C scope: They explicitly affirm the original consumer KPIs stand as the scorecard and decline to reframe the MAW miss around the new thesis. That’s the answer a governance reviewer wants — no quiet goalpost-moving.

Still notable, and to their credit self-disclosed:

• MAW trend (13 → 24 → 13): Confirms the growth was entirely event-driven with no organic carryover. They say this plainly rather than spinning it.

• New retention figure (4/16 = 25% wallets returning): This is a new, more granular metric they volunteered, and they immediately caveat it — “we do not have a complete cohort-retention curve and are not presenting consumer retention as proven.” That’s a well-calibrated disclosure: giving data while flagging its limits.

• Activation definition (136/291 = 47%): Now precisely defined (≥$1 send or offramp), and they’re honest that it measures trial, not return usage.

Remaining question:

The proposed gated pilot structure (spec + commitment → launch/measure → repeat cycle) is a sound de-risking approach, and notably they say stage 1 wouldn’t require DAO funding. Two things worth confirming before any renewal:

1. What specific MAW/retention targets would be pre-agreed for the pilot, given the current program’s target (75–100) was missed by ~5–6x?

2. Timeline expectations for stage-gating — is DAO funding requested only after a written pilot commitment is secured, per their own proposal?

1 Like

@Anzus_GemWallet It depended on the use case. With small event balances, users often wanted COP for immediate expenses. For freelancers receiving income or people sending money across borders, the goal may be to receive value quickly and use it locally, so cashing out is part of the expected flow.

We’re exploring easier cash-out options through regulated partners, including rails connected to Bre-B or other on/off-ramp providers. We also want to test holding and savings behavior in a small closed beta, but both paths still require legal and compliance work.

We don’t have enough structured responses to quantify the split, but we’d be happy to compare notes from your experience at Gem Wallet.

2 Likes

1. On the targets: we would not carry over a fixed MAW target from the consumer phase. The pilot would use cohort-based targets for active recipients, repeat use, successful claims and cash-outs, and whether the organization continues. Retention would need to improve clearly on the baseline we disclosed above.

We would publish the exact targets after securing the written commitment and before requesting funding. Results would be backed by onchain activity, product monitoring and confirmation from the organization.

This would add an organizational distribution and revenue layer to Sippy without removing the consumer product, while testing whether the model can work sustainably across LATAM.

2. On the timing: yes, the commitment comes first. We are speaking with potential pilot organizations now. Only after securing one would we consider requesting DAO support to build, run, measure and report the pilot. General company, legal and commercial costs would remain outside that request.

Sippy originally came through Arbitrum New Protocols and Ideas 3.0. Since that program has ended, which route would you recommend if we reach that stage?

1 Like

Sounds good on both. Cohort-based targets published before any funding request, plus securing the written organizational commitment first, cleanly closes out the open questions on this report. Anyone is welcome to ask further questions.

On routing:

For an organizational distribution + revenue pilot like this, the practical next steps once you have the written commitment are:

• Post on the forum to confirm current fit and get feedback from delegates/Foundation.

• Consider a direct non-constitutional proposal to the DAO (or outreach to the Foundation) for milestone-based support specific to the pilot.

• In parallel, keep an eye on any active Foundation or ecosystem programs (e.g., Mentorship/Open House tracks, ArbiFuel, Audit Program) that might offer complementary support, though they are not the primary fit for an org-payout pilot.

Happy to help review the proposal or forum post once you have the commitment locked

2 Likes

Thanks @Arb_Junior, this is really helpful. We’ll keep working on the next stage and come back once we have something concrete to share. We appreciate the offer to review it when the time comes.

1 Like

Thanks for explaining. That makes sense—if the funds are for everyday needs, being able to cash out easily is an important part of the experience. Appreciate you sharing the context.

1 Like

Thank you for the transparent final report. The team delivered a real product, met the transaction and gross throughput targets, and openly disclosed the retention gap. That level of reporting is appreciated.

However, the central concern remains unchanged: Sippy has validated that users can receive stablecoins through a familiar chat experience, but it has not validated sustained payment behavior. The target was 75 to 100 monthly active wallets, while the grant close result was 13. Event activations created first use, but not recurring usage.

This matters because a chat interface reduces onboarding friction, but it does not itself create payment demand. Even fiat payments inside messaging applications face limited repeat adoption when users already have familiar local payment rails. For a stablecoin product, the bar is higher because users also need a clear reason to hold, spend, or smoothly cash out funds.

The proposed move toward recurring B2B2C payouts is sensible as a new hypothesis, but it should be treated as a material pivot from the original consumer wallet thesis, not as proof of product market fit. Before any follow on support, the team should secure a written pilot partner commitment and define success around repeat payout cycles, recipient activation, cohort retention, local currency exit completion, cost per retained user, and full transaction reliability.

My view: this grant delivered useful infrastructure and honest learning, but it is not renewal ready for broader funding. Any next support should be a small, gated pilot tied to measurable recurring use rather than first time transactions or event driven volume.
@mateo @Arb_Junior

2 Likes

@MconnectDAO Most of your concerns have already been addressed in the thread with Sippy:

• MAW miss (13 vs. 75–100) — confirmed, with trend data (13→24→13) showing it was event-driven, not recurring.

• Treat B2B2C as a pivot, not proof of PMF — Sippy explicitly agreed; original consumer KPIs remain the scorecard, not replaced by the new thesis.

• Written pilot commitment before support — confirmed, commitment first, funding request after.

• Success metrics (repeat cycles, recipient activation, cohort retention) — confirmed, cohort-based targets to be published before any funding ask.

• Gated pilot vs. broader funding — matches Sippy’s own proposed 3-stage gated structure.

Not yet explicitly confirmed: off-ramp/local currency exit completion, cost per retained user, and ongoing transaction reliability as named pilot KPIs.

Not yet explicitly answered:

•	Local currency exit/off-ramp completion as a named success metric — the off-ramp friction was discussed (why users cash out via exchanges), but it hasn’t been confirmed as one of the pilot’s tracked KPIs specifically.

• Cost per retained user — this specific metric hasn’t come up in any exchange so far.

• Full transaction reliability as an explicit pilot-stage commitment — reliability was addressed for the past grant (226/227), but not yet confirmed as a metric they’ll track going forward in the pilot.

@mateo Worth a quick follow-up to lock those in.

2 Likes

@Arb_Junior @MconnectDAO, to clarify what Sippy already has today:

  • Local-currency exit: We have an integrated off-ramp route for Colombia and Mexico, but its KYC process still adds too much time and friction for the experience we want. We are exploring alternative partners and rails. We did not track exit completion as a formal KPI during this grant.
  • Cost per retained user: We do not yet have a reliable fully loaded figure. What we can measure today is the direct account-abstraction cost, which averages roughly one cent per sponsored operation at current gas and ETH prices, including Pimlico’s surcharge. A retained user’s direct transaction cost therefore depends on their activity. Building the complete cost model is also part of Sippy’s commercial plan, since organizational pricing must cover providers, support and operating costs for the product to become sustainable.
  • Transaction reliability: We changed the underlying gas infrastructure during the grant, replacing our legacy gas-refill contract with Pimlico-sponsored ERC-4337 account abstraction. Of 227 tracked sponsored flows after the migration, 226 were submitted and all 226 landed successfully. The remaining wallet setup was prepared but never signed or submitted before its five-minute authorization expired. It consumed no onchain gas and no funds were at risk.

We are still evaluating the organizational pilot internally, so we are not presenting it as finalized. If we move forward, these would become explicit scorecard metrics: local-currency exit completion, fully loaded cost per retained recipient, and reliability across the complete flow. The final definitions and targets would be published with the pilot scope and before any funding request.

1 Like

We really appreciate the discussion and the opportunity to clarify our thinking around the pilot, the metrics, transaction reliability, and the off-ramp experience.

At Sippy, our vision is to make stablecoins simple and useful for people across Latam. Most people should not need to understand blockchain, wallets, gas, or any of the technology behind the product. The experience should feel familiar and easy, while the complexity stays in the background.

We know there is still work to do, and conversations like this help us identify what needs more attention. We’re listening closely, continuing to learn, and building toward a product that can be accessible to anyone, regardless of their technical background.

Thank you @MconnectDAO for all your concerns they are helping us strengthen the pilot design. We understand that all of your points are highly important to us and help improve our vision for the project.

We greatly appreciate the points you highlighted @Arb_Junior, as they allow us to rethink our business model moving forward. It is highly important for us to advance with this perspective; therefore, we agree that any pilot must be gated, with written commitments and published metrics before any funding request is made.

We’re optimistic about the next steps and committed to building this carefully, transparently, and with measurable outcomes. Thanks again for helping us improve Sippy.

4 Likes

As Cartagena Onchain, Sippy has been one of the easiest ways for us to show our community the power of account abstraction and how simple it can be to interact with blockchain.

Most people who attend our events are not technical. They come from different professional backgrounds and socioeconomic contexts, but we’ve found something they have in common: for many of them, using Sippy feels familiar and accessible. They can interact with blockchain without having to understand complicated wallets, networks, or technical processes.

We had the opportunity to welcome Sippy to events such as Ethereum Everywhere in Cartagena, including a talk by @fabio

Sippy Ethereum Eveywhere - X
Sippy Ethereum Everywhere - Instragram

Sippy also helped many new users make their first pizza purchases during the Global Pizza Party 2026 in Cartagena, Colombia. These experiences showed us how powerful this kind of simple onboarding can be.

Sippy PizzaDao - X

We would love to see more integrations and everyday use cases built around Sippy, so the community can continue using it in real life not only at events. We truly believe more people should know about this technology. We know that making this happen requires a strong strategy and many hands, and that’s why we’re here: to help blockchain and everything being built onchain reach more people.

Onchain or nothing!

1 Like