Jupiter Faucet is a perpetual cycles top-up protocol for the
Internet Computer - built to help canister smart contracts keep running
indefinitely. The
Internet Computer is designed for tamper-proof, "unstoppable" on-chain services; Jupiter
Faucet focuses on the practical part: making sure canisters don’t run out of
cycles, even if nobody is maintaining the project.
The perpetual top-up workflow is intentionally designed to be so simple that anyone can
carry it out as a one-off operation directly from NNS dapp
using the enhanced transfer and memo flow - no further setup required.
See How It Works for more information.
Jupiter Faucet is built to propel big burners, including
cycle-intensive on-chain AI workloads such as WORDY,
helping projects get the most out of ICP→cycles conversion over the long run.
Due diligence:
Jupiter Faucet is open source, reproducibly buildable, and designed to
decentralize control over time.
The frontend is accessible via multiple domains controlled by independent parties.
The core components will be blackholed. A worst-case scenario
lifeline is built into the canisters so they can temporarily hand control to the
SNS DAO if a breaking change in a NNS-managed platform dependency prevents disbursals
or other core functionality, then blackhole themself again once service resumes.
Featured Projects Powered by Jupiter Faucet
If you'd like to see your project here, please start a discussion on one of Jupiter Faucet's
social channels
and/or
raise a pull request
that includes your project.
Jupiter Faucet runs on the
Internet Computer.
The frontend can be served
through more than one web origin, but DNS still depends on ordinary domain registrars and
gateway routing today. Work toward decentralized DNS
is ongoing; until then, independent
parties can publish and manage domains that point at the same certified frontend canister.
Managed by DFINITY through the default ICP HTTP gateway canister URL.
Anyone can register their own domain by following the
ICP custom domains documentation.
Raise a pull request
or start a discussion in one of Jupiter Faucet's
social channels
if you'd like to see another independently managed domain listed here.
Source Code
Jupiter Faucet is composed of a suite of smart contracts that are all
open source.
Anyone can verify that the system components have been built from this source code by cloning the repository and running the
reproducible build script.
The build hashes produced should match the Wasm module hashes currently deployed on mainnet.
The Wasm module hashes and controllers below are retrieved on-chain from the IC management canister (`aaaaa-aa`) via `canister_info`.
Once Jupiter Faucet is governed by an
SNS DAO, changes to these mainnet components will need to pass through consensus.
Serves the certified frontend assets and dashboard UI (this website).
Governance
Jupiter Faucet is moving toward SNS DAO control. Until the SNS launches, the suite
is being developed by Alex Lorimer,
the controller of the LORIMER ♾️ 🐶 known neuron,
a well-known ecosystem participant, so the remaining launch work can be completed, reviewed, and upgraded quickly.
The system is open source,
and its canister Wasm modules are intended to be verified through
reproducible builds
against the module hashes shown in the Source Code pane. All Jupiter Faucet suite canisters reside on either the Fiduciary or SNS subnet (both composed of over 30 nodes) for superior deterministic decentralization, resilience and security.
Blackholing:
The core value-moving canisters, Jupiter Disburser and Jupiter Faucet,
are intended to become blackholed, meaning their behavior will be locked in and no party will be able to alter them.
A narrow recovery path remains for a breaking change in an underlying Internet Computer system API
(NNS-managed code):
the affected canister can hand
control to the lifeline canister, which is controlled by the SNS DAO, so the DAO can restore service and then
return the canister to a blackholed state. After the Jupiter Faucet SNS has launched and the system has run for
at least six months without signs of weak points or a need for patching, a DAO proposal will be submitted to arm
the built-in trigger that causes both canisters to blackhole themselves.
How it works
The top-up process is intentionally simple: transfer at least
1 ICP directly into the staking account of
Jupiter Faucet's canister-controlled neuron
and set your declared canister ID as the transaction
memo (see example below). You do not need to be the owner of the canister.
1. If the memo field is hidden in the NNS dapp, press Ctrl + K, type memo, then select Show transaction memo.Optional. Add the Jupiter Faucet staking account to your NNS dapp address book with a nickname to make future commitments easier.2. Use the staking account address shown above, enter the ICP amount, and set the transaction memo to your declared canister ID.
That’s it. With your memo declaring a canister, that canister becomes the recipient
of perpetual cycles top-ups, funded by the stake’s ongoing
rewards.
You can monitor Jupiter Faucet top-ups to your canister via the
memo tracker.
You can estimate how much ICP needs to be committed to the Jupiter Faucet stake to keep your canister
perpetually topped up using the simulator.
Developer tip: If you need many small ICP transfers to build up to
the minimum 1 ICP threshold, you might consider deploying an instance of the
Jupiter Relay
canister.
Base maturity: 100% of the base (non age-bonus)
maturity generated from committed stake for topping up cycles is used to perpetually
burn ICP, mint cycles, and top up the declared canister over time.
Age bonus maturity: the age-bonus component (between
0% and 20% of total maturity depending on stake age) is split
into:
• 0%–19% distributed to SNS jUP stakers in the form of newly minted IO (a liquid staking protocol that will be launched alongside Jupiter Faucet)
• 0%–1% restaked into the
D-QUORUM
neuron to help fund decentralized due diligence of NNS proposals, because a prerequisite for truly unstoppable canisters is a secure and decentralized network.
Rewards:
jUP SNS tokens will be minted to patrons who have
committed ICP
to the staking account
of Jupiter Faucet's neuron
(following the rules described). Contributions must meet the requirements in order to be counted (transactions of at least 1 ICP featuring a memo that declares a canister ID or neuron ID).
While the Jupiter Faucet SNS rewards components are still being finalized the ICP will accumulate in the
rewards account
(reserved until SNS launch). See Governance for more info.
Advanced Usage
Jupiter Faucet supports three memo-directed flows. A plain declared canister ID keeps
the default perpetual cycles top-up behavior. Advanced users can instead route ICP
minted from maturity directly to either the default account of a declared canister or
the staking account of a declared public NNS neuron.
To enable raw ICP transfer mode for a canister, add a full stop character
('.') after the declared canister ID in the ICP commitment memo.
To target a public neuron instead, use the neuron ID in the memo. In either mode,
the full stop may be followed by optional text; Jupiter Faucet uses that optional
text as the outgoing memo on the perpetual ICP transfer. Declared neurons must be
'public' in order for Jupiter Faucet to derive their staking accounts.
The full ICP commitment memo must be ASCII and at most 32 characters.
For canister targets, hyphens in the principal may be omitted to save space. Use the
memo builder
to build a valid memo.
Developer tip: You can adjust the canister/neuron,
title, and label parameters in the following URL to customize the memo helper
form for a smoother user experience:
#memo-builder?canister={protocol canister ID}&title={custom title}&label={custom label}
e.g.
ONICAI's mAIner ID Memo Builder
tops up the protocol's GameState canister with raw ICP; GameState then routes a
portion as cycles to the declared mAIner.
IO's IO Perpetual Stake Memo Builder
causes Jupiter Faucet to perpetually pay into the IO neuron's staking account,
driving an ever-increasing minimum APY for all IO holders. In this particular
case a '.' suffix is superfluous.
Relay Canisters
A relay canister provides one stable destination for ICP transfers. It aims to maintain
a steadily growing cycles balance for configured target canisters by topping up 1% more
cycles than needed to restore the previously sampled balance for each configured
canister (provided enough ICP is perpetually supplied into the relay canister).
Target requirement: Every Relay target canister must make its cycles
balance publicly observable so the Relay can measure consumption and calculate each
top-up. See Cycles Observability
on the next slide.
Example: The full suite of Jupiter Faucet protocol canisters are managed by a single
relay canister.
Anyone who wishes to contribute an ICP commitment can use the
Relay Canister Memo Builder,
optionally supplying their name as a memo suffix (identifying them for their good
deed).
This flow depends on raw ICP top-ups described in the
Advanced Usage
section. This ensures Jupiter Faucet perpetually transfers raw ICP rather than
directly topping up the relay canister with cycles. The relay canister then uses
that raw ICP to keep itself topped up along with configured canisters. Surplus ICP
(if any) can then be routed to a configured DAO treasury or other account. The
Jupiter Faucet protocol's own relay canister routes 50% of any surplus ICP back into
the Jupiter Faucet neuron itself (forever increasing the rate of future
maturity-minted ICP back into the relay). The relay routes remaining surplus ICP
into the IO neuron's staking account (described below).
Anyone can deploy their own relay canister (specifying their own selection of target
canisters they wish to be kept topped up). There are two options:
The easiest path to deploying a relay canister is to use the
Relay Setup
tool (any surplus ICP will automatically be routed to the IO neuron staking
account, increasing the minimum APY for all IO holders and therefore increasing
the value of
rewards for jUP stakers).
Alternatively, developers can pull the
source code
and deploy an instance manually specifying their own selection of surplus accounts.
Developer tip: A relay canister also accepts ICP transfers into its
'1' subaccount (e.g. u2qkp-aqaaa-aaaar-qb7ea-cai.1). This
is intended to support ICP senders who do not have support for ICRC memos, or who
wish to grow their Jupiter Faucet commitment with many small ICP transfers (each
below the 1 ICP minimum Jupiter Faucet threshold).
The relay canister allows many small ICP transfers to accumulate before it
transforms these into a single ICP commitment that meets or surpasses the minimum
1 ICP threshold. The relay canister's own ID is used in the ICP commitment memo such
that it will perpetually receive raw ICP from Jupiter Faucet maturity.
Cycles Observability
Registering a canister through a qualifying memo commitment tells the
Memo Tracker
what to track. Its cycles balance can be displayed through one of these routes:
Recognized blackhole: An ordinary target is observable when either the
13-node blackhole
or the
Fiduciary blackhole
is one of its controllers. Both are immutable, run the same independently reproducible
blackhole Wasm documented by DFINITY,
and can only make canister status public. Adding either as an additional controller
introduces no trusted operator and does not remove existing controllers; it simply lets
the Memo Tracker
read the target's cycles balance.
SNS routes: Deployed SNS canisters and dapps governed by an SNS can be
observed through that SNS. These targets do not need a recognized blackhole controller.
TL;DR: Non-SNS target canisters require a recognized blackhole controller
if you want cycles history displayed in the
Memo Tracker;
cycles for SNS-governed dapps are observable by default. Newly tracked canisters may remain
pending until their initial probe or the next cycles sweep completes. While
Jupiter Faucet
perpetually tops up target canisters whether or not their cycles are publicly observable,
Jupiter Relay
target canisters must expose their cycles so the Relay can calculate how much each needs.
Memo Builder
Memo Builder
This memo helper simplifies constructing a memo from your chosen ID and a protocol
canister that facilitates a specialized top-up flow.
Health & Safety Notice: Please make sure that you have identified
the controller of the protocol canister
and that it belongs to a DAO or reputable pre-DAO dev team who prescribe this
canister. Jupiter Faucet
is not responsible for lost funds resulting from user indiscretion.
Use the generated memo as described in the
basic instructions
(in place of the "declared canister ID") to make your ICP commitment and initiate
perpetual top-ups.
For more information about this memo builder see
Advanced Usage.
Jupiter Stake
Direct ICP ledger balance plus public NNS neuron details.
The Jupiter neuron is publicly visible on the ICP dashboard. Its maturity is disbursed to the controlling disburser canister before being routed to the faucet, SNS rewards, and D-QUORUM destinations shown on the following pages.
Historian tracks the aggregate; recent rows are queried live from the ICP index canister.
Total Output counts ICP routed from the disburser staging account to the faucet payout account.
Total output
Timestamp
Amount
Tx ID
Loading…
Page 1
Total Rewards
Historian tracks the aggregate; recent rows are queried live from the ICP index canister.
Total Rewards counts ICP routed from the disburser staging account to the SNS rewards account.
Total rewards
Timestamp
Amount
Tx ID
Loading…
Page 1
D-QUORUM Route
Recent rows are queried live from the ICP index canister.
D-QUORUM Route shows ICP routed from the disburser staging account to D-QUORUM's staking account.
D-QUORUM routed shown
Timestamp
Amount
Tx ID
Loading…
Page 1
Patron Commitments
Loading next historian run…
See How It Works for qualifying commitment rules. This table shows a bounded recent view; full transfer history remains durably queryable from the ICP ledger and its archive canisters.
Declared Canisters
Timestamp
Amount
Declared
Loading…
Page 1
See Advanced Usage for raw ICP commitment rules. This table shows a bounded recent view; full transfer history remains durably queryable from the ICP ledger and its archive canisters.
Declared Raw ICP Canisters
Timestamp
Amount
Declared
Loading…
Page 1
See Advanced Usage for neuron commitment rules. This table shows a bounded recent view; full transfer history remains durably queryable from the ICP ledger and its archive canisters.
Declared Neurons
Timestamp
Amount
Declared
Loading…
Page 1
Memo Tracker
Inspect memo-based cycle top-ups, raw ICP canister inflows, and public neuron staking-account inflows.
Paste the memo you used. Plain canister memos open cycle top-up tracking; dotted canister memos show raw ICP into the target canister account; numeric memos show public neuron staking-account inflows.
Relay Setup
Create an immutable Jupiter Relay for one to twenty target canisters without login.
Setting up a dedicated relay canister can help to optimize cycles allocation and simplify integration with other protocols, as well as boost jUP staking rewards when cycles supply exceeds demand. Read more about what a relay canister is and how it works and set up a new relay using the instructions below.
Individual target canisters may be covered as part of more than one Relay. Submitting the exact same target set returns the existing Relay (an exact duplicate is prevented). The target set is immutable after Relay creation.
Setup funding is an aggregate deposit to this target set’s deterministic Historian subaccount. Deposits are not attributed to individual payers and are not automatically refundable.
Simulator
Model how much ICP you may need to commit for a declared canister so Jupiter Faucet's recurring maturity can keep pace with the canister's daily cycles burn.
Cycles per ICP
—
ICP/XDR rate source
—
Projected annual ICP to CMC
—
Projected annual cycles
—
Projected annual burn
—
Age bonus diverted
—
Effective top-up APY
—
Year-end projected balance
—
Break-even commitment
—
TOP
UPS
JUPITER
FAUCET
Powers unstoppable dapps running on a public World Computer by delivering a simple, set-and-forget, perpetual top-up solution that's trustless, permissionless and immutable. Adopters receive front-loaded jUP SNS airdrops. → How?