POP Objective

The Gateway Kit is making significant progress towards abstracting a gateway’s integration with the protocol, lowering the barrier to entry for new gateways, and is on track to complete the Initial Release Candidate in January.

One philosophy of the Gateway Kit is to be modular and agnostic, to maximise the flexibility for the Gateway Kit to be used in different architectures. For example, the Gateway Kit generates a single-tenancy HTTP endpoint for each blockchain that POKT supports, so that it can more easily be plugged into different multi-tenancy architectures. Multi-tenancy is generally strongly technically opinionated, such as which language, framework, and authentication provider to use. Existing RPC providers who want to become gateways will already have a multi-tenancy architecture, so they would simply add the Gateway Kit server as a blockchain node to their load-balancer rotation.

Our goal as PNF is to ensure that the barrier to entry is as low as possible for prospective gateway operators. One way that we can do this is to ensure that when the Gateway Kit’s initial release is complete, there are open-source reference implementations (demos) for the operators to reference when they are learning how the Gateway Kit interacts with the POKT protocol.

This Pocket Open Priority (POP) invites community builders to build open-source reference implementations of a full-stack user-facing gateway.

POP Specifications

Take the Gateway Kit and build on top the other components required for a user-facing, demo gateway, including the following must-have components

  • Authentication and multi-tenancy endpoints, enabling users to login and create authenticated endpoints for themselves
  • Request tracking (e.g. to power rate-limiting)
  • Reverse proxy setup to send requests to the gateway kit server
  • User-facing frontend


  • All components listed above are included in the reference implementation
  • Full reference implementation is open-source
  • Should not include copyleft components, so that private businesses are unrestricted in forking the reference implementation
  • Integrated with the Gateway Kit as the underlying backend for POKT integration


  • As many components as possible leverage standard, actively-maintained open-source libraries
  • Extra SaaS components, like payments, analytics, alerts
  • Admin UI for managing app stakes and visualizing statistics by ingesting Gateway Kit prometheus metrics

POP Funding & Application Details

  • Open: Now
  • Price: TBC - based on submissions. Preference will be granted to submissions that are priced in POKT.
  • Funding: This submission will be funded from the Era Allocation as outlined in PEP-60 ERA Budget.
  • Submission Deadline: Close of day 3rd January
  • Decision Provided: Close of day 5th January

Submission details requested:

  • Full scope of work, including technical specification (include language and frameworks used)
  • Estimated timeline
  • Breakdown of expected fees and payments
  • Team working on it

Submissions should be posted as replies to this thread. Submissions can be edited at any point up until the deadline.



I am delighted to present a detailed proposal for developing a cutting-edge Software as a Service (SaaS) web portal, leveraging the Gateway Kit as its backend.
Our proposition aims to surpass expectations by incorporating must-haves and some nice-to-have features, ensuring a robust and scalable portal that aligns with the needs of modern self-service SaaS portals.
This development will be agile and involve all needed stakeholders from PNF and the Pocket community. The portal will be built on top of the Gateway Kit and include all required features for a user-facing, demo gateway, including the must-haves cited in the POP above.
We also propose including and handling a demo portal hosting at no additional cost.

Why us?

Spacebelt. LLC is a web3 company focused on Ethereum and Pocket Network ecosystems, we aim to contribute to the POCKET community with multiple open-source projects.
I got into the pocket pot in January 2022, my first node costs me almost 20k for 15k POKTs. As a token holder and a long-term staker, I’ve never sold a POKT and I’ve always staked the entire rewards while covering all costs from other income.

We have developed and privately opened a monitoring platform called “Poktana” that leverages nginx logs to monitor pocket nodes (screenshot below).

Unfortunately, we had to end the development because PocketScan was including a lot of similar features in their great portal. We decided to shift focus and start working on a gateway portal while waiting for the backend layer to dispatch requests to the Pocket network.

Thanks to Nodies’s efforts, we have now an open-source pocket gateway backend (The Gateway Kit) on which we can build a new RPC business. We aim to be the 3rd gateway after Grove and Nodies.

We also plan to open-source all common building blocks we used for Poktana to improve and accelerate the development of the gateway kit portal.


