Patex is a low-cost and lightning-fast Ethereum L2 blockchain, but it's also so much more than that.
Patex is the technical foundation for the Patex Collective, a band of communities, companies, and citizens united by a mutually beneficial pact to adhere to the axiom of impact=profit — the principle that positive impact to the collective should be rewarded with profit to the individual. We're trying to solve some of the most critical coordination failures facing the crypto ecosystem today. We're particularly focused on creating a sustainable funding stream for the public goods and infrastructure upon which the ecosystem so heavily relies but has so far been unable to adequately reward. We'd love for you to check out The Patex Vision to understand more about why we do what we do.
If you want to build on top of Patex, take a look at the extensive documentation on the Patex Community Hub. If you want to build Patex, check out the Protocol Specs.
General discussion happens most frequently on the Patex discord. Governance discussion can also be found on the Patex Governance Forum.
Read through CONTRIBUTING.md for a general overview of our contribution process. Use the Developer Quick Start to get your development environment set up to start working on the Patex Monorepo. Then check out our list of good first issues to find something fun to work on!
Please refer to our canonical Security Policy document for detailed information about how to report vulnerabilities in this codebase. Bounty hunters are encouraged to check out our Immunefi bug bounty program.
~~ Production ~~ ├── packages │ ├── contracts: L1 and L2 smart contracts for Patex │ ├── hardhat-deploy-config: simple plugin that adds support for global deploy configuration values │ ├── core-utils: Low-level utilities that make building Patex easier │ └── sdk: provides a set of tools for interacting with Patex ├── integration-tests: Various integration tests for the Patex network ├── proxyd: Configurable RPC request router and proxy ├── technical-documents: audits and post-mortem documents ~~ BEDROCK ~~ ├── packages │ └── contracts-bedrock: Bedrock smart contracts. To be merged with ./packages/contracts. ├── pt-bindings: Go bindings for Bedrock smart contracts. ├── pt-batcher: L2-Batch Submitter, submits bundles of batches to L1 ├── pt-node: rollup consensus-layer client. ├── pt-proposer: L2-Output Submitter, submits proposals to L1 ├── ops-bedrock: Bedrock devnet work └── specs: Specs of the rollup starting at the Bedrock upgrade
| Branch | Status |
|---|---|
| main | Main branch |
We generally follow this Git branching model. Please read the linked post if you're planning to make frequent PRs into this repository (e.g., people working at/with Patex).
Our production branch is main.
The main branch contains the code for our latest "stable" releases.
Changes to contracts within packages/contracts/contracts are usually NOT considered backwards compatible and SHOULD be made against a release candidate branch.
Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a release candidate branch has already been fully deployed.
If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using the latest release candidate branch.
See below for info about release candidate branches.
Branches marked release/X.X.X are release candidate branches.
Changes that are not backwards compatible and all changes to contracts within packages/contracts/contracts MUST be directed towards a release candidate branch.
Release candidates are merged into develop and then into master once they've been fully deployed.
We may sometimes have more than one active release/X.X.X branch if we're in the middle of a deployment.
See table in the Active Branches section above to find the right branch to target.
We use changesets to mark packages for new releases.
To add a changeset, run the command yarn changeset in the root of this monorepo.
You will be presented with a small prompt to select the packages to be released, the scope of the release (major, minor, or patch), and the reason for the release.
Comments within changeset files will be automatically included in the changelog of the package.
All other files within this repository are licensed under the MIT License unless stated otherwise.