[Grant Request] Deakee — ERC-8063 Reference Implementation on Arbitrum One ($75K ARB)

Early Idea Discussion
1

Contact: contact@deakee.com · Telegram @jamesdeakee

TL;DR

I authored ERC-8063 (Groups: Membership Tokens) — a finalized Ethereum standard that defines the membership-token primitive. Deakee is the first production app built on it: a token-gated coupon discovery app live on iOS, Android, and web with 350+ partner brands and 1,200+ active coupon codes.

This grant funds porting the ERC-8063 reference implementation to Arbitrum One: clean Solidity contracts, full Foundry test suite, independent audit, and Deakee’s consumer app running natively on Arbitrum. The reference contracts will be MIT-licensed — any Arbitrum team building loyalty programs, governance tier gating, or membership access can fork them.

About me

I’m the sole author of three finalized Ethereum standards:

  • ERC-8063 — Groups: Membership Tokens (this proposal’s subject)
  • ERC-7743 — Multi-Owner NFTs (MO-NFT)
  • ERC-7837 — Diffusive Tokens

Authoring finalized EIPs is rare — it requires specs that survive community review and reference implementations that interop with the broader ecosystem. I’ve done it three times, all sole-authored.

I build full-stack: Solidity, React/Next.js, Node.js, native iOS (Swift), native Android (Kotlin).

What ERC-8063 is

ERC-8063 defines a token model where balance = membership level, not transferable currency. It’s the standardized primitive for:

  • Token-gated access (hold X tokens → unlock Y access)
  • Loyalty tier programs (Bronze / Silver / Gold without a points database)
  • Governance tier gating (DAO roles based on token balance thresholds)
  • Partner ecosystems (each brand issues its own token; DKG is the on-chain rail)

Read the spec: Groups - Membership Tokens | Ethereum Improvement Proposals

What Deakee is (live proof)

Deakee is a token-gated coupon discovery app. Users hold DKG tokens (they don’t spend them) to unlock exclusive partner codes. Every coupon has a requiredBalance threshold — the app reads the user’s on-chain balance and reveals qualifying coupons in real time.

Live metrics:

  • 350+ active partner brands (Awin network)
  • 1,200+ active coupon codes
  • iOS · Android · Web all shipped
  • Real affiliate commissions from day one
  • 78,000+ Shopify stores in outreach pipeline

App links: iOS · Android · Web

What this grant funds (4 months)

  • Month 1 — Solidity port to Arbitrum One + comprehensive Foundry test suite (100% coverage + fuzz tests) — $20K
  • Month 2 — Arbitrum wallet integrations (Rabby, MetaMask, Arbitrum Bridge UX) + Deakee mobile/web pointing at Arbitrum contracts — $15K
  • Month 3 — Independent security audit (Code4rena or equivalent) — $25K
  • Month 4 — MIT-licensed reference repo published + integration docs + 50 Arbitrum-ecosystem brand partner onboardings — $15K

Public good deliverable: github.com/jamesavechives/erc-8063-reference — open-source, MIT-licensed, Arbitrum-native. Any team building loyalty, governance gating, or membership access on Arbitrum can fork it.

Why Arbitrum specifically

  • EVM equivalence — DKG contracts deploy unchanged, no rewrite risk
  • DeFi-native user base — token-gating is a DeFi-shaped consumer pattern; Arbitrum users understand the model
  • Low fees — membership check = one contract call; cheap reads make the coupon flow viable at consumer scale
  • Existing consumer surface — Galxe, Layer3, Arbitrum Nova all on Arbitrum; Deakee targets the same audience

Why this benefits Arbitrum’s ecosystem

ERC-721 became dominant because OpenZeppelin shipped the canonical reference contract that teams could fork in an afternoon. ERC-4626 adoption accelerated when Solmate published a clean implementation. ERC-8063 needs the same on Arbitrum.

