diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
new file mode 100644
index 00000000000..5c7b6e81a1f
--- /dev/null
+++ b/.github/CONTRIBUTING.md
@@ -0,0 +1,25 @@
+# Welcome to MetaMask!
+
+If you're submitting code to MetaMask, there are some simple things we'd appreciate you doing to help us stay organized!
+
+### Finding the right project
+
+Before taking the time to code and implement something, feel free to open an issue and discuss it! There may even be an issue already open, and together we may come up with a specific strategy before you take your precious time to write code.
+
+There are also plenty of open issues we'd love help with. Search the [`good first issue`](https://github.com/MetaMask/metamask-mobile/contribute) label, or head to Gitcoin and earn ETH for completing projects we've posted bounties on.
+
+If you're picking up a bounty or an existing issue, feel free to ask clarifying questions on the issue as you go about your work.
+
+### Submitting a pull request
+When you're done with your project / bugfix / feature and ready to submit a PR, there are a couple guidelines we ask you to follow:
+
+- [ ] **Make sure you followed our [`coding guidelines`](https://github.com/MetaMask/metamask-mobile/blob/main/.github/coding_guidelines/CODING_GUIDELINES.md)**: These guidelines aim to maintain consistency and readability across the codebase. They help ensure that the code is easy to understand, maintain, and modify, which is particularly important when working with multiple contributors.
+- [ ] **Test it**: For any new programmatic functionality, we like unit tests when possible, so if you can keep your code cleanly isolated, please do add a test file to the `tests` folder.
+- [ ] **Add to the CHANGELOG**: Help us keep track of all the moving pieces by adding an entry to the [`CHANGELOG.md`](https://github.com/MetaMask/metamask-mobile/blob/main/CHANGELOG.md) with a link to your PR.
+- [ ] **Meet the spec**: Make sure the PR adds functionality that matches the issue you're closing. This is especially important for bounties: sometimes design or implementation details are included in the conversation, so read carefully!
+- [ ] **Close the issue**: If this PR closes an open issue, add the line `fixes #$ISSUE_NUMBER`. Ex. For closing issue 418, include the line `fixes #418`. If it doesn't close the issue but addresses it partially, just include a reference to the issue number, like `#418`.
+- [ ] **Keep it simple**: Try not to include multiple features in a single PR, and don't make extraneous changes outside the scope of your contribution. All those touched files make things harder to review ;)
+- [ ] **PR against `main`**: Submit your PR against the `main` branch. This is where we merge new features to be included in forthcoming releases. When we initiate a new release, we create a branch named `release/x.y.z`, serving as a snapshot of the `main` branch. This particular branch is utilized to construct the builds, which are then tested during the release regression testing phase before they are submitted to the stores for production. In the event your PR is a hot-fix for a bug identified on the `release/x.y.z` branch, you should still submit your PR against the `main` branch. This PR will subsequently be cherry-picked into the `release/x.y.z` branch by our release engineers.
+- [ ] **Get the PR reviewed by code owners**: At least two code owner approvals are mandatory before merging any PR.
+
+And that's it! Thanks for helping out.
diff --git a/.github/coding_guidelines/CODING_GUIDELINES.md b/.github/coding_guidelines/CODING_GUIDELINES.md
new file mode 100644
index 00000000000..f2aa54ecfab
--- /dev/null
+++ b/.github/coding_guidelines/CODING_GUIDELINES.md
@@ -0,0 +1,76 @@
+# MetaMask Mobile Coding Guidelines
+
+### 1. New Code Should be Typescript
+- New components and utilities should be written in Typescript and enforce typing.
+- Existing code should be refactored into Typescript where time allows. If you are replacing a component use Typescript.
+
+### 2. Using Functional Components and Hooks Instead of Classes
+- Use functional components and hooks as they result in more concise and readable code compared to classes.
+
+### 3. Organize Files Related to the Same Component in One Folder
+- An example of a component file structure:
+
+```.tsx
+AvatarAccount
+├── AvatarAccount.constants.ts
+├── AvatarAccount.stories.tsx
+├── AvatarAccount.styles.ts
+├── AvatarAccount.test.tsx
+├── AvatarAccount.tsx
+├── AvatarAccount.types.ts
+├── README.md
+├── __snapshots__
+│ └── AvatarAccount.test.tsx.snap
+└── index.ts
+```
+
+### 4. Follow Naming Conventions
+- You should always use PascalCase when naming components to differentiate them from other non-component TSX files. For example: *TextField*, *NavMenu*, and *SuccessButton*.
+- Use camelCase for functions declared inside components like *handleInput()* or *showElement()*.
+- When creating hooks use *withHookName()*.
+
+### 5. Avoid Repetitive Code
+- If you notice you are writing duplicated code or components, convert it into a component, utility functions or hooks that can be reused. Do this with [scalable intention](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction).
+
+### 6. Component Optimization
+- For functional components, instead of having large return statements, break the component down into smaller sub-components.
+- Use memoizing techniques where possible. Utilize the useMemo hook for values and useCallback for functions. Follow recommended React Native guidance.
+
+### 7. Use Object Destructuring For Props
+- Instead of passing the props object, use object destructuring to pass the prop name. This discards the need to refer to the props object each time you need to use it.
+
+```tsx
+import React from 'react';
+import { View } from 'react-native';
+
+const MyComponent = ({id}) => {
+ return ;
+};
+
+const MyComponent = (props, context) => {
+ const { id } = props;
+ return ;
+};
+
+const Foo = class extends React.PureComponent {
+ render() {
+ const { title } = this.context;
+ return {title}
+ }
+};
+
+```
+
+### 8. Document Each Component/Utility
+- New utility functions should be documented [TSDoc](https://tsdoc.org) commenting format.
+- Referencing our component docs.
+- If applicable add URL to online resources if they are meaningful for the component/method.
+
+### 9. Write Tests for Each Component/Utility
+- Write tests for the components you create as it reduces the possibilities of errors. Testing ensures that the components are behaving as you would expect. In this project Jest is used, and it provides an environment where you can execute your tests.
+
+### 10. External packages should be well maintained
+- New packages should only be integrated if the application doesn’t have the existing functionality and it cannot be added by implementing a small utility function. Use the https://snyk.io/advisor/ to assess the popularity, maintainability and security analysis. The package must be in good standing to be added to the project.
+- Update existing dependencies when you notice they are out of date.
+
+[Source](https://www.makeuseof.com/must-follow-react-practices/)
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index e32030a2630..2d071bb0302 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -5,7 +5,7 @@ Please ensure that any applicable requirements below are satisfied before submit
-->
**Development & PR Process**
-1. Follow MetaMask [Mobile Coding Standards](https://docs.google.com/document/d/1VJLwTRsUw_5EDq_o8d6sSbXUAYENLurkRitYO45eY5o/edit?usp=sharing)
+1. Follow MetaMask [Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/coding_guidelines/CODING_GUIDELINES.md)
2. Add `release-xx` label to identify the PR slated for a upcoming release (will be used in release discussion)
3. Add `needs-dev-review` label when work is completed
4. Add `needs-qa` label when dev review is completed
@@ -23,7 +23,7 @@ _If applicable, add screenshots and/or recordings to visualize the before and af
**Issue**
-Progresses #???
+fixes #???
**Checklist**