Launch ZKP on BASE

Panther Ecosystem
1

Hey guys! Opening this topic to discuss the possibility of launching of ZKP on the BASE L2 network…please provide your inputs on the same! Thanks

1 Like
2

This is a new and trending ecosystem launching on the 9th of August (tomorrow)! And would help enhance the visibility of V1 come launch!

1 Like
3

I think now we are nearing the POLYGON Launch it may be interesting to see if anyone out there would be willing and capable of launching the protocol on Base for us?

2 Likes
4

So Base might be a good second chain to launch on. The existing code is easier to integrate with other L2s vs let’s say a completely new chain like Solana or even those that aren’t Eth L2s like BNB Chain. It has a strong ecosystem and recently it looks like they’re looking at privacy preserving stablecoins.
Panther with its architecture I think is a good fit.

5

I agree if we can get ourselves promoted on a existing L2 with new traffic without having to do to much work to integrate. That’s the way to go.

6

Zpoken Proposal – Panther Protocol Base Network Enablement

Applicant: Zpoken OÜ (independent open‑source contributor)

Category: Research & Tooling (non‑operational)

Networks Covered: Base & Base Sepolia (configuration/testing only; no live deployments)

License: MIT (or Apache‑2.0, at Foundation’s preference)

1) Summary

This grant funds open‑source research, configuration, scripts, and documentation that enable independent third parties (e.g., a DAO, community operators) to later deploy Panther Protocol on Base. The work is non‑custodial and non‑operational: no on‑chain deployments, no UI operation, no multisig/treasury control, and no user‑funds interaction. Outputs are public, reproducible, and licensed permissively.

2) Motivation & Problem

The Panther codebase is EVM‑compatible but lacks a policy‑compliant, reproducible path tailored for Base. Ecosystem operators need clear network configs, deployment/verification scripts, parameter templates, and a runbook to execute independent deployments without relying on service providers or violating Foundation policy (no direct operations). This grant produces exactly those artifacts.

3) Scope of Work (In‑Scope)

  1. Hardhat Network Enablement

    • Add/Base and Base Sepolia configs (RPCs/env templates).

    • Reproducible builds for protocol packages & tasks.

    • Deterministic artifacts (ABIs, bytecode, metadata).

  2. Simulation & Compatibility Testing

    • Local/ephemeral test environments only (e.g., Anvil/Hardhat network).

    • Automated smoke tests covering: core registry/init flows; sample staking term wiring; role hand‑offs in a simulated context.

    • Notes on gas/bytecode size, compiler targets, and chain‑specific quirks.

  3. Deployment Runbook (for independent operators)

    • Step‑by‑step commands for hypothetical deployments (testnet/mainnet).

    • Verification scripts (Basescan API flows).

    • Rollback/Recovery guidance (upgrade paths, pausing, parameter resets—purely procedural, not executed by grantee).

    • Address/parameter templates (JSON/YAML) for role accounts (e.g., multisig, treasury, trustProvider), token addresses, and staking terms.

  4. Open‑Source Publication

    • Public GitHub repo with code, docs, and CI.

    • Repo disclaimer & POLICY compliance notice (see Section 10).

    • Optional: minimal subgraph scaffold and dApp wiring stubs kept disabled by default.

4) Explicit Exclusions (Out‑of‑Scope)

  • No deployments to Base mainnet by the grantee.

  • No UI operation/hosting or user‑facing service.

  • No custody of keys, no multisig/treasury management, no relaying, no upgrades.

  • No user‑funds interaction and no production monitoring/on‑call.

  • No brand/UI operation beyond documentation and disabled code samples.

5) Deliverables

  1. Network Configuration Pack

    • hardhat.config additions for Base/Base Sepolia

    • .env.example for RPC/verification keys

    • Scripts to build protocol packages and tasks deterministically

  2. Automation Scripts

    • scripts/prepare/*: parameter assembly from templates

    • scripts/deploy/*: dry‑run routines (local only)

    • scripts/verify/*: Basescan verification helpers

  3. Deployment Runbook (Markdown/PDF)

    • End‑to‑end flow for independent operators (testnet→mainnet), incl. pre‑checks, transactions order, verification, and rollback playbooks

  4. Parameter Registry Templates

    • JSON/YAML schemas for roles, zAssets (e.g., WETH/USDC), staking terms (APR, durations, caps), and oracle/pool hooks

  5. Final Technical Report

    • Compatibility notes, known issues, gas/size observations, and recommendations

  6. (Optional) Extras

    • Minimal subgraph scaffold and dApp wiring stubs (off/disabled)

    • CI workflow: lint/format/build/test on PR

6) Milestones & Budget

Total Grant Requested: USD 14,000 equivalent

Milestone Scope Artifacts Acceptance Payout
M1 – Base Enablement Pack Hardhat configs, deterministic builds, scripts skeleton; parameter templates v1 PR with configs; .env.example; build artefacts; docs draft Maintainer review + basic CI green $7,000
M2 – Runbook & Final Report Full runbook (deploy/verify/rollback), verify helpers, local smoke‑tests, final technical report; optional subgraph/UI stubs (disabled) Published repo & docs; CI passing; tagged release v1.0 Maintainer approval + publication under permissive license $7,000

Note: No on‑chain actions by grantee are required for acceptance.

7) Reporting & Communication

  • Weekly progress notes (short written update).

  • Code reviews via PR in a public repo.

  • One closing call/written summary upon grant completion.

8) Dependencies & Inputs (Non‑Operational)

  • Public RPC endpoints and Basescan API keys for documentation/examples only.

  • Community‑provided example addresses for templates (multisigs, treasuries, trustProvider), not used by the grantee.

  • Token metadata for sample zAsset templates (e.g., WETH, USDC) to illustrate configuration.

9) Team & Track Record

  • Zpoken OÜ – independent R&D team with deep EVM experience (smart contracts, tooling, L2s) and prior contributions across Interoperability/DeFi/RWA.

  • Key skills: Hardhat/Foundry, Solidity build chains, verification tooling, CI, reproducible deployments, ZK and cryptography.

10) Compliance Statements

  • Independent Status: The grantee acts independently and does not operate or deploy Panther Protocol on any network.

  • No Operations/No Custody: No UI operation/hosting; no keys; no funds; no multisig/treasury management; no upgrades/relaying.

  • Open‑Source Licence: All outputs released under MIT (or Apache‑2.0) with the following disclaimer placed prominently in each repo:

    “This repository is provided for research and educational purposes only. The Panther Protocol Foundation does not operate or deploy this code on any network. Any deployment or operation is undertaken solely by independent third parties at their own risk.”

  • No Incentives Tied to TVL/usage: Payment strictly milestone‑based; no performance fees, no rev‑share, no token‑based compensation.

  • No User Data: The work does not process or retain user data.

11) Timeline

3 calendar weeks from kickoff for M1→M2 handover (non‑operational). This is informational only and does not imply any on‑chain activity.

3 Likes
PIP-29: Rewards minting and Vesting Implemention