Funding this puts Arbitrum One as the canonical home for the membership-token reference implementation — a primitive that applies to loyalty, governance, creator memberships, and partner ecosystems across the ecosystem.

Budget

  • Engineering (Solidity port + tests + integration + docs) — $35,000
  • Independent audit (Code4rena / Trail of Bits scope) — $25,000
  • Partner BD (50 Arbitrum-ecosystem brands in 90 days) — $10,000
  • Contingency — $5,000
  • Total: $75,000

Milestones & accountability

All milestones delivered on-chain or as public GitHub commits — no trust-me deliverables:

  • Month 1: Tagged git release of Arbitrum-deployed contracts + Foundry coverage report
  • Month 2: App store update (iOS/Android) with Arbitrum network + Arbiscan link for deployed DKG contract
  • Month 3: Public audit report from recognized firm
  • Month 4: Open-source reference repo + live list of 50 onboarded partners

Happy to structure this as milestone-based tranches rather than a lump sum.

Questions / discussion welcome

I’m active and responsive. Reach me on this forum, X (@deakeegroup), or Telegram (@jamesdeakee).

1 Like
2

THIS IS MY METAMASK ACCOUNT, I NEED assistance on the platform!

1000005041
10000050412448×3264 607 KB

1000005043
10000050432448×3264 528 KB

1000005042
10000050422448×3264 545 KB

3

The technical work here is solid, but $75K feels inflated for what is essentially an ERC-20 wrapper extension. Engineering at $35K and wallet integration at $15K are both overestimated a senior Solidity dev can cover both for ~$25K combined. The $25K audit is fair. The $15K “ecosystem onboarding” is a marketing cost, not a technical deliverable, and shouldn’t be in this grant scope.

Also worth noting Deakee is already live with 350+ brands. If the app exists, wallet integration is partially done. What exactly is new here?

A tighter ask of ~$45K–$50K with clearer milestones would make this much easier to support. Happy to see this move forward, but the budget needs a revision pass before voting… @deakeegroup

1 Like
4

Thanks @MconnectDAO — genuinely useful feedback, let me address each point directly.

The scope is not one ERC-8063 contract — it’s a multi-token ecosystem.

The reference implementation covers four interlocking systems that need to go on-chain:

  1. Per-partner token contracts — each partner brand issues their own ERC-8063 token (symbol, supply, pricing). This is not one contract. It’s a factory + per-partner deployments, each ERC-8063 compliant.
  2. Multi-token coupon gate — coupons use either DKG (hold minimum, not deducted) or the partner’s own token (spend, deducted). Two distinct claim paths, two on-chain verification flows.
  3. Order-book exchange — a maker/taker exchange where every partner token trades against DKG as the base pair. Price-time priority, partial fills, market orders, per-token mutex and balance freezing. This alone is a non-trivial Solidity deliverable.
  4. OAuth2 bridge contracts — external brand apps push partner token balances to Deakee user wallets via client_credentials or authorization_code flows, with idempotency keys and rate limiting. This is what lets brands embed into Deakee without being replaced by it.

No coupon platform has this. Honey has no token issuance. Rakuten has no per-brand exchange. RetailMeNot has no OAuth2 token bridge. None of them can replicate this without building a crypto layer from scratch.

On “ERC-20 wrapper extension”: ERC-8063 does extend ERC-20 — that’s correct. But the grant is funding the reference implementation of the full multi-token ecosystem described above, not a single token contract. Calling it a wrapper undersells what’s being built.

On “wallet integration is partially done”: The current app runs an off-chain custodial ledger — balances, the exchange, and OAuth2 transfers are all off-chain today. The grant funds porting all four systems on-chain to Arbitrum. Off-chain and on-chain are different systems.

On Month 4 scope: Fair point — I’ll split the open-source reference repository (technical deliverable) from partner onboarding (BD) into two separate line items.