I think it’s important to express our motivation for this first collaboration with PNF to emphasize our dedication to the Pocket network. We highly believe in the democratization of decentralized RPC and the role that gateways will play in making blockchain more accessible and unstoppable.

We are aligned with the PNF’s goal of lowering barriers to entry for gateway operators, that’s why we’re keen to create accessible, user-friendly and open-source tools that contribute to the growth and success of the Pocket Network.

Scope of work

The scope of work for this proposal involves the development of an open-source reference implementation for a user-facing portal using the Gateway Kit.

The implementation will include the following 4 components :

  1. Public frontend

    • Publicly available web pages including the landing page, pricing page, login and register page.
  2. User Portal

    • Authentication

      • Secure authentication mechanisms to enable user authentication, email verification and password reset.
      • Multi-tenancy features allow users to create and manage authenticated endpoints with tokens within a multi-tenancy architecture.
    • User profile

      • A user profile page that allows users to customise their personal information easily.
      • RPC endpoints management
      • Endpoints management page to manage all protected RPC endpoints
    • User dashboard

      • A minimal dashboard to visualise real-time request statistics by ingesting gateway kit Prometheus metrics.
  3. Admin Portal

    • User management

      • A user management page to manage users and tenants.
    • Gateway kit config page

      • An admin page to manage gateway kit configuration.
    • Dashboard

      • A minimal dashboard to visualize some business KPIs
      • NB of users
      • Relays traffic
      • Success / Error rates
  4. Reverse proxy config

    • Nginx setup to forward requests to the gateway kit server

Nice-to-have features

As mentioned above, we already have several building blocks that we may add to the project deliverables including :

  • Subscriptions
  • Payments
  • Pricing plans management
  • Payment services integration
  • OAuth authentication

Still, we have chosen to refrain from committing to the incorporation of these nice-to-have features in this proposal to prioritise delivering a robust, functional, and timely solution that aligns with the POP specifications, we want to ensure that the core functionality of the portal is effectively implemented and meets the immediate needs of future gateway operators.

While we recognize the potential value of nice-to-have features, our commitment is to deliver a reliable and open-source portal that can serve as a solid foundation for future enhancements and community contributions.


  • WEEK 1

    • Admin UI design and UI components
    • Backend architecture and schema design
  • WEEK 2

    • High-level architecture diagram
    • Docker preparation for development environment
  • WEEK 3

    • Database model implementation as database migrations
    • Public pages implementation: Landing page, pricing page, login and register page.
  • WEEK 4

    • Authentication implementation: user authentication
    • Email verification and password reset forms
  • WEEK 5

    • Access token management
    • Multi-tenancy implementation.
  • WEEK 6

    • User profile development
    • User management implementation
  • WEEK 7

    • Gateway kit config page
    • RPC endpoint management pages
    • Reverse proxy config
  • WEEK 8

    • Traffic dashboard: Request tracking and KPIs
  • WEEK 9

    • Admin dashboard implementation
    • User dashboard implementation
  • WEEK 10

    • e2e tests and bug fixes
    • Documentation

Technical specifications

This project will be based on Laravel framework and will use the following open-source components :

  • Laravel 10.x
  • MariaDB 10.x - LTS
  • Nginx 1.24.x - LTS
  • Tailwind CSS

Cost & Delivery

The delivery timeline for the complete project is set at 90 days from the approval date.
Development and delivery will be ensured by 2 dedicated full-stack developers.
The entire project will be executed for payment in POKT, estimated at 60,000 USD.
The entire POKT will be staked.


Decentralized Authority (DA) is pleased to present a proposal to construct Gateway Base, an innovative, full-stack, modular gateway, and framework. This project is designed to fulfill both the “Must-have” and the “Nice-to-have” elements, while focusing on two main objectives:

GOAL 1: Develop a customizable, modular framework equipped with all vital components necessary to launch new, multi-region DePIN (Decentralized Physical Infrastructure) gateways.

GOAL 2: Create a framework enabling POKT to become the pioneering DePIN network with distributed gateways. This approach transforms gateways into nodes, facilitating widespread deployment and fostering true decentralization within the POKT network.

GOAL 1: Crafting a Customizable, Modular Framework

