Frequently Asked Questions

Retrostock is an international catalog of retro games, gaming hardware, peripherals, and other pieces of gaming culture—from a general title all the way down to an individual physical copy.

It is also a practical place to manage your entire collection, mark releases you already own, create detailed records for especially interesting items, and build a want list.

Every registered user receives a permanent RSU number. The catalog follows the RST → RSP → RSR → RSC structure.

On Retrostock, you will be able to:

• explore games, consoles, peripherals, regional products, and specific releases;
• quickly record items in your collection;
• create digital records for physical copies you own;
• preserve photographs, condition, completeness, and the history of a particular item;
• research official editions, bootleg releases, hacks, compilations, and multicarts;
• find items you are looking for and exchange offers with other collectors.

Real physical items are at the heart of the project. For that reason, user-created catalog entries begin with an RSC that the contributor actually owns.

Information about older games and hardware is often scattered across forums, social media, archived websites, and marketplace listings that eventually disappear.

Retrostock helps preserve:

• official and unofficial game titles;
• regional versions, localizations, and reissues;
• consoles, peripherals, bundles, demo discs, and multicarts;
• repeatable release and manufacturing variants;
• photographs and identifying details of real surviving copies;
• the condition, completeness, ownership, and transfer history of a particular item;
• collector research and first-hand knowledge.

Retrostock is not meant to fill up with abstract entries created from someone else’s photographs or a passing mention found online.

The goal is to preserve not only the record of what once existed, but also the stories of the items that have survived to the present day.

No. Retrostock is not an online store, auction platform, or transaction intermediary.

The service helps collectors manage collections, showcase items, find releases they are interested in, and exchange offers or contact details.

Payment, shipping, in-person handover, trades, and transfers take place directly between users outside Retrostock.

Retrostock is not limited to games on discs and cartridges.

You will be able to register:

• games, official compilations, demo discs, and unofficial multicarts or multi-game releases;
• home and handheld consoles;
• systems with built-in games;
• controllers, joysticks, and other peripherals;
• memory cards and storage devices;
• cables, adapters, and power supplies;
• boxes, manuals, printed inserts, and promotional materials;
• spare parts and individual components, including drives, power supplies, shell pieces, buttons, ribbon cables, screws, and other hardware;
• homebrew, fan-made, and other physical releases;
• official bundles containing several games or devices.

Each category may have its own item details and photography requirements.

Retrostock is being developed as an international service.

The Russian-language version may operate at retrostock.ru , while the international version may operate at retrostock.net .

Both versions can share the same RSU accounts, the same RST → RSP → RSR → RSC catalog, and the same history of physical copies.

RSU stands for Retrostock User.

It is a permanent number assigned to a registered user, for example RSU000000127 .

An RSU is assigned as soon as the account is created. It does not depend on having a short username, a public collector profile, or any registered items.

The RSU identifies a participant in the service and is separate from the catalog hierarchy used for items.

The four levels keep the title itself, a particular product, a repeatable release, and an individual physical copy from being mixed together on one page.

• RST identifies the game, device, or distinct composite title;
• RSP identifies the particular product that existed on the market;
• RSR identifies a specific repeatable release or manufacturing variant of that product;
• RSC identifies the individual physical item in front of us.

The same structure works for games, consoles, bootleg multicarts, and rare collector bundles.

RST stands for Retrostock Title.

It is the base catalog entity: a particular game on a particular platform, a distinct hardware model or family, a compilation, a multicart, or another standalone title.

Examples include:

• Driver — PlayStation;
• Resident Evil / Biohazard — PlayStation;
• Sony PlayStation;
• Sony PS one;
• PlayStation Classic;
• Cluster’s “Multigame Cartridge”;
• a particular “9999 in 1” multicart build.

Retrostock uses the word Title across all categories, including hardware and composite products.

RST answers the question: “What distinct title is this?”

For games, an RST is defined by the combination of the game itself and the platform .

• Driver — PlayStation is one RST;
• Driver 2 — PlayStation is another RST;
• Resident Evil and Biohazard on PlayStation belong to the same RST despite their different regional names.

An RST does not cover an entire series. A sequel, remake, or distinct standalone hack will usually receive its own RST.

Region, official local title, and the specific market version are described one level lower, at the RSP level.

For hardware, an RST represents a distinct model or product family—not every regional model code and not every internal variation.

For example, the original Sony PlayStation family from SCPH-1000 through SCPH-9003 belongs to one RST.

The compact PS one family from SCPH-100 through SCPH-103 receives a separate RST because it is a distinct product redesign.

The exact model code and region belong at the RSP level, while a repeatable manufacturing variation within that product belongs at the RSR level.

RSP stands for Retrostock Product.

It is a particular product within an RST: a regional version of a game, a console model for a specific market, a version of an official bundle, or another distinct product offered on the market.

For a game:

• RST — Resident Evil / Biohazard — PlayStation;
• RSP — Resident Evil — Europe;
• RSP — Resident Evil — North America;
• RSP — Biohazard — Japan.

