{this.prompter.message}
: null} {this.prompter.options ? ({this.account.publicKey}
{JSON.stringify(this.error, null, 2)}
) : null,
this.account ? (
) : null,
];
}
```
It looks messy, but it’s actually a pretty simple `.tsx` file rendering out our DOM based off a series of conditional values. You can see we’re including the `bantu-prompt` component, and setting the prompter prop to our `this.prompter` state. We then have a ternary operation toggling between a Create Account button and a basic account UI. If `this.account` has a truthy value, we’ll print out the account’s `publicKey` along with some interaction buttons. If `this.account` is falsey, we’ll print out a singular Create Account button connected to, you guessed it, the `createAccount` method. After that logic, we print out an error if there is one, and finally a Sign Out button if there’s an account to sign out of. Those are the two `Wallet` `@Component` events.
## Create Methods
Let’s look at the methods now beginning with the `./methods/createAccount.ts` file.
```typescript
import sjcl from "@tinyanvil/sjcl";
import { Keypair } from "stellar-sdk";
import { handleError } from "@services/error";
import { set } from "@services/storage";
export default async function createAccount(e: Event) {
try {
e.preventDefault();
const pincode_1 = await this.setPrompt("Enter a keystore pincode");
const pincode_2 = await this.setPrompt("Enter keystore pincode again");
if (!pincode_1 || !pincode_2 || pincode_1 !== pincode_2)
throw "Invalid pincode";
this.error = null;
const keypair = Keypair.random();
this.account = {
publicKey: keypair.publicKey(),
keystore: sjcl.encrypt(pincode_1, keypair.secret(), {
adata: JSON.stringify({
publicKey: keypair.publicKey(),
}),
}),
};
await set("keyStore", btoa(this.account.keystore));
} catch (err) {
this.error = handleError(err);
}
}
```
Aha! Finally something interesting. This method forms the meat of our component. Before we dive into it, though let’s install the missing `@tinyanvil/sjcl` package.
```bash
npm i -D @tinyanvil/sjcl
```
## Create an Account
Essentially all we’re doing is making a request to create an account, which triggers the Prompt modal to ask for a pincode. That pincode will be used in the `sjcl.encrypt` method to encrypt the secret key from the `Keypair.random()` method. We set the `this.account` with the `publicKey`, which encrypted the `keystore` cipher, and now we're storing that cipher in base64 format in `localStorage` via our `set('keyStore')` method for easy retrieval when the browser reloads. We could also encode that cipher into a QR code or a link to share with other devices. Since it requires the pincode that encrypted cipher, it's as secure as the pincode you encrypt it with.
## Copy Address
Now that we’ve created an account, there are three more actions we'll enable: `copyAddress`, `copySecret`, and `signOut`.
First `./methods/copyAddress.ts`
```typescript
import copy from "copy-to-clipboard";
export default async function copyAddress(e: Event) {
e.preventDefault();
copy(this.account.publicKey);
}
```
Well there you go, the easiest code you’ll see all day. Just `copy` the `publicKey` from the `this.account` object to the clipboard. Before we jump though don’t forget to install that `copy-to-clipboard` package.
```bash
npm i -D copy-to-clipboard
```
## Copy Secret
Next `./methods/copySecret.ts`
```typescript
import sjcl from "@tinyanvil/sjcl";
import copy from "copy-to-clipboard";
import { handleError } from "@services/error";
export default async function copySecret(e: Event) {
try {
e.preventDefault();
const pincode = await this.setPrompt("Enter your keystore pincode");
if (!pincode) return;
this.error = null;
const secret = sjcl.decrypt(pincode, this.account.keystore);
copy(secret);
} catch (err) {
this.error = handleError(err);
}
}
```
You may not actually include this in your production wallet, but for now it's a simple demonstration of how to programmatically gain access to the secret key at a later date for making payments, creating trustlines, etc. It’s essentially the `createAccount` in reverse: it asks for the pincode to decrypt the keystore which, once decrypted, we `copy` into the clipboard.
## Sign Out
Finally `./methods/signOut.ts`
```typescript
import { remove } from "@services/storage";
import { handleError } from "@services/error";
export default async function signOut(e: Event) {
try {
e.preventDefault();
const confirmNuke = await this.setPrompt(
"Are you sure? This will nuke your account",
"Enter NUKE to confirm",
);
if (!confirm || !/nuke/gi.test(confirmNuke)) return;
this.error = null;
await remove("keyStore");
location.reload();
} catch (err) {
this.error = handleError(err);
}
}
```
It’s important to allow users to nuke their account, but we need to be careful to confirm that action with our faithful `setPrompt`. Once they opt to “NUKE” the account we can remove the `keyStore` and reload the app.
## Set Prompt
Speaking of `setPrompt` the last method in our `wallet.ts` file is `./methods/setPrompt.ts`.
```typescript
export default function setPrompt(
message: string,
placeholder?: string,
options?: Array{this.account.publicKey}
{JSON.stringify(this.error, null, 2)}
) : null,
loHas(this.account, "state") ? (
{JSON.stringify(this.account.state, null, 2)}
) : null,
this.account
? [
,
,
]
: null,
];
}
```
Yikers amirite!? Don’t worry though: it’s actually quite simple if you’ve spent any time with HTML in JS before. What we're looking at are a few ternary operators toggling the UI between different states based on the account status. Basically just a bunch of buttons wired up to their subsequent actions. Turns out creating those buttons is next on our to-do list!
## Create Buttons
`updateAccount` and `makePayment` are new; `createAccount` will just need a few tweaks. Let’s start with that one.
```typescript
import sjcl from "@tinyanvil/sjcl";
import axios from "axios";
import { Keypair } from "stellar-sdk";
import { handleError } from "@services/error";
import { set } from "@services/storage";
export default async function createAccount(e: Event) {
try {
e.preventDefault();
const pincode_1 = await this.setPrompt("Enter a keystore pincode");
const pincode_2 = await this.setPrompt("Enter keystore pincode again");
if (!pincode_1 || !pincode_2 || pincode_1 !== pincode_2)
throw "Invalid pincode";
this.error = null;
this.loading = { ...this.loading, fund: true };
const keypair = Keypair.random();
await axios(
`https://friendbot.dev.bantu.network?addr=${keypair.publicKey()}`,
).finally(() => (this.loading = { ...this.loading, fund: false }));
this.account = {
publicKey: keypair.publicKey(),
keystore: sjcl.encrypt(pincode_1, keypair.secret(), {
adata: JSON.stringify({
publicKey: keypair.publicKey(),
}),
}),
};
await set("keyStore", btoa(this.account.keystore));
this.updateAccount();
} catch (err) {
this.error = handleError(err);
}
}
```
## Fund Account Using Friendbot
The only new thing we’re adding here — other than a loading state and an initial `this.updateAccount()` call at the end — is the call to [Friendbot](https://friendbot.dev.bantu.network), which is a testnet tool that we can use to automatically fund our new testnet account with 10,000 XBN. Nice little shortcut to kickstart our development.
```typescript
await axios(
`https://friendbot.dev.bantu.network?addr=${keypair.publicKey()}`,
).finally(() => (this.loading = { ...this.loading, fund: false }));
```
In production, you would have to find an actual source for funding the account. Some wallets fund users' accounts for them; some require the user to supply the funds.
So that’s the updated `./methods/createAccount.ts` file.
## Update Account Method
Now let’s create two new files for updating the account and making XBN payments.
```bash
touch src/components/wallet/methods/{updateAccount,makePayment}.ts
```
Let’s start with the simpler one, `./methods/updateAccount.ts`
```typescript
import { omit as loOmit, map as loMap } from "lodash-es";
import { handleError } from "@services/error";
export default async function updateAccount(e?: Event) {
try {
if (e) e.preventDefault();
this.error = null;
this.loading = { ...this.loading, update: true };
await this.server
.accounts()
.accountId(this.account.publicKey)
.call()
.then((account) => {
account.balances = loMap(account.balances, (balance) =>
loOmit(balance, [
"limit",
"buying_liabilities",
"selling_liabilities",
"is_authorized",
"last_modified_ledger",
balance.asset_type !== "native" ? "asset_type" : null,
]),
);
this.account = {
...this.account,
state: loOmit(account, [
"id",
"_links",
"sequence",
"subentry_count",
"last_modified_ledger",
"flags",
"thresholds",
"account_id",
"signers",
"paging_token",
"data_attr",
]),
};
})
.finally(() => (this.loading = { ...this.loading, update: false }));
} catch (err) {
this.error = handleError(err);
}
}
```
All we’re doing here is looking up the state of the Bantu account on the ledger and saving it to the `this.account.state`. You’ll also notice we’re omitting several fields from the account and balances for easier readability. You may choose to save these and selectively display the values you care about, but in our example we’re just displaying the raw JSON, so cleaning things up a little is the right move.
`this.account = {...this.account, state: loOmit(account, ['id', ...])}` may feel odd, but it’s just the Stencil way of updating a state’s object key to trigger a re-render of the DOM. You’ll notice `this.loading` follows the same pattern. We’ll make use of this data further down in the `render` method, but for now just know this is how we would grab ahold of the account to get the latest state.
## Make Payment Method
Next let’s break down the main subject method for this tutorial, `./methods/makePayment.ts`:
```typescript
import sjcl from "@tinyanvil/sjcl";
import {
Keypair,
Account,
TransactionBuilder,
BASE_FEE,
Networks,
Operation,
Asset,
} from "stellar-sdk";
import { has as loHas } from "lodash-es";
import { handleError } from "@services/error";
export default async function makePayment(e: Event) {
try {
e.preventDefault();
let instructions = await this.setPrompt("{Amount} {Destination}");
instructions = instructions.split(" ");
const pincode = await this.setPrompt("Enter your keystore pincode");
if (!instructions || !pincode) return;
const keypair = Keypair.fromSecret(
sjcl.decrypt(pincode, this.account.keystore),
);
this.error = null;
this.loading = { ...this.loading, pay: true };
await this.server
.accounts()
.accountId(keypair.publicKey())
.call()
.then(({ sequence }) => {
const account = new Account(keypair.publicKey(), sequence);
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET,
})
.addOperation(
Operation.payment({
destination: instructions[1],
asset: Asset.native(),
amount: instructions[0],
}),
)
.setTimeout(0)
.build();
transaction.sign(keypair);
return this.server.submitTransaction(transaction).catch((err) => {
if (
// Paying an account which doesn't exist, create it instead
loHas(err, "response.data.extras.result_codes.operations") &&
err.response.data.status === 400 &&
err.response.data.extras.result_codes.operations.indexOf(
"op_no_destination",
) !== -1
) {
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET,
})
.addOperation(
Operation.createAccount({
destination: instructions[1],
startingBalance: instructions[0],
}),
)
.setTimeout(0)
.build();
transaction.sign(keypair);
return this.server.submitTransaction(transaction);
} else throw err;
});
})
.then((res) => console.log(res))
.finally(() => {
this.loading = { ...this.loading, pay: false };
this.updateAccount();
});
} catch (err) {
this.error = handleError(err);
}
}
```
This method is quite massive, so let’s break it down further so it's easier to understand exactly what is going on.
```typescript
export default async function makePayment(e: Event) {
try {
e.preventDefault()
let instructions = await this.setPrompt('{Amount} {Destination}')
instructions = instructions.split(' ')
const pincode = await this.setPrompt('Enter your keystore pincode')
if (
!instructions
|| !pincode
) return
```
We’re going to need a couple pieces of info from the user: the amount of XBN to send, what address to send it to, and the pincode for unlocking the keystore file. We request those asynchronously and cancel out of the method if they aren’t provided.
```typescript
const keypair = Keypair.fromSecret(
sjcl.decrypt(pincode, this.account.keystore),
);
this.error = null;
this.loading = { ...this.loading, pay: true };
```
Next we unpack the keystore with the pincode, reset any existing errors, and trigger the `pay` loading boolean:
```typescript
await this.server
.accounts()
.accountId(keypair.publicKey())
.call()
.then(({sequence}) => {
const account = new Account(keypair.publicKey(), sequence)
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET
})
.addOperation(Operation.payment({
destination: instructions[1],
asset: Asset.native(),
amount: instructions[0]
}))
.setTimeout(0)
.build()
transaction.sign(keypair)
return this.server.submitTransaction(transaction)
```
From there we call the keypair account to retrieve its current sequence number so we can prepare a transaction with a payment operation. We set the destination and amount using the instructions from the prompt we collected and split earlier. Finally, we build, sign, and submit that transaction to the Bantu Expansion API server.
```typescript
.catch((err) => {
if ( // Paying an account which doesn't exist, create it instead
loHas(err, 'response.data.extras.result_codes.operations')
&& err.response.data.status === 400
&& err.response.data.extras.result_codes.operations.indexOf('op_no_destination') !== -1
) {
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET
})
.addOperation(Operation.createAccount({
destination: instructions[1],
startingBalance: instructions[0]
}))
.setTimeout(0)
.build()
transaction.sign(keypair)
return this.server.submitTransaction(transaction)
}
else throw err
})
```
If the account we want to send XBN is unfunded (and therefore doesn't yet exist on the ledger), we'll get back `op_no_destination`. This `catch` handles that issue by trying again with a `createAccount` operation. For any other issues we just pass the error on unmodified.
```typescript
})
.then((res) => console.log(res))
.finally(() => {
this.loading = {...this.loading, pay: false}
this.updateAccount()
})
}
catch (err) {
this.error = handleError(err)
}
}
```
Finally, we log any success transaction, kill the loader, and `updateAccount` to reflect the new balance in our account after successfully sending XBN. We also have our `catch` block that passes to the `handleError` service. We will render that in a nice error block in the UI.
There we go! That wasn’t so bad right? Pretty simple, and yet from this tutorial we have the power to hold and observe balances, and to make payments using the power of the Bantu ledger. Amazing!
# Handle Custom Assets
In this section of the tutorial, we'll add the ability to hold and transfer custom assets to the basic wallet we built in previous sections. It assumes that you've already completed Create a Basic Wallet and Make XBN Payments
## What's a Custom Asset?
Bantu allows anyone to easily issue an asset, and all assets can be held, transferred, and traded just like XBN, the network token. Every asset *other* than XBN exists on the network in the form of trustlines: an asset holder explicitly agrees to allow a balance of a specific token issued by a specific issuing account by creating a persistent ledger entry tied to the holding account. You can find out more in the guide to [creating custom assets](/issuing-assets/index).
Each trustline increases the user's [base reserve](/glossary/minimum-balance) by 0.5 XBN, and in this tutorial, we'll go over how to set up your wallet to create trustlines and manage the base reserve on behalf of a user.
## Add Trustlines Button
To enable custom asset handling, we need to modify three files and create one new one. Let’s start with our modifications. First up the `./events/render.tsx` file. We need to add a button for creating these new trustlines!
```typescript
import { h } from "@stencil/core";
import { has as loHas } from "lodash-es";
export default function render() {
return [
{this.account.publicKey}
{JSON.stringify(this.error, null, 2)}
) : null,
loHas(this.account, "state") ? (
{JSON.stringify(this.account.state, null, 2)}
) : null,
this.account
? [
,
,
]
: null,
];
}
```
If you look closely you’ll spot the Trust Asset button right below our `account-key` div. Nothing funky here, just a button that triggers `this.trustAsset` method which we’ll add in a moment.
Next up, let’s update the `./methods/makePayment.ts` file.
```typescript
import sjcl from "@tinyanvil/sjcl";
import {
Keypair,
Account,
TransactionBuilder,
BASE_FEE,
Networks,
Operation,
Asset,
} from "stellar-sdk";
import { has as loHas } from "lodash-es";
import { handleError } from "@services/error";
export default async function makePayment(e: Event) {
try {
e.preventDefault();
let instructions = await this.setPrompt("{Amount} {Asset} {Destination}");
instructions = instructions.split(" ");
if (!/xlm/gi.test(instructions[1]))
instructions[3] = await this.setPrompt(
`Who issues the ${instructions[1]} asset?`,
"Enter ME to refer to yourself",
);
const pincode = await this.setPrompt("Enter your keystore pincode");
if (!instructions || !pincode) return;
const keypair = Keypair.fromSecret(
sjcl.decrypt(pincode, this.account.keystore),
);
if (/me/gi.test(instructions[3])) instructions[3] = keypair.publicKey();
this.error = null;
this.loading = { ...this.loading, pay: true };
await this.server
.accounts()
.accountId(keypair.publicKey())
.call()
.then(({ sequence }) => {
const account = new Account(keypair.publicKey(), sequence);
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET,
})
.addOperation(
Operation.payment({
destination: instructions[2],
asset: instructions[3]
? new Asset(instructions[1], instructions[3])
: Asset.native(),
amount: instructions[0],
}),
)
.setTimeout(0)
.build();
transaction.sign(keypair);
return this.server.submitTransaction(transaction).catch((err) => {
if (
// Paying an account which doesn't exist, create it instead
loHas(err, "response.data.extras.result_codes.operations") &&
err.response.data.status === 400 &&
err.response.data.extras.result_codes.operations.indexOf(
"op_no_destination",
) !== -1 &&
!instructions[3]
) {
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET,
})
.addOperation(
Operation.createAccount({
destination: instructions[2],
startingBalance: instructions[0],
}),
)
.setTimeout(0)
.build();
transaction.sign(keypair);
return this.server.submitTransaction(transaction);
} else throw err;
});
})
.then((res) => console.log(res))
.finally(() => {
this.loading = { ...this.loading, pay: false };
this.updateAccount();
});
} catch (err) {
this.error = handleError(err);
}
}
```
This is a big file that was covered in great detail in the [Make XBN Payments](/building-apps/xbn-payments) tutorial, so we’ll just focus on the changes we need to make to support custom asset payments.
```typescript
let instructions = await this.setPrompt("{Amount} {Asset} {Destination}");
instructions = instructions.split(" ");
if (!/xlm/gi.test(instructions[1]))
instructions[3] = await this.setPrompt(
`Who issues the ${instructions[1]} asset?`,
"Enter ME to refer to yourself",
);
```
This change allows us to indicate a specific asset code we’d like use to make a payment and triggers an additional prompt to set the issuer for that asset if it’s not the native XBN.
```typescript
if (/me/gi.test(instructions[3])) instructions[3] = keypair.publicKey();
```
This is just a nifty little helper shortcut to allow us to use the `ME` “issuer” to swap with our actual account publicKey. Niceties make the world go ‘round.
```typescript
asset: instructions[3] ? new Asset(instructions[1], instructions[3]) : Asset.native(),
```
The final noteworthy change is a ternary operation that switches our payment asset between the native XBN and a custom asset based off of responses to our prompt. Essentially, if `instructions[3]` exists — meaning there is an issuer — use that issuer and custom token as the asset for the payment. Otherwise, just use the native `Asset`.
The final changes are in the `wallet.ts` itself and tie together all the other updates as well as pull in the new `trustAsset` method.
```typescript
import { Component, State, Prop } from "@stencil/core";
import { Server, ServerApi } from "stellar-sdk";
import componentWillLoad from "./events/componentWillLoad";
import render from "./events/render";
import createAccount from "./methods/createAccount";
import updateAccount from "./methods/updateAccount";
import trustAsset from "./methods/trustAsset"; // NEW
import makePayment from "./methods/makePayment"; // UPDATE
import copyAddress from "./methods/copyAddress";
import copySecret from "./methods/copySecret";
import signOut from "./methods/signOut";
import setPrompt from "./methods/setPrompt";
import { Prompter } from "@prompt/prompt";
interface StellarAccount {
publicKey: string;
keystore: string;
state?: ServerApi.AccountRecord;
}
interface Loading {
// UPDATE
fund?: boolean;
pay?: boolean;
trust?: boolean; // NEW
update?: boolean;
}
@Component({
tag: "stellar-wallet",
styleUrl: "wallet.scss",
shadow: true,
})
export class Wallet {
@State() account: StellarAccount;
@State() prompter: Prompter = { show: false };
@State() loading: Loading = {};
@State() error: any = null;
@Prop() server: Server;
// Component events
componentWillLoad() {}
render() {}
// Batun methods
createAccount = createAccount;
updateAccount = updateAccount;
trustAsset = trustAsset; // NEW
makePayment = makePayment; // UPDATE
copyAddress = copyAddress;
copySecret = copySecret;
signOut = signOut;
// Misc methods
setPrompt = setPrompt;
}
Wallet.prototype.componentWillLoad = componentWillLoad;
Wallet.prototype.render = render;
```
Only thing worth seeing here besides the inclusion of the new `trustAsset` method is the addition of the `trust?: boolean,` in the `Loading` class.
## Add Trustlines
Alright so, finally we get to the `./methods/trustAsset.ts` file!
```typescript
import sjcl from "@tinyanvil/sjcl";
import {
Keypair,
Account,
TransactionBuilder,
BASE_FEE,
Networks,
Operation,
Asset,
} from "stellar-sdk";
import { handleError } from "@services/error";
export default async function trustAsset(
e?: Event,
asset?: string,
issuer?: string,
pincode?: string,
) {
try {
if (e) e.preventDefault();
let instructions;
if (asset && issuer) instructions = [asset, issuer];
else {
instructions = await this.setPrompt("{Asset} {Issuer}");
instructions = instructions.split(" ");
}
pincode = pincode || (await this.setPrompt("Enter your keystore pincode"));
if (!instructions || !pincode) return;
const keypair = Keypair.fromSecret(
sjcl.decrypt(pincode, this.account.keystore),
);
this.error = null;
this.loading = { ...this.loading, trust: true };
await this.server
.accounts()
.accountId(keypair.publicKey())
.call()
.then(({ sequence }) => {
const account = new Account(keypair.publicKey(), sequence);
const transaction = new TransactionBuilder(account, {
fee: BASE_FEE,
networkPassphrase: Networks.TESTNET,
})
.addOperation(
Operation.changeTrust({
asset: new Asset(instructions[0], instructions[1]),
}),
)
.setTimeout(0)
.build();
transaction.sign(keypair);
return this.server.submitTransaction(transaction);
})
.then((res) => console.log(res))
.finally(() => {
this.loading = { ...this.loading, trust: false };
this.updateAccount();
});
} catch (err) {
this.error = handleError(err);
}
}
```
This is similar to the `makePayment` method but there are a couple tiny tweaks worth noting:
```typescript
export default async function trustAsset(
e?: Event,
asset?: string,
issuer?: string,
pincode?: string
) {
try {
if (e)
e.preventDefault()
let instructions
if (
asset
&& issuer
) instructions = [asset, issuer]
else {
instructions = await this.setPrompt('{Asset} {Issuer}')
instructions = instructions.split(' ')
}
pincode = pincode || await this.setPrompt('Enter your keystore pincode')
```
We’re allowing the inclusion of several arguments in this function, namely `asset`, `issuer`, and `pincode`. We won’t be making use of them here, but transparently creating trustlines from within other functions will prove useful later.
If we have any of those variables set, we can “preload” our interface a bit, and even bypass user input altogether if a pincode is provided. Again, not something we’ll make use of quite yet, but once we look into depositing and withdrawing assets from an Anchor or accepting incoming payments for which we don’t yet have a trustline this functionality will prove useful.
So there we have it! The ability to accept and pay with custom assets on Bantu!
# Run a Core Node
# index
Bantu is a peer-to-peer network made up of nodes, which are computers that keep a common distributed [ledger](/glossary/ledger), and that communicate to validate and add [transactions](/glossary/transactions) to it. Nodes use a program called Bantu Core — an implementation of the [Bantu Consensus Protocol](/glossary/scp) — to stay in sync as they work to agree on the validity of transaction sets and to apply them to the ledger. Generally, nodes reach consensus, apply a transaction set, and update the ledger every 3-5 seconds.
You don’t need to run a node to build on Bantu: you can start developing with your [SDK of choice](/software-and-sdks/index), and use public instances of Horizon to query the ledger and submit transactions right away. In fact, the Bantu Development Foundation offers two public instances of Horizon — one for the public network and one for the testnet — which you can read more about in our [API reference docs](/api/introduction/index).
If you’re serious about building on Bantu, have a production-level product or service that requires high-availability access network, or want to help increase network health and decentralization, then you probably *do* want to run a node, or even a trio of nodes (more on that in the [Tier 1 section](/run-core-node/tier-1-orgs)).
If you’re going the DIY route, this section of the docs is for you. It explains the technical and operational aspects of installing, configuring, and maintaining a Bantu Core node, and should help you figure out the best way to set up your Bantu integration.
The basic flow, which you can navigate through using the menu on the left, goes like this:
* Choose which type of node you want to run
* Prepare Your Environment
* Install Bantu Core
* Configure Bantu Core
* Join the network
* Monitor and maintain your node
* Join the validators channels to stay on top of critical upgrades and network votes
## Types of nodes
All nodes perform the same basic functions: they run Bantu Core, connect to peers, submit transactions, store the state of the ledger in a SQL [database](/run-core-node/configuring#database), and keep a duplicate copy of the ledger in flat XDR files called [buckets](/run-core-node/configuring#buckets). All nodes also support [Horizon](/run-api-server/index), the Bantu API.
In addition to those basic functions, there are two key configuration options that determine how a node behaves. A node can:
* Participate in consensus to [validate transactions](/run-core-node/configuring#validating)
* Publish an [archive](/run-core-node/publishing-history-archives) that other nodes can consult to find the complete history of the network.
To make things easier, we’ll define four types of nodes based on permutations of those two options: **Watcher**, **Basic Validator**, **Full Validator**, and **Archiver**. You’ll notice that they *all* support Horizon and submit transactions to the network:
| Type of Node | Supports Horizon | Submits Transactions | Validates Transactions | Publishes History |
| ------------------- | ---------------- | -------------------- | ---------------------- | ----------------- |
| **Watcher** | ✅ | ✅ | | |
| **Basic Validator** | ✅ | ✅ | ✅ | |
| **Full Validator** | ✅ | ✅ | ✅ | ✅ |
| **Archiver** | ✅ | ✅ | | ✅ |
So why choose one type over another? Let’s break it down a bit and take a look at what each type is good for.
### Watcher
#### Non-validating, no public archive
A Watcher is the lightest node you can run. It keeps track of the ledger and submits transactions for possible inclusion, but it is *not* configured to participate in validation or to publish a history archive, which means it doesn’t do anything to support the network or increase decentralization.
Watchers pair well with Horizon, and if all you need is a Horizon instance to query the ledger or submit transactions, a Watcher is probably the right choice for you. While there are public instances of Horizon you can use — namely those maintained by [SDF](/api/introduction/index), [Lobstr](https://horizon.Bantu.lobstr.co), [Satoshipay](https://Bantu-horizon.satoshipay.io), and [Coinqvest](https://horizon.Bantu.coinqvest.com) — they’re all rate limited, so they won’t work if you need to scale your project or you want to offer your customers an SLA — 99% uptime, for instance.
**Use a Watcher to run Horizon, and to ensure reliable access to the network.**
### Basic Validator
#### Validating, no public archive
A Basic Validator is a lot like a Watcher, and has the same advantages and similar operational requirements. The difference between the two is that a Basic Validator requires a secret key, and is [configured to participate in consensus](/run-core-node/configuring#validating) by voting on — and signing off on — changes to the ledger.
The advantage: signatures can serve as official endorsements of specific ledgers in real time. That’s important if, for instance, you issue an asset on Bantu that represents a real-world asset: you can let your customers know that you will only honor transactions and redeem assets from ledgers signed by your validator, and in the unlikely scenario that something happens to the network, you can use your node as the final arbiter of truth. Setting up your node as a validator allows you to resolve any questions *up front and in writing* about how you plan to deal with disasters and disputes.
**Use a Basic Validator to run Horizon, ensure reliable access to the network, and sign off on transactions.**
### Full Validator
#### Validating, offers public archive
A Full Validator is the same as a Basic Validator except that it also publishes a [History Archive](/run-core-node/publishing-history-archives) containing snapshots of the ledger, including all transactions and their results. A Full Validator writes to an internet-facing blob store — such as AWS or Azure — so it's a bit more expensive and complex to run, but it also does the most to support the network’s resilience and decentralization.
When other nodes join the network — or experience difficulty and temporarily fall out of sync — they can consult archives offered by Full Validators to catch up on the history of the network. Redundant archives prevent a single point of failure, and allow network participants to verify the veracity of a given history.
Full Validators can support Horizon, but generally, organizations that run them don’t use them to query network data or submit transactions. In fact, they often run a Watcher to handle Horizon *in addition* to Full Validators. Most of those organizations are also part of — or on track to join — [Tier 1](/run-core-node/tier-1-orgs), which is a core group of network participants who run three Full Validators to contribute maximum redundancy.
**Use a Full Validator to sign off on transactions, and to contribute to the health and decentralization of the network.**
### Archiver
#### Non-validating, offers public archive
An Archiver is a rare bird: like a Full Validator, it publishes the activity of the network in long-term storage; unlike a Full Validator, it does not participate in consensus.
Archivers help with decentralization a bit by offering redundant accounts of the network’s history, but they don’t vote or sign ledgers, so their usefulness is fairly limited. If you run a Bantu-facing service, like a blockchain explorer, you may want to run one. Otherwise, you’re probably better off choosing one of the other three types.
**Use an archiver if you want to referee the network. Which is unlikely.**
# running-node
```javascript
import { CodeExample } from "components/CodeExample";
```
## Starting Bantu Core
Once you've [set up your environment](/run-core-node/prerequisites), [configured your node](/run-core-node/configuring), set up your [quorum set](/run-core-node/configuring#choosing-your-quorum-set), and selected archives to `get` [history from](/run-core-node/configuring#history), you're ready to start Bantu Core.
Use a command equivalent to:
`$ bantu-core run`
At this point, you're ready to observe your node's activity as it joins the network.
You may want to skip ahead and review the [logging](/run-core-node/running-node#logging) section to familiarize yourself with Bantu Core's output.
## Interacting With Your Instance
When your node is running, you can interact with Bantu Core via an administrative HTTP endpoint. Commands can be submitted using command-line HTTP tools such as `curl`, or by running a command such as
`$ bantu-core http-command