Welcome to our Help Center.


Our Help Center is designed to give you a place to get the information you need to be effective at using our site.

You can find information by browsing the sections and categories on the left hand dropdown menu (top if you have a very small screen)

We appreciate any feedback regarding the design of the help center, or new bits of information to add, including tutorials; You can open a ticket with us at any time.

 

Mining Rig Rentals may add new mining algorithms when there is enough demand and when the algorithm can be supported reliably through our rental system.

If you want us to consider adding a new algorithm, please provide enough technical information for us to test it. An algorithm name alone is usually not enough. Many coins use modified algorithms, custom stratum behavior, different parameters, or pool-specific requirements.

Providing complete information helps us determine whether the algorithm can be added safely and whether rentals will work correctly for both rig owners and renters.


New algorithm requests are reviewed

Submitting a request does not guarantee that the algorithm will be added.

Before adding a new algorithm, Mining Rig Rentals needs to consider:

  • whether the algorithm is actively used,
  • whether working pools exist,
  • whether mining software is available,
  • whether the protocol is compatible with our system,
  • whether accepted shares can be verified,
  • whether hashrate can be measured correctly,
  • whether the algorithm is different from existing supported algorithms,
  • whether there is enough expected renter or rig-owner demand.

Some requests may be declined if the algorithm is inactive, too niche, technically incompatible, unsafe to proxy, or not practical to support.


Information required for a new algorithm request

When requesting a new algorithm, include as much of the following information as possible.

Algorithm details

Provide:

  • full algorithm name,
  • any common aliases,
  • exact variant or parameters,
  • coin or coins using the algorithm,
  • whether the algorithm is a fork or modification of another algorithm,
  • whether it requires special personalization strings, seed data, or extra parameters.

Be precise. For example, “Equihash” alone is not enough because there are many Equihash variants.


Coin information

Provide at least one coin that currently uses the algorithm.

Include:

  • coin name,
  • coin ticker,
  • official website,
  • official wallet or node software,
  • block explorer if available,
  • coin documentation if available,
  • mining documentation if available.

The coin should be active and mineable. If the coin has no working pool, no working miner, or no active network, we may not be able to test it.


Pool information

Provide a working mining pool for the algorithm or coin.

Include:

  • pool website,
  • pool stratum URL,
  • pool port,
  • whether the port uses TLS/SSL,
  • required username or wallet format,
  • required password field,
  • worker name format,
  • fixed difficulty options if available,
  • regional pool servers if available.

If possible, provide pool credentials or a wallet address that can be used for testing. This allows any test mining rewards to go to the correct destination instead of being wasted.

Make sure the pool is currently online and accepting miners before submitting the request.


Mining software

Provide mining software that supports the algorithm.

Include:

  • miner software name,
  • official download or source link,
  • supported operating systems,
  • supported hardware type,
  • miner version tested,
  • command line used to mine,
  • configuration file example if applicable,
  • any required special flags,
  • whether the miner supports stratum,
  • whether the miner reports accepted, rejected, and stale shares.

The command line or configuration example should be complete enough that we can reproduce your test.

Example information to include:

Miner software:
Version:
Operating system:
Hardware:
Pool URL:
Pool port:
Wallet/username format:
Password field:
Command line:
 

Hardware and hashrate

Provide information about the hardware used for testing.

Include:

  • ASIC model, GPU model, CPU model, or other hardware type,
  • number of devices,
  • operating system or firmware version,
  • expected hashrate,
  • hashrate shown by the miner,
  • pool-side hashrate if available,
  • accepted share rate,
  • rejected share rate,
  • stale share rate.

This helps us understand expected hashrate units, share frequency, and difficulty behavior.

For example:

Hardware: 2x RTX 3080
Miner-reported hashrate: 000.00 MH/s
Pool-side hashrate: 000.00 MH/s
Accepted shares after 10 minutes: 00
Rejected shares: 0
Stale shares: 0
 

Confirm accepted shares before submitting

Before requesting a new algorithm, test the miner directly against the pool.