For a console:

• RST — Sony PlayStation;
• RSP — Sony PlayStation SCPH-1002 — Europe;
• RSP — Sony PlayStation SCPH-5500 — Japan.

RSP answers the question: “Which particular product of this title existed?”

RSR stands for Retrostock Release.

It is a specific repeatable release, print run, reissue, or manufacturing variant of an RSP.

Examples include:

• an original release and a later pressing;
• a Platinum or Greatest Hits reissue;
• a variant with different cover art, disc label, matrix, or printed materials;
• a confirmed repeatable software build;
• different mass-produced revisions of the same device;
• a distinct production run of a bootleg, fan-made, or homebrew product.

The defining feature of an RSR is repeatability . When the same difference appears across several copies and comes from the release or manufacturing process, it may justify a separate RSR.

RSR answers the question: “How exactly was this product released or manufactured?”

RSC stands for Retrostock Copy.

It is the digital record of a particular physical item or set in the form in which it currently exists and is tracked by its owner.

An RSC may describe a single disc, cartridge, console, boxed set, incomplete set, spare part, or a quantity of identical small parts kept and offered together.

An example of a permanent public code is RSC000000077 .

Two identical discs from the same RSR are still two different RSCs because they may have different owners, condition, completeness, and history.

RSC answers the question: “Which exact physical item or set is this today, and what has happened to it over time?”

An RSC page may contain:

• original photographs of that specific item;
• condition and completeness;
• serial numbers and individual markings;
• damage, repairs, and replaced parts;
• descriptions added by different owners;
• public, anonymous, or private ownership history;
• changes in condition over time;
• collection, sale, trade, or lost status;
• offer, price, and transfer history;
• for rewritable devices, the history of their actual installed content.

The RSC stays with the physical item itself and does not change when ownership changes.

Yes.

Sometimes an item can be confidently linked to an RST and RSP, but its exact RSR cannot be identified. A loose console may retain its model number while the box that distinguished the original retail release has been lost.

A unique item may also have no repeatable RSR—for example, a one-off homemade cartridge, a disc recorded as a single copy, or a custom-built device.

Spare parts follow an even simpler rule: an individual component may be registered as an RSC without any RST, RSP, or RSR at all. A clear category, description, quantity, condition, and original photographs are enough.

Retrostock never forces a contributor to choose a more specific level than the available evidence can honestly support.

Record only the level that can genuinely be supported by the item itself and the surviving materials.

For example, an SCPH-3000 console may originally have been sold in either a full-color or black-and-white box, while an SCPH-5500 may have come in a red or green box. If the box is gone and only the console remains, the RSP model can still be identified, but the exact boxed RSR cannot.

In that case, the RSC is linked to the RSP and the release remains unspecified. That is neither an error nor an incomplete registration.

The key rule: an RSC is linked to the most specific level that can be proven, not the most detailed possibility that can be guessed.

One level cannot accurately describe all of the following at once:

• the game itself or the hardware model;
• the regional or market-specific product;
• a particular production run or repeatable release variant;
• the history of an individual physical item.

For example, Driver for PlayStation is the RST. The European product is an RSP. A particular reissue is an RSR. Your own disc is an RSC.

This keeps the catalog understandable without turning every small variation into a new title.

Not as a regular user.

A new catalog entry cannot be created from memory, a written description, a link, or photographs found online.

The user begins by registering an RSC they own. If the appropriate RST, RSP, or RSR does not yet exist, it is proposed as part of the same submission.

An administrator may create or correct catalog entities without a user-owned RSC for data migration, duplicate merging, maintenance, or correction of a confirmed error.

For a regular item, there is one starting action: “Add my RSC copy.”

What happens next depends on what already exists:

• if the RST, RSP, and RSR already exist, only the RSC is created;
• if the RST and RSP exist but the right RSR does not, RSR + RSC are proposed;
• if the RST exists but the right RSP does not, RSP + RSR + RSC are proposed;
• if the title itself is missing, RST + RSP + RSR + RSC are proposed;
• if the item is unique and has no repeatable release, the submission may end with RST + RSP + RSC ;
• if the item is a spare part or individual component, a standalone RSC can be created without requiring an RST, RSP, or RSR.

The contributor confirms that they possess the physical item and uploads their own photographs. When new catalog entries are proposed alongside the RSC, the entire group is reviewed as one submission.

No.

A new catalog entity cannot be created from an item you do not possess or from photographs taken from search engines, stores, auctions, marketplace listings, forums, social media, other collections, or other catalogs.

You may report a potentially unknown title or release, provide a link, or suggest a correction. That information may help future research, but it does not create a new catalog entry by itself.

User-created catalog entities begin with a personal RSC.

Yes.

Owning an RSC is required to create a new entity, but not to report an error in an existing entry.

You may suggest:

