diff --git a/POP_proposal.md b/POP_proposal.md new file mode 100644 index 00000000..fa05d2e6 --- /dev/null +++ b/POP_proposal.md @@ -0,0 +1,138 @@ +# POKT Gateway Demo + +Work related to https://forum.pokt.network/t/open-priority-gateway-demo/4874 + +## Proposal + +### ⚔️ Raid Guild Proposal <> POKT OPEN PRIORITY: Gateway Demo ⚔️ + +> 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 + +##### Frontend +- **Framework**: Next.js + - Utilizes React.js, enabling server-side rendering and static site generation. + - Improved SEO, performance, easy routing, and Node.js integration. + +##### Backend +- **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. + + +##### TEAM +###### [Raid Guild](https://www.raidguild.org/portfolio) +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 + + +##### **Milestones** +--- +###### 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 diff --git a/README.md b/README.md index fa05d2e6..82ead398 100644 --- a/README.md +++ b/README.md @@ -1,138 +1,58 @@ -# POKT Gateway Demo - -Work related to https://forum.pokt.network/t/open-priority-gateway-demo/4874 - -## Proposal - -### ⚔️ Raid Guild Proposal <> POKT OPEN PRIORITY: Gateway Demo ⚔️ - -> 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 - -##### Frontend -- **Framework**: Next.js - - Utilizes React.js, enabling server-side rendering and static site generation. - - Improved SEO, performance, easy routing, and Node.js integration. - -##### Backend -- **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. - - -##### TEAM -###### [Raid Guild](https://www.raidguild.org/portfolio) -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 - - -##### **Milestones** ---- -###### 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 +# PORTERS POKT RPC Gateway + +## Table of Contents + +## Background + +- Gateway Kit +- POKT +- Sign-in-with-Ethereum + +### Dependencies + +- Postgres +- Prisma +- Prometheus + +## Requirements + +The PORTERS POKT RPC Gateway is build using **golang** for proxy, **javascript** for the frontend and backend. The portal, consisting of frontend and backend, requires **node.js** and you may follow our implementation design by using ```pnpm``` for package management, however, you may use other package managers if you desire. + +## Install + +- required environment variables + - db pw, etc. + - .env +- docker compose + +## Build + +- allow for short iterations +- split up descriptions into components + +See the [just file](/gateway-demo/justfile) for further information. You can run the just commands to see which components you can run how. + +- JUST file descriptions + - ``` just built``` + - top level vs component-specific +- include a definition of how one can contribute to it + +## Usage + +Once you installed the PORTERS POKT RPC Gateway, you can use the PORTERS portal for generating RPC endpoints. + +- Plor will think about this section as the portal is kind of counterintuitive + +In the proxy is the file ```main.go``` that is used for configuration. It allows you to configure rate limiting and other core functionalities of an RPC service. + +## Contribute + +We welcome contributions from outside contributors. For contributing, please fork the repository and open a pull request with the proposed changes. + +All contributions shall be made to the ```develop``` branch. Contributions may then be merged into ```master```. + +In the future, more stringent contribution rules may be put in place at the sole descretion of the PORTERS core team. + +## Licence + +- MIT Licence \ No newline at end of file diff --git a/docs/.gitignore b/docs/.gitignore index fd3dbb57..6d333829 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -5,6 +5,7 @@ /.pnp .pnp.js .yarn/install-state.gz +package-lock.json # testing /coverage diff --git a/docs/pages/Architecture_Overview.mdx b/docs/pages/Architecture_Overview.mdx deleted file mode 100644 index 463e90c3..00000000 --- a/docs/pages/Architecture_Overview.mdx +++ /dev/null @@ -1,6 +0,0 @@ -# Overview of RPC Gateway Architecture - -## Architecture Diagram - - -FINAL_PORTERS_Architecture diff --git a/docs/pages/For_Contributors/0_for_devs_index.mdx b/docs/pages/For_Contributors/0_for_devs_index.mdx new file mode 100644 index 00000000..a3365c19 --- /dev/null +++ b/docs/pages/For_Contributors/0_for_devs_index.mdx @@ -0,0 +1,18 @@ +# Overview of the Contributor Documentation + +This section of the documentation contains the following. First a brief overview of the architecture is given. Then, in sections two and three the frontend and backend of the portal are described. Fourth, the gateway (or proxy) is documented. Fifth, the gateway kit is described. Thereafter the schema is described, documenting the interation between the backend and the proxy. Seventh, the documentation describes the smart contract payment infrastructure. Lastly, this documentation covers the POKT integration. + +For documentation on PORTERS PORTALS please refer to the [PORTAL section](/gateway-demo/docs/pages/PORTALS/0-PORTALS-index.mdx) of this documentation. + +## Table of Contents + +1. Architecture +2. Frontend +3. Backend +4. Gateway (Proxy) +5. Gateway Kit +6. Schema +7. Smart Contract Payment Infrastructure +8. POKT Integration + + diff --git a/docs/pages/For_Contributors/10_Redis.mdx b/docs/pages/For_Contributors/10_Redis.mdx new file mode 100644 index 00000000..56324c71 --- /dev/null +++ b/docs/pages/For_Contributors/10_Redis.mdx @@ -0,0 +1,10 @@ +# Redis Data Store + +The Redis data store is located between the gateway and the postgres server. Thus, it is a local cache for the information described in the schema. + +It is important to note that there is one postgress instance, but one Redis instance per region, so that there is a local copy that can be quickly read or written. + +Due to this setup individual Redis instances may differ, but are synced eventually. This is achieved because the only write of the Redis data store to the postgres instance is `append only`. Hence, no conflicts are possible. + +For example, given two users of the same app are in two regions, they both will be accessing different Redis instances. However, their usage will be reflected in the postgres instance eventually. + diff --git a/docs/pages/For_Contributors/1_Architecture_Overview.mdx b/docs/pages/For_Contributors/1_Architecture_Overview.mdx new file mode 100644 index 00000000..f3c40837 --- /dev/null +++ b/docs/pages/For_Contributors/1_Architecture_Overview.mdx @@ -0,0 +1,24 @@ +# Overview of RPC Gateway Architecture + +A few changes to the initial architectures are needed. + +- some services are external that were initially conceptualised as internal +- changes to the payment infrastructure +- the data flow should be described + +Generally the data flows from the frontend to the backend and then to the schema. + +The frontend and the backend manage access to accounts for setting up the database. A redis database primarily caches postgres calls, but also usage is being cached and is being updated in chunks to the postgress database. + +- future enhancement may include a flow chart +- postgress is the canonical data store for all bits +- frontend calls the backend, which in turn alters the postgres for configuring the proxy + +- smart contracts are burning tokens +- event watcher for looking for these events and updating the account + +## Architecture Diagram + +![](/FINAL_PORTERS_Architecture.png) + +For further details on the architecture and data flow, refer to the diagram above. diff --git a/docs/pages/For_Contributors/2_Frontend.mdx b/docs/pages/For_Contributors/2_Frontend.mdx new file mode 100644 index 00000000..1c9af459 --- /dev/null +++ b/docs/pages/For_Contributors/2_Frontend.mdx @@ -0,0 +1,45 @@ +# Frontend Documentation + +## Introduction + +This document provides an overview of the frontend architecture and technologies used in the PORTERS portal. + +## Framework and Libraries + +- **Next.js**: Used as the frontend framework. +- **Mantine**: UI library for components. +- **Connect Kit**: For Sign-in-with-Ethereum functionality. +- **WAGMI**: Connects the frontend to the blockchain. +- **Jotai and Tanstack Query**: For state management. +- **@react-pdf/renderer**: For generating invoices. + +## Folder Structure + +- **Pages**: Uses next.js pages router, each page resides in its respective directory `[pageName]/index.tsx`. +- **Components**: Reusable components reside in `components/[pageFolder]/...components.tsx`. + +## Functionality + +- **Sign-in-with-Ethereum**: Handled by Connect Kit, which validates sessions using the `/siwe` endpoint on backend. +- **Blockchain Integration**: WAGMI is used for connecting frontend to the blockchain. +- **State Management**: Jotai and Tanstack Query are used for managing state. +- **Fetching Data**: Tanstack Query is used for general fetching. +- **Theming**: Centralized theming in a `theme.ts` file. + +## Integration with Backend + +- **Endpoints**: Frontend calls endpoints on the next.js backend/API, which redirects to the nest.js backend. +- **Swap Feature**: Swapping feature related to payment infrastructure uses 0x. +- **Usage Data**: Backend calls Prometheus for usage data and alerts. + +## Session and User Information + +- **Balances**: Provided from sessions, containing user info such as apps, orgs, enterprises, and tenant ID. +- **Rate Limiting**: Notifications retrieved from the backend by calling Prometheus. +- **Redeeming**: Calls the `applyToAccount` function. + +## Additional Tools + +- **Invoice Generation**: Utilizes `@react-pdf/renderer` for generating invoices. + +For detailed information on each aspect, refer to the relevant sections above. diff --git a/docs/pages/For_Contributors/3_Backend.mdx b/docs/pages/For_Contributors/3_Backend.mdx new file mode 100644 index 00000000..fab331b7 --- /dev/null +++ b/docs/pages/For_Contributors/3_Backend.mdx @@ -0,0 +1,22 @@ +# Backend Documentation + +This document provides an overview of the backend architecture and technologies used in the PORTERS portal. + +## Frameworks and Libraries + +- **Nest.js**: Backend framework. +- **Express.js**: Used underneath Nest.js. +- **Prisma ORM**: Interacts with the PostgreSQL database. + +## Authentication and Authorization + +- **Global Guard**: Authorisation guard is used as a global guard to protect routes. +- **Session Authentication**: Checks whether a session cookie is provided for authorisation. +- **Endpoint Visibility**: Only one endpoint, `\siwe`, is public and marked with a custom decorator `isPublic`. + +## API Documentation + +- **API Specification**: Endpoint documentation and parameter details are available in our [API specification](https://staging.porters.xyz/api/specs). +- **REST Endpoints**: Endpoints follow REST principles and should be self-explanatory. + +For detailed information on each aspect, refer to the relevant sections above. diff --git a/docs/pages/For_Contributors/4_Gateway.mdx b/docs/pages/For_Contributors/4_Gateway.mdx new file mode 100644 index 00000000..ae25cd10 --- /dev/null +++ b/docs/pages/For_Contributors/4_Gateway.mdx @@ -0,0 +1,38 @@ +# Gateway Documentation + +This document provides an overview of the gateway architecture and functionality used in the PORTERS portal. + +## Overview + +The gateway primarily relies on the `[net/http](https://pkg.go.dev/net/http)` library and its `ReverseProxy` functionality. +Requests are handled by `[gorilla/mux](https://github.com/gorilla/mux)`, mapping paths to the reverse proxy. + +## Reverse Proxy and Middleware + +Inside the reverse proxy, middleware runs and hosts logic for allowing or denying requests in addition to modifying aspects of the request (headers, error codes, etc). +These middleware plugins are inserted into the request lifecycle, implementing rules for proxying or rejecting requests. +Contributors can start by exploring plugins located in the **plugins** package. + +## Plugins Package + +The `main.go` file configures the server and allows adding plugins. Contributors can add new logic by providing new plugins. +These plugins are essential for customizing gateway behavior. + +## Database Package + +The `db` package contains logic for interactions between Redis and PostgreSQL, handling data storage and retrieval. + +## Utils Package + +The `utils` package consists of small utility packages, providing helper functions and tools for various tasks. + +## Commons Package + +The `commons` package includes Prometheus metrics and configuration files essential for gateway operations. + +## Lifecycle Management + +The concept of the lifecycle, where each stage must be fulfilled by a plugin for the request to be considered valid. +This concept guides the development and integration of plugins into the gateway architecture. + +For more detailed information on each aspect, refer to the corresponding sections above. diff --git a/docs/pages/For_Contributors/5_Gateway-Kit.mdx b/docs/pages/For_Contributors/5_Gateway-Kit.mdx new file mode 100644 index 00000000..2e988572 --- /dev/null +++ b/docs/pages/For_Contributors/5_Gateway-Kit.mdx @@ -0,0 +1,15 @@ +# Gateway Kit + +## Introduction + +This page documents our usage of the gateway kit. More thorough documentation is available at the [Gateway Kit documentation](). + +## Description of our implementation + +We are proxing to the Gateway Kit. The Gateway Kit, in turn coordinates traffic with the POKT Network, i.e. selecting nodes to route traffic to based on the alocated [app stakes](). The private keys from the app stakes are imported to the Gateway Kit, which distributes POKT-specific traffic among the staked nodes according to the app stakes, latency, and available nodes. + +Furthermore, the gateway kit manages the quality of services and the pool of nodes on the POKT network. In short, it tracks connections between app stakes and nodes and distributes traffic among them. + +## Our usage + +We included a Docker image of the gateway kit and included it in our repository. Thus, the gateway kit is not built from source. diff --git a/docs/pages/For_Contributors/6_Schema.mdx b/docs/pages/For_Contributors/6_Schema.mdx new file mode 100644 index 00000000..afae543e --- /dev/null +++ b/docs/pages/For_Contributors/6_Schema.mdx @@ -0,0 +1,36 @@ +# Postgres Schema + +## Description + +It is the contract layer between the gateway and the portal. Any change to the schema must be coordinated between the portal and the gateway. It is a shared component between the portal and the gateway, as such connecting the two components. + +Schemas are managed by **Prisma object relational model (ORM)**. It allows to generate object models for the schemas. + +## Functionality + +The schema consists of several tables. Tables contain a partition. There are portal-specific tables and some tables are shared between the gateway and the portal. Tables that are not interfacing with the gateway are frontend-specific. + +### Shared Tables + +- tenant table, managed by the portal + - stores and tracks the balance +- app(lication) table, managed by the portal +- app rule table, managed by the portal +- payment ledger, updated and managed by the watcher +- relay ledger, updated by the gateway +- product table, it is a look up table + - contains the supported chains, but generalises + - maps the chain name to an identifier + - enables per product usage tracking +- rule-type table, a look up table + - describes the available rules + - it is used inconsequentially by the gateway + +### Portal-only Tables + +- user table, stores user and session information, as well as governing permissions +- org(anisation) table, currently not used, but allows for scalability in the future +- enterprise table, for future use + - an enterprise can have many tenants and many organisation + - organisations and tenants under an enterprise can autonomously manage balances +- user-org mapping is contained in another table diff --git a/docs/pages/For_Contributors/7_Smart_Contracts_Payments.mdx b/docs/pages/For_Contributors/7_Smart_Contracts_Payments.mdx new file mode 100644 index 00000000..241102cf --- /dev/null +++ b/docs/pages/For_Contributors/7_Smart_Contracts_Payments.mdx @@ -0,0 +1,27 @@ +# Smart Contracts + +## ERC-20 Token `PORTR` + +It is a standard ERC-20 smart contract with a few additions, namely: + +- open mint with a fixed price, which is maintained by Chainlink. + - the smart contract on Taiko Mainnet is using PYTH data feed through the Chainlink interface + - it allows for minting by sending the native token as the payable, the rate of which is set by the Chainlink price feed +- admin mint is only called by the owner to mint without having to pay + - this is used for internal usage and enterprise-onboarding +- apply to account function + - initiates a burn and emits an event, which is used to increase the account balance within the gateway +- sweep and sweep token + - allows the operator to withdraw token balances of the contract, both native and ERC-20, sor settling internal accounts + - this enables coverage of POKT relay costs + - it completes the lifecycle of the smart contract + +## PYTH Integration + +The Taiko deployment of the smart contract has a dependency of the PYTH-wrapper for Chainlink. It has been deployed by us, but the code-base is not maintained by PORTERS. The wrapper is then connected to our implementation. + +A [script]() for deploying this wrapper exists and has to be modified for deploying any other price feed. + +## Smart Contract Deployments + +Link Smart Contract Deployments diff --git a/docs/pages/For_Contributors/8_POKT_Integration.mdx b/docs/pages/For_Contributors/8_POKT_Integration.mdx new file mode 100644 index 00000000..2d061eda --- /dev/null +++ b/docs/pages/For_Contributors/8_POKT_Integration.mdx @@ -0,0 +1,18 @@ +# PORTERS Integration with POKT + +We are using a script by Nodies for the app stakes, which can be found [here](). It is a simple node script, which walks you through the app stake process. + +One sets up a file with the private keys for accounts that contain unstaked POKT. The private key goes into the input directory. Then the script is run. + +The inputs are the POKT nodes, which is required to do the RPC calls. + +## Prompts + +- POKT node, URL of the node the script is going to call to +- Chain IDs, a CSV of the chains you intend to stake to. It can be a list of one to fifteen chain IDs +- selector for POKT Mainnet and POKT Testnet +- amount of POKT to stake per account and chain + - mono relays are split across chains + + +Thereafter, the script verifies the prompts. The script then sends the POKT to stake. diff --git a/docs/pages/For_Users/the-portal.mdx b/docs/pages/For_Users/the-portal.mdx new file mode 100644 index 00000000..bdd5fd76 --- /dev/null +++ b/docs/pages/For_Users/the-portal.mdx @@ -0,0 +1,3 @@ +# The PORTERS RPC PORTAL + + diff --git a/docs/pages/PORTALS/0-PORTALS-index.mdx b/docs/pages/PORTALS/0-PORTALS-index.mdx new file mode 100644 index 00000000..e39341aa --- /dev/null +++ b/docs/pages/PORTALS/0-PORTALS-index.mdx @@ -0,0 +1,3 @@ +# PORTALS Documentation + +PORTALS are a way for developers to contribute. This is TBD. \ No newline at end of file diff --git a/docs/pages/_meta.json b/docs/pages/_meta.json index 2c5adf14..d4b6cd7e 100644 --- a/docs/pages/_meta.json +++ b/docs/pages/_meta.json @@ -1,6 +1,5 @@ { "index": "Introduction", - "advanced": "Advanced", "about": { "title": "About", "type": "page" diff --git a/docs/pages/about.mdx b/docs/pages/about.mdx deleted file mode 100644 index b5b20dbe..00000000 --- a/docs/pages/about.mdx +++ /dev/null @@ -1,3 +0,0 @@ -# About - -This is the about page for pokt network open gateway project! This page is shown on the navbar. diff --git a/docs/pages/advanced.mdx b/docs/pages/advanced.mdx deleted file mode 100644 index a1a5148e..00000000 --- a/docs/pages/advanced.mdx +++ /dev/null @@ -1,3 +0,0 @@ -# Advanced - -This is the index page for the Advanced folder! diff --git a/docs/pages/advanced/satori.mdx b/docs/pages/advanced/satori.mdx deleted file mode 100644 index 46eb19fd..00000000 --- a/docs/pages/advanced/satori.mdx +++ /dev/null @@ -1,3 +0,0 @@ -# Satori - -Satori (悟り) is a Japanese Buddhist term for awakening, "comprehension; understanding". diff --git a/docs/pages/index.mdx b/docs/pages/index.mdx index 1b86ff0e..b5114a56 100644 --- a/docs/pages/index.mdx +++ b/docs/pages/index.mdx @@ -1,11 +1,7 @@ # Introduction - -Welcome to Pokt Open Gateway Demo Project! More Documentation incoming. -## What is POKT Open Gateway? +Welcome to Porters RPC Gateway! -An **Open-source**, **Gateway** **Implementation** for POKT network. - -## Documentation +## What is Porters RPC Gateway? -Documentation Forked from [https://nextra.site](https://nextra.site). +An **Open-source**, **Gateway** **Implementation** for POKT network. diff --git a/docs/public/2024-02-13_PORTERS_Architecture.png b/docs/public/2024-02-13_PORTERS_Architecture.png new file mode 100644 index 00000000..d9ccf683 Binary files /dev/null and b/docs/public/2024-02-13_PORTERS_Architecture.png differ diff --git a/docs/public/FINAL_PORTERS_Architecture.png b/docs/public/FINAL_PORTERS_Architecture.png new file mode 100644 index 00000000..5e933a7e Binary files /dev/null and b/docs/public/FINAL_PORTERS_Architecture.png differ diff --git a/docs/theme.config.tsx b/docs/theme.config.tsx index 646d7995..b17b6e79 100644 --- a/docs/theme.config.tsx +++ b/docs/theme.config.tsx @@ -2,7 +2,7 @@ import React from "react"; import { DocsThemeConfig } from "nextra-theme-docs"; const config: DocsThemeConfig = { - logo: Open Gateway, + logo: Porters RPC Gateway, project: { link: "https://github.com/porters-xyz/gateway-demo/", },