add contributing, changelog, security md files

CHANGELOG.md

@@ -0,0 +1,49 @@
+<!--
+Guiding Principles:
+
+Changelogs are for humans, not machines.
+There should be an entry for every single version.
+The same types of changes should be grouped.
+Versions and sections should be linkable.
+The latest version comes first.
+The release date of each version is displayed.
+Mention whether you follow Semantic Versioning (we do at and after v1.0.0).
+
+Usage:
+
+Change log entries are to be added to the Unreleased section
+under the appropriate stanza (see below).
+Each entry should ideally include the Github issue or PR reference.
+
+The issue numbers will later be link-ified during the
+release process so you do not have to worry about including
+a link manually, but you can if you wish.
+
+Types of changes (Stanzas):
+
+* __Added__ for new features.
+* __Changed__ for changes in existing functionality that did not aim to resolve bugs.
+* __Deprecated__ for soon-to-be removed features.
+* __Removed__ for now removed features.
+* __Fixed__ for any bug fixes that did not threaten user funds or chain continuity.
+* __Security__ for any bug fixes that did threaten user funds or chain continuity.
+
+Breaking changes affecting client, API, and state should be mentioned in the release notes.
+
+Ref: https://keepachangelog.com/en/1.0.0/
+Ref: https://github.com/osmosis-labs/osmosis/blob/main/CHANGELOG.md
+-->
+
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) for all versions `v1.0.0` and beyond (still considered experimental prior to v1.0.0).
+
+## [Unreleased]
+
+## v0.1.0
+
+*Initial release.*
+

CONTRIBUTING.md

@@ -0,0 +1,47 @@
+# Contribution Guidelines
+
+*Borrowed from Osmosis's [contribution guidelines](https://github.com/osmosis-labs/osmosis/blob/main/CONTRIBUTING.md)*
+
+Any contribution that you make to this repository will
+be under the Apache 2 License, as dictated by that
+[license](http://www.apache.org/licenses/LICENSE-2.0.html):
+
+~~~
+5. Submission of Contributions. Unless You explicitly state otherwise,
+   any Contribution intentionally submitted for inclusion in the Work
+   by You to the Licensor shall be under the terms and conditions of
+   this License, without any additional terms or conditions.
+   Notwithstanding the above, nothing herein shall supersede or modify
+   the terms of any separate license agreement you may have executed
+   with Licensor regarding such Contributions.
+~~~
+
+Contributors must sign-off each commit by adding a `Signed-off-by: ...`
+line to commit messages to certify that they have the right to submit
+the code they are contributing to the project according to the
+[Developer Certificate of Origin (DCO)](https://developercertificate.org/).
+
+# General Style
+
+We follow a hexagonal/"ports and adapters" architecture. This means that the domain layer is decoupled from the implementation details of the adapters and the ports. This allows for a more modular and testable codebase.
+
+# General Philosophy
+
+Allora producer is meant to be used by any consumer of Allora chain events. These may include forecasters, who will use the events to inform their forecasting models. It may also include other services, indexing, cached RPC endpoint, or monitoring tools. However, the producer is not meant to directly support all possible consumers, but rather to provide a standardized way to parse and relay events on Allora chain. We focus on data production here, not data consumption.
+
+Thus, it's important to keep the general applicability of this repo in mind, and to avoid adding convenience methods or making the codebase more opinionated for specific consumers.
+
+# Standard Domain Event Format
+
+We have defined a standard format for domain events that are emitted by modules. This allows for a more consistent and predictable way to handle events in the codebase, and allows for easier parsing of events by consumers and maximally general event handlers.
+
+### Example
+
+```go
+Message{
+   ID:        "0x" + hex.EncodeToString(hash[:]),
+   Type:      msgType,
+   Name:      name,
+   Timestamp: time.Now().UTC(),
+}
+```

SECURITY.md

@@ -0,0 +1,72 @@
+# Security Policy
+
+## Introduction
+
+Security researchers are essential in identifying vulnerabilities that may impact the Allora ecosystem. If you have discovered a security vulnerability in the Allora chain or any repository managed by Allora, we encourage you to notify us using one of the methods outlined below.
+
+### Guidelines for Responsible Vulnerability Testing and Reporting
+
+1. **Refrain from testing vulnerabilities on our publicly accessible environments**, including but not limited to:
+  - Allora mainnet
+  - any Allora-affiliated frontends e.g. allora.network, alloralabs.xyz
+  - Allora public testnets
+  - Allora testnet frontend
+
+2. **Avoid reporting security vulnerabilities through public channels, including GitHub issues**
+
+## Reporting Security Issues
+
+To privately report a security vulnerability, please choose one of the following options:
+
+### 1. Email
+
+Send your detailed vulnerability report to `[email protected]`.
+
+### 2. GitHub Private Vulnerability Reporting
+
+Utilize [GitHub's Private Vulnerability Reporting](https://github.com/allora-network/allora-chain/security/advisories/new) for confidential disclosure.
+
+## Submit Vulnerability Report
+
+When reporting a vulnerability through either method, please include the following details to aid in our assessment:
+
+- Type of vulnerability
+- Description of the vulnerability
+- Steps to reproduce the issue
+- Impact of the issue
+- Explanation of how an attacker could exploit it
+
+## Vulnerability Disclosure Process
+
+1. **Initial Report**: Submit the vulnerability via one of the above channels.
+2. **Confirmation**: We will confirm receipt of your report within 48 hours.
+3. **Assessment**: Our security team will evaluate the vulnerability and inform you of its severity and the estimated time frame for resolution.
+4. **Resolution**: Once fixed, you will be contacted to verify the solution.
+5. **Public Disclosure**: Details of the vulnerability may be publicly disclosed after ensuring it poses no further risk.
+
+During the vulnerability disclosure process, we ask security researchers to keep vulnerabilities and communications around vulnerability submissions private and confidential until a patch is developed. Should a security issue require a network upgrade, additional time may be needed to raise a governance proposal and complete the upgrade.
+
+During this time:
+
+- Avoid exploiting any vulnerabilities you discover.
+- Demonstrate good faith by not disrupting or degrading Allora's services.
+
+## Severity Characterization
+
+| Severity     | Description                                                             |
+| ------------ | ----------------------------------------------------------------------- |
+| **CRITICAL** | Immediate threat to critical systems (e.g., chain halts, funds at risk) |
+| **HIGH**     | Significant impact on major functionality                               |
+| **MEDIUM**   | Impacts minor features or exposes non-sensitive data                    |
+| **LOW**      | Minimal impact                                                          |
+
+## Bug Bounty
+
+Though we don't have an official bug bounty program, we generally offer rewards to security researchers who responsibly disclose vulnerabilities to us. Bounties are generally awarded for vulnerabilities classified as **high** or **critical** severity. Bounty amounts will be determined during the disclosure process, after the severity has been assessed. Please note that in order to collect a bounty, the reporter must go through a KYC process.
+
+> [!WARNING] 
+> Targeting our production environments will disqualify you from receiving any bounty.
+
+## Feedback on this Policy
+
+For recommendations on how to improve this policy, either submit a pull request or send an email to `[email protected]`.