• a corrected title or typo;
• a clarification of platform, region, model, date, or manufacturer;
• a correction to an incorrect relationship;
• the separation or merging of duplicates;
• a correction to the contents of a compilation or multicart;
• a report concerning an incorrect photograph or rights violation;
• additional text supported by a verifiable source.

A correction request must not be used to effectively create a new title or release without a personal RSC.

A composite title is a game, device, or official bundle that contains other games or items which can also be cataloged in their own right.

Examples include:

• an official compilation containing several games;
• a demo disc containing several playable demos;
• an unofficial “6 in 1” or “9999 in 1” multicart;
• a PlayStation Classic or NES Mini with a built-in game library;
• an official PS one bundle that includes a game;
• a boxed set containing several separate discs.

The contents may be built into a disc, cartridge, or device, or they may be separate physical items packaged together in one box.

A particular official compilation or demo disc receives its own RST.

Regional versions of that compilation become RSPs, while separate pressings and reissues become RSRs.

Its contents are recorded separately: which games or demos are included, their order, and how confidently their source versions have been identified.

The included games do not become child RSPs of the compilation. They retain their own RST, RSP, and RSR entries, which the compilation contents can reference.

If several standalone games were officially sold together as one retail set, the set itself receives its own RST.

For example, Need for Speed III, Sled Storm, and NASCAR Rumble may have been sold together in one box. Each game keeps its own catalog entry, while the set records exactly which products or releases were included.

A particular set may have its own regional RSP and separate RSRs for different release variants.

Every physical box of that set receives its own RSC.

If a console and game were officially sold as a distinct retail bundle, that bundle receives its own RST.

For example, a PS one and Harry Potter bundle contains at least two independently identifiable parts:

• a particular PS one product;
• a particular product or release of the Harry Potter game.

The standard PS one remains a separate RST. The bundle does not replace the console’s own catalog entry; it simply records the products included in the package.

A game casually added by a retailer does not necessarily create a new title. What matters is whether the bundle existed as a distinct product in its own right.

PlayStation Classic, NES Mini, and both official and unofficial systems with built-in games are treated as composite titles.

One hardware model can remain a single RST even when regional products have different built-in libraries. For example, the game list of PlayStation Classic can differ at the RSP level.

If a later release of the same product received different firmware or an altered game library, that difference may belong at the RSR level.

An unofficial console sold under a brand such as 8bit follows the same catalog principles. Official or unofficial status does not change the structure of the catalog.

The contents are recorded at the level where they genuinely become common to every item below it.

• If every version of the title has the same contents, they are described at the RST level.
• If the contents differ between regional or market-specific products, they are refined at the RSP level.
• If the difference appears only in one particular release, it is recorded at the RSR level.

A lower level may refine a single included item without forcing the entire compilation to become a new RST because one game was replaced.

This is especially important for regional mini-consoles, bootleg multi-game releases, and cartridges that look identical but contain different software.

A particular “6 in 1” multi-game build receives its own RST.

Different products based on the same title may appear under different labels or with different presentation. The same underlying build, for example, might have been distributed as a Vector, Golden Leon, or Pinochet Games product.

If the game list, game order, and menu behavior are the same, differences in label, cover art, and disc print do not by themselves require a new RST.

If one particular release swaps an included game for another localization or internal version, that difference can be recorded at the RSR level without creating an entirely new title for the compilation.

If the builds are genuinely different—for example, the game list or the way the menu works changes substantially—they may receive separate RSTs.

The words “9999 in 1” prove very little on their own. Completely different multicarts may use the same name.

Identification takes into account the menu, the actual game list, game order, repeated entries, internal versions, and how the cartridge behaves after booting.

Two cartridges may have identical shells, labels, and boards, yet on startup the menu on one contains a Mario entry, while the menu on the other contains a Tetris entry. In that case, they may belong to the same RST and RSP but to different RSRs.

When the variant cannot be identified from the outside, the RSC can first be registered without an exact RSR and then refined after the cartridge has been tested.

Cluster’s “Multigame Cartridge” is a standalone RST.

The 64 MB and 128 MB versions may be separate RSPs, while repeatable board variants may be separate RSRs.

The exact game library, however, is chosen by the owner when the cartridge is written. The contents of a particular cartridge therefore belong to its RSC rather than to the entire RST, RSP, or RSR.

If the owner rewrites the cartridge, the previous game list is not erased from its history. The RSC keeps a sequence of content snapshots.

This allows two identical cartridges of the same board revision to hold different libraries while still remaining copies of the same release.

Yes, but there is no need to create a separate RSC for every part of a complete set in advance.

As long as a boxed console, three-disc set, or other bundle is stored and treated as one collectible unit, one RSC with its current completeness is enough.

A separate RSC is created when part of the set is genuinely separated and becomes an independent item—stored, sold, transferred, or tracked on its own.

The same rule applies to a boxed console. There is no need to create separate records in advance for the console shell, controller, manual, packing foam, and every screw. But when the box, manual, or another part begins to exist and trade independently, it may receive its own RSC as a standalone collectible item.