Architectural Vision :building_construction:

DA envisions a foundational framework that encapsulates all crucial components for a gateway. This positions POKT as a comprehensive solution for new DePIN initiatives, enabling startups to make their data decentralized using the Pocket protocol, and enabling rapid development of their own gateways to grow users.

Consideration: POKT’s potential for AI integration is widely discussed. However, AI startups currently need to create a separate gateway to facilitate user access to any AI services on POKT. By providing an integrated protocol and gateway architecture, POKT can be the one-stop platform for easily launching a decentralizing data services.

DA proposes a highly modular system, offering developers flexibility in component selection and customization. This approach allows startups to leverage Gateway Base for foundational functionalities, concentrating their efforts on innovative features like:

  1. Data Analytics: Enhancing endpoint usage data utility.
  2. Privacy: Developing customer data protection systems.
  3. Indexing: Optimizing data storage for efficient access.
  4. Custom APIs: Streamlining data delivery.
  5. Unique Payment Structures: Offering diverse payment options.
  6. Project Specific Needs: Focusing on tailored services.

A Proven Architecture

DA’s proposal draws on our experience with designing a similar architecture for Community Chains (CC). Today CC still stands as the first DNS distributed gateway in Web3, connecting POKT nodes to a distributed, global pool of chain nodes directly via DNS.

CC has operated autonomously for six months, handling significant POKT traffic volumes (upwards of 20% at times) and successfully tested at bandwidths of up to 6 billion relays daily. We paused further tests due to the costs associated with multi-region testing.

We advocate for this architectural model for Gateway Base due to its demonstrated modularity, automation, performance, and resilience.

Core Architecture

Gateway Base comprises three primary components:

  1. Gateway Node(s)
  2. Gateway Command
  3. Portals

This diagram provides the applications and modules being built as part of Gateway Base, with their coding languages, and external open-source libraries and dependencies.

1. Gateway Node (GN)

GNs function akin to POKT nodes, primarily processing user relays. These relays are routed via DNS to a GN, where they undergo TLS unpacking and applicable filtering or routing before reaching the POKT network via Gateway Kit. GNs can be globally deployed to ensure worldwide coverage and low latency.

A key feature of GNs is the GController, which manages modules and containers, enhancing Gateway Base’s scalability. This feature allows for custom filtering and routing logic implementation, encouraging innovation in areas like Custom APIs or WebSockets.


GController includes an “Update Cycling” feature, circumventing the need for costly HAProxy enterprise subscriptions. This design allows for seamless HAProxy configuration updates without downtime, bypassing the limitations of the free version. This feature is part of CC, and allows config changes without losing any relays or logs.

2. Gateway Command (GC)

GC serves as the central management system for the Gateway Base stack, integrating data, logs, automation, and controls. Its modular design enables customization to meet specific gateway requirements.

For instance, Cloud Modules facilitate API interactions between GServer and cloud services. While we provide an AWS-compatible reference implementation, these modules can be adapted to work with various services, offering a versatile “pick your own adventure” approach for gateway owners.

FEATURE HIGHLIGHT: Operational Autonomy

GC’s design ensures GNs maintain user service capabilities, even if GC is offline. This architecture has proven effective in CC operations, allowing uninterrupted user service during major system updates. Even if GC is offline for an extended period of time, GNs will continue serving relays without skipping a beat, and all components will seamlessly resync once GC has been restored.

3. Portals

User-friendly GUI portals are crucial for any service. Besides User Portals, we emphasize the importance of Admin Portals. In CC, our Admin Portal enables comprehensive management of CC Towers (equivalent to GNs in Gateway Base), usage tracking, user management, and payments.

FEATURE HIGHLIGHT: Serverless Portals

We aim to develop portals with a serverless architecture, facilitating scalability and ease of customization through API-driven data retrieval via cloud services connected to GC.

GOAL 2: Enabling Distributed Gateways in the POKT Network

The separation of Gateway Command from Gateway Nodes paves the way for the future development of truly distributed gateways within the POKT network. We envision a scenario where gateway owners manage Gateway Command and Portals, while other hosts operate Gateway Nodes. This model, already successful in CC, ensures maximum decentralization for resilience and global coverage.