Happy to post a full contract-by-contract technical breakdown if that helps the committee evaluate the scope.

1 Like
5

Thanks for the detailed breakdown the four-system scope makes the engineering ask much clearer now.
I’ll revise my earlier position: the $35K engineering line is justifiable given the factory contracts + order-book complexity. The audit at $25K is fair for this surface area.
My remaining ask before full support:

Can you share a revised budget table with Month 4 split (open-source repo vs. BD onboarding as separate line items)?

What is the revised total ask still $75K, or adjusted?

Once the updated breakdown is posted, I’m happy to move to support. The on-chain architecture is non-trivial and Arbitrum is the right chain for this. Looking forward to the revision. @deakeegroup

6

Thanks @MconnectDAO — appreciate the detailed review and the revised position.

To answer your questions directly: the total ask remains $75,000 ARB. Month 4 was previously a single bundled line item, so here’s the clarified breakdown:

Revised Budget Table

Month Deliverable Amount
Month 1 Smart contract development — ERC-8063 factory contracts + coupon gate logic on Arbitrum One $20,000
Month 2 Order-book exchange contracts (DKG as base pair) + full integration test suite $15,000
Month 3 Third-party security audit $25,000
Month 4a Open-source reference repository — full source code, NatSpec docs, deployment scripts, MIT licence $10,000
Month 4b Partner onboarding coordination — 50 ERC-8063 partner integrations, technical support $5,000
Total $75,000 ARB

Month 4 was always two parallel workstreams; splitting them makes the scope clearer. The technical deliverable (the open-source repo + docs) is distinct from the BD effort of guiding 50 partners through their ERC-8063 integration on Arbitrum.

No change to the total. Happy to address any further questions before the review moves forward — and thank you again for pushing for the clarification.

1 Like
7

The revised budget table is much cleaner now.

8

Thanks @MconnectDAO — glad the revised breakdown is clearer. Appreciate the thorough engagement throughout the review.

1 Like
9

Quick update for delegates following this proposal:

Deakee is launching on Product Hunt on May 10 — the consumer app goes fully public for the first time. This is relevant context for the grant: the Arbitrum deployment in Month 1 would be the immediate next milestone after launch.

A few things that may be useful for evaluation:

The Product Hunt launch gives the grant a concrete before/after marker: consumer traction first, then chain-native infrastructure. Happy to answer any outstanding questions before the review moves forward.

1 Like
10

Thanks for the updat the Product Hunt launch on May 10 gives this proposal a clear and verifiable milestone, which makes evaluation straightforward for delegates.

A few things that stand out as positives from a governance perspective:

Real traction already exists 350+ brands, 1,200+ coupons, live affiliate revenue. This isn’t a speculative ask.

ERC-8063 reference repo is already public on GitHub — the work is happening regardless; the grant accelerates Arbitrum-native deployment, not ideation.

The consumer-first → chain-native infra sequencing is sensible and reduces execution risk.

Supporting this proposal moving forward. The ask is reasonable relative to the deliverables, and the team has shown they execute before asking. @deakeegroup

1 Like
11

Thanks @MconnectDAO — the explicit support means a lot, and your read on the sequencing (consumer-first → chain-native infra) is exactly the framing we wanted delegates to walk away with.

The PH launch on May 10 will be the first public verifiable milestone. I’ll post a follow-up here within a week of launch with the live numbers (sign-ups, partner activations, on-chain DKG mints), so delegates can evaluate against the deliverables rather than against intent.

Looking forward to coordinating the warm-intro layer once the grant moves.

1 Like
12

Interesting initiative.

As L2 and Orbit ecosystems continue to fragment and scale, standardized infrastructure layers and interoperable tooling will likely become increasingly important for long-term developer adoption and operational reliability.

Clear reference implementations can play a major role in reducing integration complexity across heterogeneous environments.

Looking forward to seeing how this evolves within the broader Arbitrum ecosystem.

1 Like