A set’s current completeness or incompleteness does not erase the record of how it was originally released.

Identification can become more precise over time.

• At first, we may know only that the included game is Driver, so the contents point to the game’s RST.
• Further research may identify a specific regional version, allowing the reference to be refined to an RSP.
• If the exact release can be established, the RSR is recorded.

If a menu entry has not yet been identified at all, its displayed name, menu position, photographs, and observed behavior can be preserved without prematurely linking it to the wrong catalog entry.

The evidence can come from researching a real disc, cartridge, or device registered as an RSC: running it, examining its menu, and documenting observable details.

An included game can be given one of three clear findings:

• it is not yet known whether the version was modified;
• research confirms that it is complete;
• the version is cut down or materially altered.

The record can also explain what was found: removed videos, music, or levels; a different translation; a modified executable; compression; or other changes.

If that version was never released as a standalone product, Retrostock does not invent a fictional RSR for it. It remains a description of the contents of the relevant compilation, release, or RSC.

At this stage, Retrostock does not publish game dumps or firmware images themselves.

Yes.

Retrostock preserves not only the current conclusion, but also the path taken to reach it.

For example:

• a menu entry was initially unidentified;
• it was later identified as Contra;
• the regional version was established after further research;
• a later comparison showed that some content had been removed.

Much of the catalog’s knowledge begins with an observation made on one real RSC. When the same feature appears on other copies, or its wider meaning becomes clear, that finding may be reflected at the RSR, RSP, or RST level.

This lets Retrostock correct and refine the catalog without losing earlier observations, while making it clear which physical items support each conclusion.

Retrostock can store several names for the same game or product and record where each name came from.

These may include:

• the original official title;
• an official regional title;
• a translated or localized title;
• an unofficial name used on a bootleg product;
• a name shown only in the menu of one particular multicart;
• an incorrect or tentative name found in older sources.

A new name does not always mean a new RST. The key question is whether the game itself changed or only its label and presentation.

Contra and Probotector belong to the same RST because they are official regional versions of the same game on the same platform.

They receive different RSPs: one product is titled Contra, while the other is titled Probotector for its intended market.

Even substantial regional changes to characters and presentation do not necessarily create a new RST when they are part of an official adaptation of the same game.

Individual editions and reissues of Contra or Probotector are then separated at the RSR level.

Journey to Silius and Raf World belong to the same RST.

They are different official regional titles for the same game on the same platform, so each name is stored at the appropriate RSP level.

If a bootleg cartridge uses yet another title for the otherwise unchanged game, that name may belong to a separate unofficial RSP, but it does not automatically require a new RST.

It depends on what is actually inside.

If Super Contra 6 is genuinely a modified version of Contra Force—with replaced characters, altered graphics, or other consistent changes to the game itself—it receives a separate RST. Its description explains that the hack was built from Contra Force.

If the cartridge merely says Super Contra 6 but contains an unchanged copy of Contra Force, no new RST is needed. It is an unofficial RSP of Contra Force with a different title and presentation.

The key rule: a new label creates a new product, while a distinct modified game may create a new title.

An RSU is assigned immediately after an account is successfully created.

RST, RSP, RSR, and RSC numbers are assigned after the catalog submission has been reviewed. Until then, entries use internal draft identifiers only.

A submission may contain just an RSC, or it may also include any missing RST, RSP, and RSR entries needed for that copy.

Once approved, permanent codes are assigned, for example RST000000555 , RSP000000321 , RSR000000666 , and RSC000000077 .

Moderation helps to:

• prevent duplicate entries;
• separate RST, RSP, RSR, and RSC correctly;
• distinguish a new title from a regional product or a particular release;
• determine whether two multi-game releases are the same build or different titles;
• verify the contents of official bundles and built-in libraries;
• confirm that a new user-created entity is supported by a personal RSC;
• correct errors and remove unauthorized or prohibited material.

Moderation is not a professional authentication service and does not constitute legal proof of ownership.

New knowledge does not always arrive as a finished conclusion.

A collector may be the first to notice an unusual label, cartridge contents, menu variant, or another difference on their own RSC. At first, that finding is preserved as an observation about one specific item.

If the same difference is later confirmed on other copies, it may become clear that it represents more than a one-off quirk: it may identify a repeatable release, a separate product, or a distinct title.

Retrostock therefore grows from real items toward broader catalog conclusions, rather than relying only on entries defined in advance and then forcing copies into them.

Related entities are reviewed as one submission because the new catalog entries are being proposed on the basis of a particular physical RSC.

A moderator may:

• approve the proposed structure;
• request additional information or photographs;
• find an existing RST, RSP, or RSR and link the RSC to it;
• move a product under a different title;
• decide that a difference belongs at the RSP, RSR, or individual RSC-history level;
• merge duplicates or split entities that were incorrectly combined;
• reject the submission.

If the supporting RSC is rejected, the related new RST, RSP, and RSR entries are not published.

An approved RSU, RST, RSP, RSR, or RSC number should never be reassigned to a different object.