Integrating Distributed Gateways as a standard, user-friendly feature requires additional development but is achievable with the Gateway Base foundation. Emphasizing a decentralized approach from the outset positions POKT to lead in gateway technology, alongside the POKT protocol.

Distributed gateway tech is the next evolution of DePIN, and the POKT ecosystem is best suited to be its pioneers.

Submission Details

Team & Background

The project leads are @shane and @AmishBatman, potentially collaborating with contractors and community members as needed. Our track record with the POKT DAO and PNF includes successful deliveries, 100% of the time, across proposals, Sockets, and POPs. This includes the recent POKT wallet, which was completed within two months, with a budget that was 1/4 and 1/10 of past wallet initiatives.

Regarding gateways, the proposed architecture has already been widely battle tested though CC. The team brings direct experience in distributed gateways, and have been a prominent contributor in bringing gateways to the protocol itself.

Timeline & Budget

The project duration is estimated at 8 months, with the following development phases:

  1. Gateway Node Alpha - Completion in month 2.
  2. Gateway Command Alpha
    a. Cloud Modules - Completion in month 4.
    b. GServer - Completion in month 5.
  3. Gateway Node and Gateway Command Version 1 - Completion in month 7.
  4. Portals - Completion in month 8.

The budget is set at $25k per month, totaling $200k. This estimate is 40% less than the current Gateway-verse bootstrap initiative (which provided POKT with Gateway Kit), with the added advantage of Gateway Base being a fully open-source initiative. Payments, preferably a 50/50 mix of stables and POKT, will be made at the start of each month. DA is willing to work with PNF to come up with the ideal ratio for their ERA budget.

Progress will be trackable via public repos and public updates directly from the team. DA is very active within the weekly community calls, and is always open to discuss progress and answer questions on-call.


Gateway Kit vs. Gateway Base: What’s the Difference?

While Gateway Kit integrates POKT into existing gateways, Gateway Base focuses on establishing new gateways or evolving existing ones into distributed systems. Gateway Base encompasses elements beyond the scope of Gateway Kit.

Gateway Kit covers:

  1. Handling App Stakes
  2. Generating App Sessions
  3. Single Endpoint access to an App Session
  4. Session level QoS
  5. POKT traffic logging

Gateway Base covers:

  1. Geolocation DNS
  2. TLS
  3. User generation
  4. Endpoint generation
  5. User facing UI
  6. Admin facing UI
  7. Load balancing
  8. Request tracking
  9. Call Filtering/Routing
  10. Gateway level QoS
  11. Payments
  12. Automations

Gateway Kit and Gateway Base combined creates a full-stack framework for new, POKT enabled, DePIN gateways.

Why Opt for a Full Framework Instead of a Simple Gateway?

A “simple gateway” will likely not drive significant traffic to POKT. World Class gateways require substantial investment and methodical architecture to achieve competitive performance on a global scale and draw user interest. Both Grove and Nodies’ gateways were built with substantial DAO funding and have taken time to build.

Gateway Base aims to use fewer resources than past initiatives, while maximizing efficiency, so new gateways can be quickly created, with enterprise-level performance, using an open-source modular framework. This will give all new gateways the ability to focus on value-add features to drive new users and revenue to the POKT protocol (the north star metric POKT is focused on).


Today on the Ecosystem Community Call we talked extensively about the purpose of gateways, how they should be seen alongside the protocol, and what the future could look like with distributed gateways.

One of the most important concepts to come out of it, was thinking about how gateways act as an L2 to the POKT ecosystem. They facilitate features and use experiences that aren’t possible with the protocol itself. This is similar to how L2 on Ethereum enable speed, privacy or low costs not possible on ETH itself.

I think it’s important that POKT start thinking about the big picture of gateways and the tech that would be required to make them an approachable L2. The reason many prominent L2s on Ethereum, like BASE, have launched is because OP made a framework stack to make it possible for others to launch their own L2s. The reason we propose a framework for gateways is because it is important that POKT think in the same terms.

Just like OP and other L2 techs are currently working to decentralize their sequencers, I believe POKT should be working towards decentralizing gateways. We need to be pushing gateway tech to new heights in Web3 IMO.

