diff --git a/documentation/dev-portal/src/SUMMARY.md b/documentation/dev-portal/src/SUMMARY.md
index b9909e8190..cd930be17a 100644
--- a/documentation/dev-portal/src/SUMMARY.md
+++ b/documentation/dev-portal/src/SUMMARY.md
@@ -57,6 +57,11 @@
       	- [Building Your Service Provider](tutorials/simple-service-provider/service-provider.md)
       	- [Sending a Message Through the Mixnet](tutorials/simple-service-provider/sending-message.md)
 
+# Shipyard Builders Hackathon 2023 
+- [General Info & Resources](shipyard/general.md)
+- [Hackathon Challenges](shipyard/challenges-overview.md)
+- [A Note on Infrastructure](shipyard/infra.md)
+- [Submission Guidelines](shipyard/guidelines.md)
 
 # Events
 
diff --git a/documentation/dev-portal/src/shipyard/challenges-overview.md b/documentation/dev-portal/src/shipyard/challenges-overview.md
new file mode 100644
index 0000000000..f4a0be6b92
--- /dev/null
+++ b/documentation/dev-portal/src/shipyard/challenges-overview.md
@@ -0,0 +1,53 @@
+# Hackathon Challenges
+There are a few different challenges to choose from, each with different approaches. It is also recommended to check out the _**Examples**_ directory above for inspiration, and if you have questions ask in the [Builders channel]() on Matrix. 
+
+## Tooling challenge
+The tooling challenge involves creating tooling for users, operators, or developers of Nym.
+
+### Examples of user-centric tools:
+- Facilitate onboarding new users more easily to staking their Nym, and understanding the pros and cons, as well as finding a good node to stake on. Examples of tools like this:
+    - [ExploreNym dashboard](https://explorenym.net/)
+
+- Show information on a dashboard about the network. NOTE due to the amount of dashboards currently available, we expect a good justification for why / something to set this apart from existing ones e.g. it is presenting information that is not already presented, or it is presented in a different manner, such as a TUI or CLI app instead of a web dashboard - maybe an onion service, or no-JS site for those who do not wish to enable Javascript in their day to day browsing. Examples of tools like this:
+    - [NTV's node dashboard](https://status.notrustverify.ch/d/CW3L7dVVk/nym-mixnet?orgId=1)
+    - [IsNymUp dashboard](https://isnymup.com/)
+
+### Examples of operator-centric tooling:
+- An APY calculator for determining different financial outcomes of running a node in different situations. 
+    
+- Scripting for updating and maintaining nodes. Examples of tools like this:
+    - [ExploreNym's bash scripts](https://github.com/ExploreNYM/bash-tool) 
+
+- Scripting for packaging node binaries for different OSes.
+
+### Examples of developer-centric tooling:
+- Tooling for use in development: are there pain points you’ve found when developing apps with Nym that you have created scripts/hacks/workarounds for? Is there a pain point that you’ve thought ‘oh it would be great if I could just do X’? These are often the best places to start for building out developer tooling - if you’ve run into this issue, it's very likely someone else already has, or will!
+
+- Interacting with one of the SDKs via FFI: perhaps you’re a Go developer who would love to have the functionality of one of the Nym SDKs. Building an FFI tool might be something that would make your life easier, and can be shared with other developers in your situation. 
+
+## Integrations challenge
+Integration options for Nym are currently relatively restrictive due to the manner in which Nym handles sending and receiving traffic (as unordered Sphinx packets). This challenge will involve (most likely) implementing custom logic for handling Nym traffic for an existing application.
+
+There are several potential avenues developers can take here:
+- If your application (or the application you wish to modify) is written in either Javascript or Typescript, and relies on the `fetch` library to make API calls, then you can use its drop-in replacement: [`mixfetch`](). Perhaps you wish to interact with Coingecko, or a private search engine like Kagi without leaking your IP and metadata, or an RPC endpoint.
+    - Example with [NTV’s privacy-preserving Coingecko API](https://github.com/notrustverify/mixfetch-examples)
+    - [Mixfetch docs examples](https://github.com/nymtech/nym/tree/develop/sdk/typescript/examples)
+
+- If you instead have an application that is able to use any of the SOCKS5, 4a, or 4 protocols (a rule of thumb: if it can communicate over Tor, it will) then you can experiment with using Nym as the transport layer. 
+  - For Rustaceans, check out our [socks5 rust sdk example](https://nymtech.net/docs/sdk/rust.html#socks-client-example).  
+  - For those of you who aren’t Crustaceans, then you will have to run the [Socks Client]() alongside your application as a separate process. _NOTE If you are taking this route, please make sure to include detailed documentation on how you expect users to do this, as well as including any process management tools, scripts, and configs (e.g. if you use systemd then include the configuration file for the client, as well as initialisation logic) that may streamline this process._
+    - [NTV's PasteNym backend](https://github.com/notrustverify/pastenym) is a great example of an application with this architecture. 
+
+- Nym is not only useful for blockchain-related apps, but for anything that requires network level privacy! Email clients, messaging clients, and decentralised storage are all key elements of the privacy-enabled web. Several of these sorts of apps can be found in the [community apps page](../community-resources/community-applications-and-guides.md). 
+
+- There is currently a proof of concept using Rust Libp2p with Nym as a transport layer. Perhaps you can think of an app that uses Gossipsub for p2p communication could benefit from network-level privacy. 
+  - [GossipSub chat example](https://github.com/nymtech/nym/tree/develop/sdk/rust/nym-sdk/examples/libp2p_chat) 
+  - [Chainsafe's Lighthouse Nym PoC](https://github.com/ChainSafe/lighthouse/blob/nym/USE_NYM.md#usage)
+
+- Alternatively if you know of an app that is written in Rust or TS and could benefit from using Nym, you could fork and modify it using the SDKs. Applications such as:
+  - Magic Wormhole (has a [rust implementation](https://github.com/magic-wormhole/magic-wormhole.rs))
+  - [Qual](https://github.com/qaul/qaul.net) (uses Rust Libp2p)
+  - [Syncthing](https://github.com/syncthing/syncthing)
+
+### MiniApp challenge 
+Write an app, either using one of the SDKs or a standalone client (harder). Think of what you can ‘nymify’ e.g. a version of the [TorBirdy](https://support.torproject.org/glossary/torbirdy/) extension that uses Nym instead of Tor. This is very similar to the Integration challenge in terms of the different potential _architectures_ and approaches, but just for new applications. 
diff --git a/documentation/dev-portal/src/shipyard/general.md b/documentation/dev-portal/src/shipyard/general.md
new file mode 100644
index 0000000000..f07f3f22ac
--- /dev/null
+++ b/documentation/dev-portal/src/shipyard/general.md
@@ -0,0 +1,16 @@
+# General Info & Resources 
+Discussions and announcements will be taking place in the [builders channel on Matrix](https://matrix.to/#/#shipyardbuilders:nymtech.chat). This channel can be used for all discussions. 
+
+There will be daily office horse between 12-14:00 CET. 
+
+This is an open call and questions will be answered on a first come first serve basis. 
+
+The timetable can be found on the [Shipyard website](https://nymtech.net/learn/shipyard). 
+
+## Links 
+- You can find **code examples**, **tutorials**, & **quickstart** information here, on the Developer Portal. 
+- [Rust SDK docs](https://nymtech.net/docs/sdk/rust.html)
+- [Typescript SDK docs](https://sdk.nymtech.net)
+- [Platform docs](https://nymtech.net/docs)
+- [NoTrustVerify's Awesome Nym list](https://github.com/notrustverify/awesome-nym)
+- [Builders channel Matrix](https://matrix.to/#/#shipyardbuilders:nymtech.chat)
diff --git a/documentation/dev-portal/src/shipyard/guidelines.md b/documentation/dev-portal/src/shipyard/guidelines.md
new file mode 100644
index 0000000000..ac8a7b18a8
--- /dev/null
+++ b/documentation/dev-portal/src/shipyard/guidelines.md
@@ -0,0 +1,12 @@
+# Submission Guidelines
+We expect to see the following for submissions: 
+- Working code demos hosted publicly (Gitlab, Github, some other git instance).
+- Quality > quantity here: we’d prefer to see a contained, working, and well documented Proof of Concept over a sprawling and messy app that does more but is poorly explained and presented. _The repo must be open source and able to be used and modified by others. The license is up to you._
+- If you already have existing apps / projects you are more than welcome to extend them, instead of starting from scratch - we will only be looking at the NEW additions to make this fair. If you are doing this, make sure to write a detailed account of what it is you;ve added to the existing project, preferably with the possibility to see the ‘old’ version as well as the new one.
+- Proper documentation:
+  - If an app / tool:
+    - How do you install and run the code? How is it to be used? 
+    - An overview of the application architecture: what is it doing? Is it relying on other services? 
+  - If a UI-based solution:
+    - How to run it locally? We are happy to also accept staging deployments as part of the submission (e.g. via Vercel) but this does not replace being able to run it locally.
+- Please make sure that your application works on commonly reproducible system environments (e.g. if you’re developing on Artix Linux please check for the necessary dependencies for more common-place OSes such as Debian, or Arch). If you are developing on Windows please make sure that it works on non-Windows machines also. Where possible please try to include build and install instructions for a variety of OSes. 
diff --git a/documentation/dev-portal/src/shipyard/infra.md b/documentation/dev-portal/src/shipyard/infra.md
new file mode 100644
index 0000000000..b5621f6ff6
--- /dev/null
+++ b/documentation/dev-portal/src/shipyard/infra.md
@@ -0,0 +1,5 @@
+# A Note on Infrastructure
+If you are writing an application that requires sending messages through the mixnet, then you will either be relying on existing infrastructure nodes (network requesters), or writing your own custom service (for example, the service written as part of the Rust SDK tutorial).
+
+If you are relying on network requesters then chances are that the IPs or domains your app relies on will not already be on the whitelist. Ideally, you would [run your own,](https://nymtech.net/operators/nodes/network-requester-setup.html) but we will also run a few nodes in ‘open proxy’ mode and share the addresses so that you can use them when beginning to develop. 
+