If entries are merged, the former number may remain as a historical identifier and redirect to the primary entry.

If the original classification was wrong, moderation corrects the relationships without reusing the now-unused number.

Yes. A contributor can remain anonymous in the public-facing parts of the service.

A user may register a personal RSC and propose any missing RST, RSP, or RSR without revealing their profile or RSU to other visitors.

The operator still retains the internal link between the submission, the copy, and the account for moderation, safety, and item-history purposes.

No.

Approval means that the entry has been accepted into the catalog structure, passed the applicable review, and was not considered an obvious duplicate at the time of moderation.

It is not a professional authentication, condition appraisal, legal proof of ownership, or guarantee that the user is acting in good faith.

Possible reasons include:

• the contributor has not demonstrated possession of the physical RSC;
• the photographs were downloaded or belong to someone else;
• the photographs show different copies;
• required angles or markings are missing;
• the correct entity already exists;
• a new RST was proposed for a difference that belongs only at the RSP or RSR level;
• a one-off feature of a single item was incorrectly presented as a repeatable release;
• the contents of a multicart were described only from the label without examining the actual software;
• the material violates the rules or another person’s rights;
• a moderator’s request for clarification was not completed.

If the correct existing entity is found, the RSC may be linked to it instead of the entire submission being rejected.

The available details depend on the category and on how precisely the item has been identified.

• RST describes the title itself: the game, hardware model, compilation, or multicart;
• RSP describes the particular regional, model-specific, or market-specific product;
• RSR describes a repeatable release, production run, or manufacturing variant;
• RSC describes the condition, completeness, and individual history of the physical item.

For a disc, details may include the data surface, disc label, matrix, case, cover art, and manual.

For a cartridge, they may include the shell, label, contacts, board, battery, and the software observed after booting.

For a console, they may include the model, region, serial markings, functionality, completeness, and signs of repair.

For a spare part, the initial requirements are deliberately simple: category, clear description, quantity, condition, and photographs. The owner may add any other useful information in the description.

Structured fields are used when they genuinely improve search and comparison—not merely to make an entry more complicated.

An RSC’s condition is stored as a history of observations rather than one field that is overwritten forever.

This makes it possible to see how an item changed over time and across different owners.

An RSC must use original photographs of the exact physical item in the contributor’s possession.

Depending on the category, required photographs may include:

• views from several sides;
• the disc and its matrix;
• the box, printed materials, and overall completeness;
• the label, contacts, and board of a cartridge;
• serial and catalog markings;
• connectors, damage, and individual identifying features.

Photographs taken from search engines, stores, auctions, marketplace listings, forums, social media, other collections, or other catalogs are not accepted.

Do not upload documents, addresses, faces, private messages, or other unnecessary personal information.

A consistent set of photographs may be enough when it clearly shows the same item, its markings, completeness, condition, and individual features.

When necessary, Retrostock may request:

• an additional angle;
• a close-up of a marking or defect;
• a photograph of the set arranged in a specified way;
• a photograph of the item beside a one-time submission code;
• new photographs after a moderator’s request.

Decisions are based on the complete set of evidence. No single indicator is treated as absolute proof.

No.

Metadata may disappear after resizing, conversion, or removal of location information. Its presence also proves nothing by itself.

Retrostock may treat available technical metadata as one additional signal, but missing EXIF data is not grounds for rejection.

Location data is not required and is not published.

Yes. Retrostock is intended to help not only collectors, but also people who repair and restore older hardware.

Users will be able to add CD drives and GD-ROM drives, laser mechanisms, power supplies, circuit boards, ribbon cables, buttons, shell pieces, lids, screws, and any other physical components.

Even a small original screw may be a valuable spare part when it is needed to restore a console properly.

No, not necessarily.

For most individual components, a full catalog hierarchy would be excessive. A spare part may be registered as a standalone RSC without an RST, RSP, or RSR.

If a well-known component later proves useful enough to deserve full cataloging, that structure can be added then. At launch, it should not prevent someone from listing a needed part quickly.

The basic information is enough:

• category;
• a clear description;
• quantity;
• condition;
• original photographs.

The description may freely include anything useful, such as markings, a known device model, test results, defects, and other details.

At the initial stage, Retrostock does not require a formal link to the donor device or a structured compatibility table.

There is no need to create a separate RSC for every identical screw, bolt, or other small component.

Create one RSC and enter the quantity. For example:

An account is the internal record used for sign-in, security, settings, and confirmation of actions. It receives a permanent RSU number immediately after registration.

A collector profile is an optional public or hidden page with a short username, collection, interests, reviews, and social links.

A user may have an account and RSU, register RSCs, and contribute to the catalog without creating a collector profile or short username.

No.

The account receives its RSU at registration. A short username, collector profile, public collection, and social features are all optional.

Changing, hiding, or removing a username does not change the RSU.

No.

An RSU is assigned once, cannot be transferred to another account, and is not reused after an account is closed.