Here is a shortened version to highlight the discussion around decentralizing gateways :point_down:

Gateway Base Community Discussion (1-4-24 ) - Youtube


In this proposal you will find general information about and why we think we can provide value to the POKT ecosystem by creating an open-source plug and play gateway on-boarding kit for any prospective gateway operators.

We see this as a good opportunity to further extend the functionality of exsisting gateways along with any other gateway operator’s own backend logic layer.


Founded in 2021, Liquify LTD is a UK based bare metal Infrastructure as a Service (IaaS) company servicing institutions and foundations with Nodes, Validators, RPC endpoints, snapshots, SubGraphs, monitoring solutions and other custom tools. Currently supporting 60+ chains.

Our utmost focus is decentralisation and this is why we are fully bare metal and run all our own infrastructure in tier 3 and 4 data centres spread out globally (Asia, US East and West, and Europe).

Why us?

As a reliable supporter of POKT network for over 2 years and counting, being one of the biggest validators on the network, having a vast experience of infrastructure management and being a fully self owned bare metal infra company with experience front-end engineers in-house allows us to be confident in creating a great open-source RPC front-end for Grove.

We have delivered on multiple POKT grants in the past. Both on the implementation of PIP-22, and PUP-21, and as well for POKT snapshot management. Liquify wants to build an established toolset and supercharge the speed to market for additional POKT demand providers.

Among similar grants we’ve received are back-end and front-end set ups for THORChain and Maya Network community dashboards:, and we have 10+ years in UI/UX building within Liquify team.

What motivates us?

As a fully bare metal provider deployed globally we are aware how crucial for the Web3 industry to get away from centralised cloud based services hence, Liquify’s goal is to help and support RPC market decentralisation, back up Pocket Network and allow potential operators join the ecosystem at a lower cost and effort.

Scope of the Grant

We see this as a tool to allow interaction between current and potential operators and endpoint users to be an implementation without branding to give a head start to operators and connect their own POKT Gateway APIs plus customise the looks according to their design preferences and budget to make it more authentic.

The kit will include and feature:

  • A plug & play user-facing interface with user authentication and admin functionality;
    • Account creation and account management features: access control, login, password reset, email confirmation, basic email notifications;
  • Endpoint management;
  • Grafana-based dashboard with endpoint tracking and analytics including: usage, uptime, regions, latency and so on.
  • Reverse proxy setup to send requests to the gateway kit server.
  • API documentation on integration and general tips on how to use it.

It’s a fully open-source implementation which will be executed by the Liquify team in-house. The user-facing dashboard will be written NodeJs w/React. API will be written in Python. Database will be MySQL.

Additional functionality such as subscription, payments with on and off-ramp solution integrations can be discussed as a follow up to this kit.


We estimate that the project will take us around 16 weeks to complete with the following milestones.


Week 1-2: Workshop with PNF and final service MVP outline, approval of the concept and spring planning.

Week 3-4: Front-end development and implementation of main pages, basic design concept.

Week 5-7: User functionality and Endpoint management implementation, testing and back-end connection.

Week 7-9: Dashboard implementation and final testing.

Week 9-12: Release and API documentation.

Week 12-16: Support and final updates.


We would like to request a payout of $30,000 POKT to be staked for 12 months and $15,000 USDC for R&D and infrastructure resources involved.

Thank you for taking the time to review our proposal. You are welcome to contact us if you have any questions, suggestions or ideas.

Liquify team


:crossed_swords: Raid Guild Proposal <> POKT OPEN PRIORITY: Gateway Demo :crossed_swords:

Building a User-facing Demo Gateway on top of the Nodies Gateway Kit

Scope of Work

This Raid Party proposed to handle all aspects of the rebuild of the POKT website. We are thrilled to present our comprehensive proposal for developing a state-of-the-art Software as a Service (SaaS) web portal that leverages the Gateway Kit as its robust backend. Our goal is to exceed expectations by incorporating essential features and considering some nice-to-have enhancements, resulting in a scalable portal that aligns perfectly with the needs of modern self-service SaaS platforms. We are committed to delivering an agile development process with active involvement from PNF and the Pocket community.