Confirm that:

  • the miner connects successfully,
  • the pool authorizes the miner,
  • jobs are received,
  • accepted shares increase,
  • rejected shares are low,
  • stale shares are low,
  • pool-side hashrate appears,
  • the miner remains connected.

A miner that only connects but does not submit accepted shares is not enough for algorithm review.

Accepted shares are required to prove that the miner, pool, and algorithm configuration are working.


Algorithm variants matter

Many mining issues happen because the algorithm name is incomplete or ambiguous.

Examples of algorithm families with multiple variants include:

  • Equihash,
  • CryptoNight,
  • Ethash-style algorithms,
  • KawPow-style algorithms,
  • X11-family algorithms,
  • Blake variants,
  • Yescrypt variants,
  • ProgPoW variants.

If the algorithm has parameters, personalization strings, fork-specific changes, or coin-specific modifications, include them in your request.

Do not assume that one variant is compatible with another because the names are similar.


Optional: packet capture

In some cases, Mining Rig Rentals may ask for a packet capture to better understand the mining protocol or pool behavior.

A packet capture is not required for every request, but it can be useful when the algorithm uses unusual stratum behavior, custom messages, or undocumented protocol changes.

If you provide a packet capture, only capture the mining connection being tested.

Recommended approach:

  1. Install Wireshark or another packet capture tool.
  2. Find the IP address of the mining pool.
  3. Configure your miner to connect to that pool.
  4. Start a capture using a filter for only that pool IP.
  5. Start the miner.
  6. Let it mine until several shares are accepted.
  7. Stop the miner.
  8. Stop the capture.
  9. Save the capture file.
  10. Compress the file before sending it.

A capture filter may look like:

host 192.0.2.123
 

Replace 192.0.2.123 with the actual pool IP address.

Do not capture unrelated browsing, downloads, private traffic, or traffic from other devices. Packet captures may contain wallet addresses, worker names, IP addresses, and other connection details. Review what you are sending before sharing it.


What not to send

Do not send:

  • wallet private keys,
  • seed phrases,
  • exchange account credentials,
  • pool account passwords used for account login,
  • unrelated packet captures,
  • screenshots containing unrelated personal information,
  • miner downloads from unofficial or suspicious sources.

For testing, a public mining wallet address or worker name is usually enough.


Example new algorithm request

A good request should look similar to this:

Algorithm name:
Algorithm variant or parameters:
Coin name:
Coin ticker:
Coin website:
Wallet/node software:
Pool website:
Pool stratum URL:
Pool port:
TLS/SSL required:
Username or wallet format:
Password field:
Mining software:
Miner version:
Miner download/source link:
Operating system:
Hardware used:
Expected hashrate:
Miner command line:
Accepted shares observed:
Rejected shares observed:
Stale shares observed:
Pool-side hashrate:
Additional notes:
 

The more complete the request is, the easier it is for us to review.


Reasons an algorithm may not be added

An algorithm may not be added if:

  • no working pool is available,
  • no reliable mining software is available,
  • the coin network is inactive,
  • the algorithm is already covered by an existing category,
  • the algorithm variant is unclear,
  • test mining does not produce accepted shares,
  • hashrate cannot be measured reliably,
  • the pool uses unsupported protocol behavior,
  • the miner requires unusual manual intervention,
  • there is not enough expected demand,
  • the setup would create a poor renter or rig-owner experience.

Mining Rig Rentals must be able to support the algorithm reliably before making it available for rentals.


When to contact support

Contact Mining Rig Rentals support with your new algorithm request and include the technical details listed above.

At minimum, provide:

  • algorithm name and variant,
  • coin using the algorithm,
  • working pool URL and port,
  • mining software link,
  • working miner command line,
  • hardware used for testing,
  • observed hashrate,
  • proof that accepted shares were submitted.

If more information is needed, support may ask for logs, screenshots, or a packet capture.


Summary

Mining Rig Rentals is open to reviewing new algorithms, but a successful request needs technical detail.

The most important items are:

  • exact algorithm and variant,
  • active coin,
  • working pool,
  • working miner,
  • command line or configuration,
  • tested hardware,
  • observed hashrate,
  • accepted shares.

A complete request gives us the best chance to test the algorithm and determine whether it can be supported.