If an account is restored, it keeps the same RSU. If duplicate accounts are merged, the history of both numbers is preserved and moderation determines the primary number.

A permanent RSU is necessary to preserve the integrity of submissions, ownership records, content, and audit history.

That depends on the feature and your visibility settings.

• for public participation, the RSU may appear beside a short username or in place of it;
• for anonymous participation, visitors see “Anonymous Retrostock contributor”;
• for private actions, the link to the RSU is available only to the Operator and authorized moderators.

Hiding a profile does not remove the RSU or break the internal link between the account and its actions.

No.

A user receives an RSU and can register personal RSCs, participate in moderation, and own copies without a public profile.

The profile is mainly for a short public username, a public collection, social links, reviews, reputation, and communication.

Not having a profile does not allow a user to create an RST, RSP, or RSR without a personal RSC.

Regular registration is expected to require only a minimal set of information:

• an email address;
• a password;
• acceptance or confirmation of the required documents and consents.

After successful registration, the system automatically assigns the account an RSU.

A short username and collector profile are optional and may be created later.

Normal use of the catalog is not expected to require a passport or ID document, full legal name, home address, phone number, or payment details.

Not by default.

Your email address is used for sign-in, account recovery, security, and service notifications.

Users should not post their email address in articles, comments, or a public profile description unless they intentionally want it to be public.

Yes.

Once hidden, the profile is no longer available to visitors. In other public contexts, the user may appear by RSU or as an anonymous contributor, depending on their settings.

Catalog content and anonymized item history may remain available under the service rules.

Hiding a profile is not the same as closing an account: the user keeps access to the account and the same RSU.

A user may close the public profile and request deletion or anonymization of related personal data when there is no other lawful basis for continuing to process it.

The following may be removed or hidden:

• the profile image and description;
• social links;
• the short public username;
• the public association between content and the individual.

The account’s RSU is not transferred to another user. RST, RSP, RSR, RSC, and non-personal catalog history may continue to exist.

In public areas, the former contributor may be shown in anonymized form.

Yes.

After closure, access is disabled, the profile is hidden, and personal data is deleted or anonymized to the extent permitted by law and the service rules.

The RSU is not transferred to a new account and is never reused.

RST, RSP, RSR, and RSC entries are not deleted automatically because they describe the catalog and physical items. A limited internal link to the former RSU may be retained where necessary for historical integrity, auditing, and dispute resolution.

The public connection to the former user may be removed or replaced with an anonymized record.

One account and one RSU may have only one collector profile.

Creating additional accounts to evade moderation, bans, or reputation history is prohibited.

If access is lost, the user should contact support. Duplicate accounts may be merged, with the history of their RSU numbers preserved.

An RSU is a permanent identifier, not a disposable alias.

Yes.

Ownership may be:

• public —an allowed profile, short username, or RSU is shown;
• anonymous — the item is shown as owned, but the owner’s profile and RSU are not disclosed;
• private —ownership information is not shown to other users.

The Operator retains the internal link between ownership, the account, and its RSU.

Yes.

The previous and new owners may choose not to reveal their profiles, usernames, or RSU numbers publicly.

The new owner chooses the visibility of their own ownership record.

The RSC does not change during a transfer: the history of the same physical item continues, while the necessary internal link to each participant’s RSU is preserved.

A collector may voluntarily add links to:

• a personal website;
• Telegram;
• VK;
• YouTube;
• Avito;
• Meshok;
• eBay;
• other online profiles or resources.

These links allow collectors to showcase their projects and continue conversations outside Retrostock.

The user decides whether a link is visible to everyone, only to a user whose offer has been accepted, or not shown at all.

Yes.

A new or changed link may become visible only after review.

This helps protect users from:

• spam;
• misleading or substituted URLs;
• fraudulent pages;
• malicious websites;
• links that do not belong to the profile owner.

Where supported by the system, a previously approved link may remain visible while the replacement is being reviewed.

A user can mark that they own an existing RSR without creating a detailed RSC.

It is a quick way to manage an entire collection: choose the release, enter the quantity, and optionally add a short note.

You cannot mark an RST or RSP as owned. A physical item must belong to a specific existing RSR.

If the required RSR is not yet in the catalog, you must first register a personal RSC and use it to propose the missing release.

The “I Own This” option is available only on the page of an existing RSR.

An RST describes the title as a whole, while an RSP describes a particular product. Neither is specific enough to show which physical release is in the collection.

A unique item with no RSR is recorded as an individual RSC.

Yes.

A simple “I Own This” entry can include a quantity, such as three copies of the same RSR.

When detailed RSCs are created, each item that is tracked, stored, sold, or transferred independently will normally receive its own record.

One RSC may still describe a factory bundle, an incomplete set, or a quantity of identical small parts that the owner tracks together. For example, five identical original screws can be recorded as one RSC with a quantity of 5.

Separate RSCs are required when items have different owners, condition, completeness, history, or sale and transfer status.