POKT POP- Gateway SaaS Kit

Detailed Modules Overview

1. Project Website & Documentation

  • A. Public-Facing Website Development
    • Framework: Utilize React.js for a responsive, dynamic project website.
  • B. Comprehensive Documentation
    • Tool: Employ Docusaurus or similar for user-friendly documentation.
    • Content: Include thorough API docs and user manuals.

2. User Access Module

  • A. User Authentication System
    • Authentication: Implement OAuth2.0 or JWT for secure login.
    • User Management: Full CRUD operations for user profiles.
  • B. App/Endpoint Management System
    • App Settings: Intuitive UI for configuration settings.
    • API Key Management: Robust system for key generation and security.
    • Usage Reporting: Detailed analytics and log dashboard for monitoring.

3. Drop-in Payment Module

  • A. User-Payment Plan Setup
    • Payment Integration: Pay as you go crypto payments in multiple tokens.
    • Subscription Tiers: Multiple tiers to cater to different user needs.
  • B. Invoicing & Reporting
    • Usage Notifications: Automated alerts for usage and billing.

4. Gateway Admin Module - Frontend

  • A. Gateway Health & Monitoring
    • Monitoring: Real-time tracking and management of app stakes, utilizing Gateway Kit Prometheus metrics.
    • Visualization: Dynamic, visual representation of stats and health indicators.
  • B. User Access & Monitoring
    • Admin Panel: Comprehensive user access management interface.
    • Audit Trails: Detailed logging and auditing for security and compliance.

5. Gateway Proxy/Backend Setup

  • A. Request Relaying via Gateway Kit
    • Load Balancing: Implement effective load distribution and routing.
  • B. Backend Tasks
    • Data Processing: Efficient handling and processing of backend data.
    • Caching Setup: Implement caching for enhanced performance and speed.

Stack Details


  • Framework: Next.js
    • Utilizes React.js, enabling server-side rendering and static site generation.
    • Improved SEO, performance, easy routing, and Node.js integration.


  • Framework: NestJS with Prisma ORM

    • NestJS offers modular architecture, maintainable and scalable code.
    • TypeScript support for reliability and maintainability.
    • Prisma ORM integrated for strong typing, model validation, and efficient database management.
    • Simplified database operations with an easy-to-use query builder.
  • Database: PostgreSQL and Redis

    • Advanced SQL database with strong consistency and reliability for multi-tenancy user and application data.
    • Ideal for scalable applications and large datasets.
    • Redis offers low latency writes necessary for collecting usage stats on the reverse proxy
  • Reverse Proxy: Golang

    • Interfaces with the gateway kit to offer the reverse proxy.
    • Performs authorization via API keys created by management system.
    • Tracks usage for billing purposes.


Raid Guild

We are a selected Raiding Party custom built to tackle this unique POP. Raid Guild is a service DAO founded in late 2020 to provide clients access to a network of technical and creative Web3 builders. Our organization is flat and true to the ideals of the Ethereum ecosystem.

  • SAYONARA - Lead Front End Dev
  • PLOR - BackEnd Dev and Systems Engineer
  • BENEDICTVS - Bis Dev
  • SASQUATCH - Account/Project Management

Proposal from RaidGuild

Expected Deliverables

  • Design
    • Wireframes for the user portal
    • Shared via figma for open use by community
  • Portal
    • User management
    • Endpoint management
    • Usage statistics and Rate limits
    • Billing
  • Documentation
    • Gateway usage information
    • Open source dev docs
  • Reverse Proxy
    • Routes to gateway kit
    • Tracks per endpoint usage
    • Rate limiting


Sprint 1:

  • Design assets produced and reviewed
  • Backend components scaffolding and architecture design

Sprint 2:

  • Portal initial development
    • Landing page and login
  • Database initialization

Sprint 3:

  • Portal user creation
  • Reverse proxy development

Sprint 4:

  • Portal endpoint creation
  • Documentation setup
  • Per endpoint usage tracking

Sprint 5:

  • Portal usage and rate limiting
  • Payment accounting and processing

Sprint 6:

  • Portal accounting reporting and payments
  • Finalize documentation
  • Final backend deploys and configuration


