Node Provisioning API
Dynamically provision nodes and receive staking transactions to sign.
What is the Node Provisioning API?
The Node Provisioning API allows partners to programmatically spin-up nodes for staking. Partners specify the number of nodes needed and receive a transaction to sign that stakes with those node/s.
Chain | Assets per Node |
32 ETH per Validator | |
1,000 DASH per Masternode | |
Horizen | 500 ZEN per Supernode |
Keep | 100,000 KEEP per Node |
ETH2
Provision validators with an API request and submit the deposits through a single ETH1 transaction.
Integration Environments
Staked supports integration testing on ETH2, as defined below.
Base URL | Target ETH Network |
---|---|
https://mainnet.staked.cloud/api | Mainnet |
https://testnet.staked.cloud/api | Holeksy |
Post ETH2 Provisioning Request
POST
https://mainnet.staked.cloud/api/provisioning_requests/eth2
Provision ETH2 validators in our secure cloud environments. The response contains a unique identifier for the provisioning request.
Query Parameters
Name | Type | Description |
---|---|---|
api_key | string | Your API Key - (Must have ETH2 access) |
Request Body
Name | Type | Description |
---|---|---|
attributes | object | ETH2 Attributes Object |
ETH2 Attributes Object
Field | Description | Type | Required |
---|---|---|---|
| Ethereum wallet address which will be used to create withdrawal credentials for the validator (consensus layer reward recipient) |
|
|
| Optional: A payable Ethereum address that will receive execution layer payments. Note: if none is provided, payments will be sent to the withdrawal credential. |
|
|
| Optional: Specify that these validators should receive execution layer fees on an separate address. Note: This groupKey and its associated recipient address must be registered and confirmed with Staked in advance before it is valid to be used in provisioning requests. |
|
|
| Array of validator config objects |
|
|
Validator Config Object
Field | Description | Type |
provider | Validator provider enum: "decentralized" or "amazon" | String |
count | Number of validators to provision | Number |
Provisioning Response Object
Field | Description | Type |
id | Numbered identifier of provisioning request | String |
uuid | Unique identifier of provisioning request | String |
created | Provisioning request creation datetime | String |
status | Provisioning request status - "CREATED" | String |
chain | Chain identifier - "ETH2" | String |
user_id | User identifier - returns null unless using oauth | String |
partner_id | Partner identifier associated with api key | String |
attributes | ETH2 attributes object | Object |
Get ETH2 Delegation Objects
GET
https://mainnet.staked.cloud/api/delegations/eth2
After POSTing a provisioning request, use the unique identifier to GET the delegation objects for each validator. Delegation objects contain the information required to submit deposits on ETH1.
Query Parameters
Name | Type | Description |
---|---|---|
api_key | string | Your API Key - (Must have ETH2 access) |
filters | string | provisioning_request_uuid:YOUR UUID |
page | number | Page of results to fetch |
per_page | number | Number of results per page |
Validators are provisioned asynchronously, meaning the GET request will fill-in over time as our infrastructure fulfills the associated provisioning request. Use the "total" field in the response object to track the number of validators provisioned at any given time.
Paginated Response Object
Field | Description | Type |
results | Array of ETH2 delegation objects | Array |
page | Page of fetched results | Number |
pages | Total number of pages | Number |
per_page | Number of results per page | Number |
total | Number of results in total | Number |
ETH2 Delegation Object
Field | Description | Type |
id | Identifier of delegation object | Number |
address | Validator public key | String |
chain | Chain identifier - "ETH2" | String |
attributes | ETH2 delegation attributes object | Object |
amount | Amount currently delegated | String |
created | Delegation object creation time | String |
status | ETH2 delegation status enum | String |
user_id | User identifier - returns null unless using oauth | String |
partner_id | Partner identifier associated with api key | String |
provisioning_request_uuid | Associated provisioning request unique identifier | String |
provisioning_request_id | Associated provisioning request numbered identifier | String |
ETH2 Delegation Attributes Object
Field | Description | Type |
cloud | Validator cloud configuration | String |
count | Total number of validators in associated provisioning request | Number |
index | Index of validator in associated provisioning request | Number |
depositInput | Validator deposit transaction data | String |
validatorKey | Validator public key | String |
ETH2 Delegation Status Enum
Value | Definition | Time Period |
CREATED | Validator was provisioned through Staked API | n /a |
DEPOSITED | Deposit is waiting to be seen by ETH2 chain | 0-6 Hours |
PENDING | Validator is in the queue waiting to go live | 0-6 Days |
ACTIVE | Validator is participating and earning rewards | n / a |
Submit Deposits through the Batching Contract
The canonical ETH2 deposit contract, used to convert ETH1 to ETH2, only supports one deposit transaction at a time. Since 32 ETH is required for each validator, depositors with large amounts of ETH would have to broadcast many deposit transactions.
To simplify submitting deposits, we have created a batching contract which takes up to 185 deposits at once and submits each to the deposit contract. Integrators can therefore stake up to 5920 ETH in one Ethereum transaction, and leave behind the hassle of tracking many individually broadcasted transactions.
Batching Contract Deployments
ETH2 Network | Batching Contract Address |
---|---|
Mainnet | |
Holesky |
The batching contract contains an external payable function, batchDeposits
, which loops over each validator's deposit and sends them to the deposit contract. The function arguments are passed as a 2-d array where the array at [i]
represents the deposit arguments for validator i
.
For release notifications of the ETH2 API and developer tools, click here.
Dash
Automate provisioning of Dash masternodes.
Integration Environments
Staked supports integration testing on Dash, as described below.
Base URL | Dash Network |
https://mainnet.staked.cloud/api | Mainnet |
https://testnet.staked.cloud/api | Testnet |
Email sam@staked.us for testnet Dash, or request it in the Dash Discord. Staked will support 2 masternodes per partner account in a testnet environment.
Getting Started
Each masternode requires an unspent transaction output (UTXO) of exactly 1,000 DASH. The address that owns this UTXO is the collateral address.
Instructions below assume use of the dash command line tool or debug console in the GUI wallet. If using the debug console, please remove dash-cli
from the beginning of each command.
Create a new address to hold your masternode collateral.
dash-cli getnewaddress <address-alias>
Example
dash-cli getnewaddress masternode_collateral_1
Next, send exactly 1,000 Dash to your collateral address.
dash-cli sendtoaddress <address> <amount>
Example
dash-cli sendtoaddress yTrtvsNuVgezcGmcVyv2n8D2dFeJEHCYhg 1000
Get the transaction id and output index of the transaction you just created (you may need to wait up to 2 minutes until your transaction is added to a block).
dash-cli masternode outputs
A payout address is also needed and can be generated using the getnewaddress
command. A single payout address can be shared across masternodes.
Step 1: Post Masternode Provisioning Request
POST
https://mainnet.staked.cloud/api/delegations/DASH/delegator/:collateralAddress
Provision a new masternode after sending 1,000 DASH to a collateral address.
Path Parameters
Name | Type | Description |
---|---|---|
collateralAddress | string | Your collateral address |
Query Parameters
Name | Type | Description |
---|---|---|
api_key | string | Your api key |
Headers
Name | Type | Description |
---|---|---|
Content-Type | string | application/json |
Request Body
Name | Type | Description |
---|---|---|
attributes | object | Using example from pre-reqs: { "collateralHash": "3483e20a675d7585f0...", "collateralIndex": 1, "payoutAddress": "Payout address here" } |
Step 2: Poll Masternode Status
GET
https://mainnet.staked.cloud/api/delegations/DASH/delegator/:collateralAddress
Poll the masternode status. The status is initially set as CREATED
. Once the masternode registration message is created through Staked's provisioning infrastructure the response will pass the message for signing along with a status of WaitingForSigning
.
Path Parameters
Name | Type | Description |
---|---|---|
collateralAddress | string | Your collateral address used previously. |
Query Parameters
Name | Type | Description |
---|---|---|
api_key | string | Your API Key |
Step 3: Sign Delegation Message
This must be run on the wallet or device that holds collateral key, and can be done completely offline if required. signMessage
is returned in the response of the previous step.
Example Output:
Step 4: Send Us the Signed Delegation Message
PUT
https://mainnet.staked.cloud/api/delegations/DASH/delegator/:collateralAddress
Finally, send Staked the signed transaction and we will broadcast it to the Dash blockchain!
Path Parameters
Name | Type | Description |
---|---|---|
collateralAddress | string | Masternode collateral address set up previously. |
Query Parameters
Name | Type | Description |
---|---|---|
api_key | string | Your API Key |
Request Body
Name | Type | Description |
---|---|---|
attributes | string | { "signedTx": "Your Signed Message" } |
status | string | Set as "WaitingtoSubmit" |
The status of the delegation object is now WaitingToSubmit
. When the Masternode is synched, the signedTx will be submitted and the status will be Ready
.
Boom! You've programmatically set up a Masternode. Check out the Reporting API to monitor your position.
Last updated