Not when the appropriate RSR already exists. You can use “I Own This” and manage most of a large collection quickly.

Create an RSC when a particular physical item needs its own record: photographs, condition, completeness, ownership history, sale, trade, or transfer.

If the required RSR does not yet exist, the simple mark is not enough. A new release can only be proposed through an RSC that you own.

“I Own This” does not verify condition, completeness, authenticity, or the individual history of a copy.

It shows that the user:

• is looking for the item;
• would like to buy it;
• would accept it in a trade;
• is open to receiving an offer.

The visibility of a Want entry depends on the user’s settings.

Yes, but each level means something different.

• Want RST — the user wants the title in general and is willing to consider different products and releases;
• Want RSP — the user wants a particular regional, model-specific, or market-specific product but may accept different releases of it;
• Want RSR — the user wants that exact edition, production run, or manufacturing variant.

For a specific already identified physical copy, an offer is sent to the owner of the RSC.

Yes.

You may specify:

• a starting amount for discussion;
• a maximum budget;
• currency;
• desired condition;
• completeness requirements;
• acceptable defects;
• whether you are willing to buy or trade;
• an additional comment.

A maximum budget can be hidden from other users and used only by internal search settings.

Yes.

If the owner’s profile is public, approved social links may be available.

If the owner is hidden, you can send an internal offer without either party having to reveal their identity first.

The recipient decides whether to accept the offer and whether to share permitted contact information with the other party.

An item or copy may use statuses such as:

• in collection;
• open to offers;
• available for trade;
• for sale;
• sale or trade;
• lost .

The Lost status preserves the RSC and its history even when the owner no longer has the item and does not know where it is.

Yes, when it is a copy of an existing RSR.

A user may offer an item they own as a copy of a known release without creating a detailed digital record. Condition, completeness, and individual details can then be discussed directly with the owner.

An RST or RSP alone is not enough. If no suitable RSR exists, the new release must be proposed by registering a personal RSC.

A spare part that is not linked to an RST, RSP, or RSR receives a simple RSC of its own; otherwise, there would be no item for the offer to refer to.

This keeps a detailed record optional for ordinary known releases while still requiring real physical evidence for new or uncataloged items.

Yes.

The owner may specify:

• price;
• currency;
• whether offers are welcome;
• a comment;
• trade conditions.

A price may apply to:

• a specific RSC;
• an item recorded only as a copy of a particular RSR.

Yes.

Retrostock can distinguish and preserve:

1. the owner’s asking price;
2. the amount offered by a buyer;
3. the confirmed final transfer price.

These values do not overwrite one another and may have different visibility settings.

Yes.

Either party to the transfer may choose to hide the final price.

If at least one participant chooses privacy, the public record shows:

The fact that the transfer occurred may remain visible when permitted by the participants’ settings.

It is an offer to:

• buy an item;
• trade for an item;
• buy or trade;
• discuss another arrangement.

It may refer to:

• a specific RSC;
• an “I Own This” entry;
• a Want entry.

Yes.

Before accepting, the owner might see a message such as:

An anonymized reputation summary may also be shown.

Retrostock internally retains the link between the offer, the account, and its RSU for safety, interaction history, and abuse prevention.

The parties may gain access to each other’s permitted profile information and contact links.

Before confirmation, the interface should clearly explain which information will be revealed to the other party.

Accepting an offer does not mean that:

• the transaction has been completed;
• money has changed hands;
• the item has been shipped;
• ownership has been legally verified;
• the RSC has automatically changed owners.

Any further arrangements are made directly between the users outside Retrostock.

Offers are tied not only to the item, but also to the ownership record that existed when the offer was sent.

When ownership changes, old offers become invalid. A new owner cannot accept an offer that was addressed to the previous owner.

The new owner continues the history of the existing RSC instead of creating a new record for the same physical item.

They may add:

• their own photographs;
• their own description;
• a new condition observation;
• updated completeness information;
• the story of how they acquired it.

Materials contributed by previous owners remain separate unless there is a valid reason to remove or anonymize them.

Yes.

A transfer may happen because of:

• a sale;
• a trade;
• a gift;
• inheritance;
• a donation or transfer to a museum;
• another arrangement.

A request can be submitted to merge the entries.

After review, the information, photographs, and history may be combined into the primary RSC.

The former number of the duplicate entry may continue to redirect to the primary record.

A new owner cannot independently delete or replace material contributed by a previous owner.

However, the administration may correct, hide, anonymize, or remove material when:

• it contains unnecessary personal data;
• it violates another person’s rights;
• it is unrelated to the item;
• it contains substantial errors;
• it includes prohibited information;
• removal is required by law;
• there is no longer a lawful basis for processing the contributor’s personal data.

Non-personal historical information about the RSC may remain in anonymized form.

The RSC continues to exist as the record of a physical item.

The public connection to the former owner may be removed or replaced with an anonymized entry.

Keeping the RSC does not mean retaining the former user’s email address, social links, or other identifying information indefinitely.