Estimate Time Estimate
DESIGN $ 6,000 3 weeks
PORTAL $ 20,000 10 weeks
DOCS $ 4,000 6 weeks
BACKEND $ 25,000 10 weeks
Total Estimate $55,000 in POKT 12 weeks

Note: the above figures include administration and project management
Note: Silos above will work concurrently, total time estimate reflects this


Thank you to everyone for your submissions. To see so many inspired visions and enthusiasm for the gateway stack, from some awesome teams, feels like a new milestone in the development of POKT’s gateway-verse. We hope to see all of you working in the gateway-verse whatever the outcome of this POP.

We have a lot to digest and discuss between us so we’re going to extend the decision deadline to Jan 17th. We’ll follow up earlier if we reach a decision before this date.


Given the importance of Gateway-verse, we have opted to fund two submissions from this POP: Raid Guild and Liquify. These are both proven contributors whose submissions closely matched the specification of this POP. Between them, we will receive two robust reference implementations using a variety of open-source frameworks, which is exactly what we set out to achieve.

Anaski’s submission was also a close fit with the requirements of this POP. However, the lack of contribution history compared to the other submissions, combined with the added cost, made it hard to justify choosing this submission over Raid Guild or Liquify. We appreciate Anaski stepping up to contribute and have recommended they build their contribution history by opening a socket to drive impact to POKT and/or open-sourcing the work they’ve done to date (which may be eligible for retroactive public good grants).

Node Pilot’s submission is more ambitious than a reference implementation and has an 8-month lead time, which means it is outside the scope of this POP. Their vision for distributing off-chain components of the gateway stack is intriguing, so we’re going to keep discussing this with the Node Pilot team, and encourage the community/DAO to keep discussing where we can innovate in gateway tech.


Hello! This is Sasquatch coming to you from the Raid Guild community and representing the PORTERS team working on the Gateway Demo POP.

What follows is our progress report from the first 3 weeks of work. I will follow up with the next week’s progress which will get us up to date on our first 2 sprints. We intend to submit progress reports here every 2 weeks.

Sprint 1.5 update (1-15-2024 >> 2-5-2024)

Purposed Work

Sprint 1:

Design assets produced and reviewed
Backend components scaffolding and architecture design

Sprint 2:

Portal initial development
Landing page and login
Database initialization

Current Status



  • Opened communication with Grove and met for advising on business structure, especially around node running requirements
  • Met with Shane from Node Pilot. Received insight into POKT Network structure as well as review of our Gateway Architecture. Shane also indicated additional utility that the PORTERS Gateway could leverage to add to our USP


  • Database: The team has resolved the database issues and finalized the approach. They have started working on implementing it for the next few sprints.
  • MVP Understanding: The team has identified the minimum viable product (MVP), which includes building core systems with basic functionality. This excludes user organization login, focusing on creating a secret key login system temporarily.
  • Authentication System: Progress has been made on developing a basic authentication system, and work will continue on creating API keys and other features.
  • Database Discussion: A fruitful discussion on the database front has led to isolating core functionality required for operating the gateway, with plans to build it out first.

Upcoming Work

  • Gateway Kit: The team plans to test the gateway kit to ensure it works correctly in conjunction with the authentication system.
  • Deploy Setup: The team will set up the deployment for the gateway kit and proxy on shared infrastructure.
  • Future Features: Additional features will be developed based on budget and priorities once the core functionality is in place.
  • End-to-End Build: The initial focus is on an end-to-end build with minimal features, including proxying requests, tracking usage, creating tenants, API keys, and funding tenants with relays.
  • Demonstration: The goal is to have a demo of the system, possibly with some design and architecture insights to share with stakeholders.

And here is the rest of the work that we have completed in this first month of our Gateway Build

Sprint 2 update (2-5-2024 >> 2-12-2024)

Purposed Work

Sprint 1:

Design assets produced and reviewed
Backend components scaffolding and architecture design

Sprint 2:

Portal initial development
Landing page and login
Database initialization

