WeTheNorth Market Architecture
A layer by layer model of how a darknet marketplace is structured, from the interface a participant sees down to the data that records state. Described at a high level, for understanding rather than implementation.
Architecture Overview
Marketplace architecture is the arrangement of responsibilities into layers. Each layer has one job and a clear boundary with its neighbours, which is what makes the whole system possible to reason about, test, and secure.
At the top, an interface renders listings and categories and captures intent. Below it, an application layer holds the logic that turns intent into actions. An account layer resolves identity and session, a marketplace layer models the domain of listings and vendors, a security layer enforces controls across everything, and a data layer persists state.
The value of this separation is that a change in one layer does not force a change in the others. The interface can be redrawn without touching how data is stored; security controls can be strengthened without rewriting the domain model. Boundaries are where guarantees live.
This is a conceptual model, not a schematic of any specific platform. It exists to make the vocabulary concrete: when a reference mentions the account layer or the data layer, this page is what those terms mean here.
The security layer is given its own page because trust is the central problem of the category. Read this architecture first, then read security as the cross cutting concern that touches every layer below.
Architecture Layers
Each layer is a boundary of responsibility. Read top to bottom to follow a request through the model.
Interface Layer
Presentation. Renders listings and categories and captures participant intent.
Application Layer
Logic. Coordinates actions, validates input, and orchestrates the layers below.
Account Layer
Identity and session. Resolves who a request belongs to and what it may do.
Marketplace Layer
Domain. Models listings, vendors, categories, and the relationships between them.
Security Layer
Controls. Enforces authentication, integrity, and access rules across every layer.
Data Layer
State. Persists records and guarantees they remain consistent over time.
Marketplace Components
The recurring components that populate the layers above, described conceptually.
Interface
The presentation surface. It translates the domain into something browsable and turns interaction back into structured requests.
Account & Session
Identity resolution and the session that scopes a set of actions. The session is the thread that ties requests to a participant.
Listings
The core content records. Listings carry the fields that categories and search operate on and are referenced throughout the domain.
Vendor Organization
The modelling of the vendor role, including reputation and identity signals that feed trust evaluation.
Categories
The taxonomy that makes a large collection navigable. Categories are structure imposed on content for discovery.
Transactions
The settlement concept, generally cryptocurrency based, recorded at a high level as an exchange of value between roles.
Security
The controls that cut across every component: authentication, integrity, and access enforcement.
Data
Persistent state and the consistency guarantees around it. Data is where the effects of every other component are recorded.
Architecture Principles
The design ideas that hold the layered model together.
Separation
Each layer owns one responsibility with a clear boundary, so changes stay local and guarantees are easy to locate.
Authentication
Requests are tied to a resolved identity before they are trusted, making the account layer a gate rather than a formality.
Session Management
A session scopes what a set of actions may do and for how long, limiting the blast radius of any single compromise.
Data Integrity
State is kept consistent and tamper evident, so records can be reasoned about and trusted after the fact.
Availability
The model favours designs that keep the system reachable and responsive, since instability is itself a trust problem.
Security
Controls are treated as a cross cutting layer rather than a feature, present at every boundary in the stack.
Technical Reference
A high level summary of the model. All entries are informational and describe concepts, not any live system.