Yes.

An RST page may include the broader history of a title, information about its development, purpose, and place in gaming culture.

An RSP page may describe a particular regional, model-specific, or market-specific product, including its name, localization, and differences from other products under the same title.

An RSR page may examine a particular release: its production run, reissue status, presentation, markings, and other repeatable features.

An RSC page preserves the history of one specific physical item.

For compilations, multicarts, and devices with built-in games, users may publish research into the contents, menu, and origins of the included versions.

An article, link, or photograph found online does not allow a user to create a new RST, RSP, or RSR independently. User-driven catalog growth begins with a personal RSC.

Yes.

During moderation and after publication, the administration may:

• correct grammar, spelling, and punctuation;
• change headings and reorganize the text;
• remove repetition and unnecessary passages;
• clarify wording and factual statements;
• rewrite the text substantially while preserving the meaning contributed by the user;
• remove unnecessary personal data and unsafe links.

If an edit changes the intended meaning, the author may report the issue to moderation.

Yes.

A photograph may be hidden or removed when it:

• does not relate to the entry;
• duplicates other images;
• is too poor in quality to be useful;
• was taken from the internet or belongs to someone else;
• does not pass verification that it shows the claimed RSC;
• contains unnecessary personal data;
• contains prohibited material;
• violates another person’s rights;
• creates a security risk;
• is no longer useful to the catalog;
• violates the Retrostock rules.

Detailed rules for photograph moderation are set out in the Terms of Service.

Without a lawful basis, users should not publish:

• another person’s address or phone number;
• another person’s email address;
• private messages;
• photographs of identity documents;
• home addresses;
• payment details;
• other private information.

The administration may hide, anonymize, or remove such material.

At this stage, Retrostock does not publish the dumps themselves.

Research may include checksums, file size, observable differences, comparison results, and other information that helps identify the contents.

The catalog exists to document and research physical items, not to distribute copies of games or firmware.

Yes.

A review may be left after a confirmed interaction, such as an accepted internal offer.

This helps protect the system from:

• spam;
• artificial rating manipulation;
• reviews left without any real contact;
• targeted abuse.

An accepted offer confirms that an interaction took place, but it does not guarantee that an external transaction was completed successfully.

The basic version may include:

• an overall rating;
• a written comment.

Additional categories may be introduced later, such as:

• communication;
• reliability;
• accuracy of the item description;
• whether agreements were honored.

No.

Simply hiding a profile does not reset reviews or interaction history.

After an account is closed, reviews may remain in anonymized form when there is a valid basis for retaining them.

A review may be hidden or removed if it violates the service rules, another person’s rights, or applicable legal requirements.

Reviews may use a double-blind publication system:

• they become visible after both parties have submitted a review;
• or after a specified review period has ended.

A disputed review may be appealed to moderation. Disagreeing with a rating alone is not necessarily grounds for removal.

Yes. A listing may include not only an RSC code, but any permanent Retrostock code:

• RSU — the participant number;
• RST — the title;
• RSP — the specific product;
• RSR — the release;
• RSC — the individual physical copy.

For example, RSC000000077 can be added to a marketplace description, private message, social post, or forum thread.

The code can be searched either within the marketplace itself—such as Avito, Meshok, or eBay—or through a regular search engine.

A marketplace URL is temporary: the listing may be removed, moved, or reposted at a different address.

An RSC code belongs to the physical item itself and does not tie it to:

• one seller profile;
• one listing;
• one marketplace;
• the current owner.

The same code can be searched across different marketplaces or through a search engine even after the item changes owners and appears in a new listing.

The RSC remains the same and continues to preserve the item’s history regardless of where or when it was offered for sale.

No.

Retrostock does not guarantee:

• a user’s identity;
• their ability to pay;
• their legal ownership of an item;
• the authenticity of an item;
• its condition or completeness;
• that the item matches the photographs and description;
• that either party will honor an agreement.

Profiles, reviews, RSCs, and item history are informational tools, not a guarantee that a transaction is safe.

Retrostock is not the seller, buyer, broker, guarantor, or shipping provider.

The service does not conduct the transaction and does not confirm that either party has fulfilled their agreement.

Payment, shipping, in-person exchange, trades, and other actions are arranged by the users themselves and carried out at their own risk.

Users should independently verify:

• the identity and reputation of the other party;
• current photographs of the item;
• condition and completeness;
• serial numbers and markings;
• whether the item matches the stated RST, RSP, and RSR;
• whether the photographs match the specific RSC, when one exists;
• the terms of payment, shipping, or an in-person meeting.

Do not post payment details, identity documents, or other sensitive information in public Retrostock fields.

Retrostock may review violations of its own rules, including:

• spam;
• misrepresentation or substitution of data;
• duplicate entries;
• harassment or insults;
• abuse of service features;
• publication of prohibited material;
• unauthorized disclosure of personal data.

Retrostock is not required to arbitrate disputes involving external payment, shipping, sales, trades, or the performance of private agreements.