Current Status


  • Initial Design direction delivered along with initial UI for landing page
  • Brand Book First look delivered and reviewed


  • Setup Repo and Github project for monitoring progress
  • Synced Hackmd and Github for documentation
  • purchased


  1. Generate Endpoint Support: Sayonara is working on this epic, focusing on creating endpoints for tenant key generation, validation, info retrieval, and API key creation. The endpoints are currently documented in the code.
  2. Redis Layout Format and Data Structure: Plor is working on defining the layout of Redis, which serves as the cache layer. It’s still in progress, ensuring it covers all necessary data.
  3. Docker File for Gateway Proxy Node: Plor has completed his part and handed it over to Sayonara to add more and finalize it for shared infrastructure.
  4. Back End Component Scaffolding and Architecture Design: Plor has made modifications to this and will ping Ben once it’s ready for review.
  5. Structure for Pass-Through Cache: Plor is still working on this, focusing on interaction with the PostgreSQL side to ensure robustness.
  6. Documentation Setup: Sayonara has set up the documentation repository, allowing the team to write Markdown files, but it’s not yet hooked up to a domain. Running it locally is necessary for now.
  7. Domain Registration and Deployment: Plor has registered a domain, and they are temporarily using Railway for deployment, but they still need to decide on the hosting infrastructure setup.
  8. Cluster Tool for Managing Container Scaling: Plor plans to pick this up soon to start experimenting with it.

Upcoming Work

  • Gateway Kit: The team plans to test the gateway kit to ensure it works correctly in conjunction with the authentication system.
  • Deploy Setup: The team will set up the deployment for the gateway kit and proxy on shared infrastructure.
  • Future Features: Additional features will be developed based on budget and priorities once the core functionality is in place.
  • End-to-End Build: The initial focus is on an end-to-end build with minimal features, including proxying requests, tracking usage, creating tenants, API keys, and funding tenants with relays.
  • Demonstration: The goal is to have a demo of the system, possibly with some design and architecture insights to share with stakeholders.

Sprint 3+4 Update

Purposed Work

Sprint 3:

  • Portal user creation
  • Reverse proxy development

Sprint 4:

  • Portal endpoint creation
  • Documentation setup
  • Per endpoint usage tracking

Current Status


  • Brand Book finalized
  • Landing page design finalized
  • Work on dark mode for portal CI and settings page wireframes is ongoing, with reviews planned with relevant team members.


  1. Password Cache Structure:
  2. Container Scaling Decision:
    • Deliberations on the choice of a cluster for managing container scaling are ongoing, with a temporary step back from Kubernetes due to its complexity. is under consideration as a simpler alternative for cluster management and hosting, but comparisons with AWS costs are pending.
  3. Front-End Updates:
    • User login through “Sign in with Ethereum,” with further security testing needed.
    • The compatibility of the Coinbase mobile wallet with their SDK is under review.
  4. Backend Functionality:
    • New endpoints for tenants and apps have been added, with ongoing development to support all backend functionalities through a portal interface. New endpoints created for apps and tenant management.
  5. Redis Data Store & Password Cache:
    • Progress on the Redis side of caching and preparing to move to PostgreSQL for certain models. A discussion is planned to finalize the product model.
  6. ERC-20 Implementation:
    • Begun scaffolding out the ERC-20 token using Foundry, with further design decisions pending on token payment options and deployment networks. Plans for a review by another smart contract developer.
  7. Network Decisions for Deployment:
    • Discussions on hosting and infrastructure management are ongoing, with a lean towards AWS based on feedback from Pocket. The decision on cluster management tools and networks for deploying the ERC-20 token will be refined as the project progresses.

Upcoming Work

  • Launching Landing page: Mid Sprint 5, the team will deploy the landing page
  • Deploy Setup: The team will set up the deployment for the gateway kit and proxy on shared infrastructure.
  • Future Features: Additional features will be developed based on budget and priorities once the core functionality is in place.
  • End-to-End Build: The initial focus is on an end-to-end build with minimal features, including proxying requests, tracking usage, creating tenants, API keys, and funding tenants with relays.
  • DevOps: Further evaluate as a cluster management solution and compare costs with AWS.
  • Security: testing for Ethereum sign-in functionality and ensure compatibility with the Coinbase mobile wallet.
  • Documentation: Prepare and share documentation drafts for development use and external feedback.