> This page is for Taurus PROTECT, version v3.52.
> For other versions, use one of these documentation indexes:
> - v3.58 (default): https://taurushq.ferndocs.com/protect-capital/v3.58/llms.txt
> - v3.56: https://taurushq.ferndocs.com/protect-capital/v3.56/llms.txt
> - v3.54: https://taurushq.ferndocs.com/protect-capital/v3.54/llms.txt
> - v3.52: https://taurushq.ferndocs.com/protect-capital/v3.52/llms.txt
> - v3.50: https://taurushq.ferndocs.com/protect-capital/v3.50/llms.txt
> - v3.48: https://taurushq.ferndocs.com/protect-capital/v3.48/llms.txt
> - v3.46: https://taurushq.ferndocs.com/protect-capital/v3.46/llms.txt
> - v3.44: https://taurushq.ferndocs.com/protect-capital/v3.44/llms.txt
> - v3.42: https://taurushq.ferndocs.com/protect-capital/v3.42/llms.txt
> - v3.40: https://taurushq.ferndocs.com/protect-capital/v3.40/llms.txt
> - v3.38: https://taurushq.ferndocs.com/protect-capital/v3.38/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://taurushq.ferndocs.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://taurushq.ferndocs.com/_mcp/server.

# Wallets and core concepts

In order to use properly Taurus-PROTECT or Taurus-CAPITAL and take advantage of all product capabilities, it is important to understand the main building blocks that underpin our products and how to interact with them. Further details are available in the user guides (*protected access*).

# Taurus-PROTECT

Taurus implements **hierarchical deterministic wallet** structure, concretely our engineering team has implemented BIP32 (see Figure below), BIP44 standards.

![BIP-SEED-WALLET-BITCOIN-CONVERTER-4-1.png](/_fern-img/959f10bac5bc12e29a122553af530899c123d3da2d72ec9d0afff629ad2edbe3.webp)

## Wallet

A `wallet` is a group of `addresses`. It corresponds to depth = 3 in BIP 32 standard. Taurus-PROTECT allow clients to create up to 231 wallets.

#### Properties

* There are 2 flavors of wallets:
  * single owner wallets: all addresses within the wallet belong to the same owner and inherit the same `Client ID`. This property enables an advanced feature (called `AUTO` mode) of Taurus-PROTECT which allows to create `requests` with funds coming from multiples addresses of the wallet.
  * multiple owners wallets: each address within the wallet belongs to a different owner.
* A `wallet` can be tagged

## Address

An `address` represents a blockchain address, whose private key is secured by Taurus-PROTECT. An address **always** corresponds to one wallet. It corresponds to depth = 5 in BIP 32 standard. Taurus-PROTECT clients can create up to 231 addresses *per wallet*.

#### Properties

* an `address` belongs to a single `wallet`
* the blockchain `address` is signed by the HSM
* an `address` can be tagged
* sometimes also referred as `deposit address` or `internal address`

#### Example

**`Example of a Bitcoin P2SH address`**

```text Example of a Bitcoin P2SH address
3J5ZgXpkCffMoDi1snLMw9bY5GCUxyN8nw
```

## Whitelisted address

A `whitelisted address` is a blockchain address external to Taurus-PROTECT, that is, whose private key is **not** generated nor secured by Taurus-PROTECT. It is typically an external address to which users would like to send funds to. Whitelisted addresses can be those of counterparties, clients external addresses etc.

> **Warning**
>
> **Whitelisted addresses**
>
> Any asset that leaves Taurus-PROTECT must be towards a whitelisted address. That is, no external transaction is allowed towards non-whitelisted addresses.

#### Properties

* a `whitelisted address` must be approved and signed by selected users, before being useable. Said workflow must be defined in [Governance rules](/user-guides/docs/address-whitelisting-rules)
* sometimes also referred as `external address`

## Whitelisted contract

A `whitelisted contract` is a contract address that represents a smart contract. Supported contracts cover both `Ethereum` and `Tezos` blockchains :

* Ethereum: `ERC-20` and any `ERC` smart contracts (incl. NFTs)
* Tezos: `FA1.2` and `FA2` smart contracts (incl. NFTs)

#### Properties

* a `whitelisted contract ` must be approved and signed by selected users, before being useable. Said workflow must be defined in [Governance rules](/user-guides/docs/asset-whitelisting-rules)

## Request

A `request` represents a business action that might be subject to the approval of other users. Typical actions are:

* transfer funds from a blockchain address to another blockchain address
* transfer funds from a wallet (i.e., containing multiple addresses belonging to the same owner) to a blockchain address
* withdraw funds from an exchange to an internal blockchain address
* interact with a smart contract
* staking, unstaking, and withdraw

#### Properties

* a `request` is usually verified and approved (signed) by one or more approvers whose workflow must be defined in [Governance rules](/user-guides/docs/transaction-rules)
* a `request` can result in multiple blockchain `transactions`

## Transaction

A `transaction` represents a blockchain transaction, as observed on the blockchain network.

> **Note**
>
> **Request or Transaction ?**
>
> `request` and `transaction` are 2 different concepts, although usually linked. A `request` to transfer funds can result in several blockchain transactions. For example, let us imagine that we have 2 ETH addresses `a1` (balance: 5 ETH) and `a2` (balance: 3 ETH)  in a wallet `w` owned by the same owner.
> A `request` to transfer 6 ETH from the wallet `w` to the address `d` will result in 2 blockchain transactions:
>
> 1. a transfer of 5 ETH from `a1` to `d`
> 2. a transfer of 1 ETH from `a2` to `d`

## Action

* An `Action` relies on an engine that allows users to *automate selected actions* such as filling addresses or forwarding assets
* Actions are created by users with `Administrator` role
* For more details, refer to user guides (*password protected*)

## Business rule

* A `business rule` allows to configure the system and set different rules regarding opening hours, requests, wallets, currencies, etc.
* Business rules are created by users with `Administrator` role
* For more details, refer to user guides (*password protected*)

## Governance rule

* A `governance rule`  defines the rules for a request to be accepted by the HSM. A rule is usually composed of a source, a destination and an amount. The HSM verifies any `requests` against the set of enforced `governance rules` to decide if the `request` can be processed or not.
* Governance rules are created by users with `Super Administrator` role
* For more details, refer to user guides (*password protected*)

## Exchange Account

An exchange account is an account held with a 3rd party such as Coinbase, Kraken, Binance etc. Taurus-PROTECT integrates with several exchanges to facilitate the viewing of your exchange account positions (fiat + crypto balances held outside of your custody solution) as well as initiate withdrawal requests via API to that exchange. API keys must be pre-configured in Taurus-PROTECT with the correct permissions in order to benefit from this feature.

# Taurus-CAPITAL

## Smart contract

A smart contract is a software code stored and executed on a blockchain or a Distributed Ledger Technology ("DLT") network, such as Ethereum or Tezos.

Each time a new version of the very same smart contract source code is deployed, we refer to it as an `instance`.

A `contract template` is the standard source code of a given smart contract that can be used to deploy several instances of the same smart contract.

## Digital asset

A Digital Asset is a digital representation of a right, claim, asset property, security, financial instrument, currency or unit of account booked on a distributed ledger, such as a blockchain.

The primary types of digital assets are, as per the Swiss Financial Markets Supervisory Authority FINMA's classification:

* Payment Tokens are generally synonymous with Cryptocurrencies, the sole or primary purpose and function of which is to serve as means of payment, so that Payment Tokens have no other material functions or links to development projects
* Utility Tokens are Digital Assets that are intended to provide digital access to an application or service
* Asset/investment Tokens represent assets such as participations in real physical underlyings, companies, or earnings streams, or an entitlement to dividends or interest payments. In terms of their economic function, Asset Tokens are analogous to equities, bonds, derivatives or other investment instruments.

## Token

A Token is a Digital Asset with the following main characteristics:

* It is booked on an existing distributer ledger (e.g., Ethereum, Tezos) - instead of launching a new one for each new token
* It is modelled and implemented in the form of a `smart contract`.

A Token on Ethereum coexists with other tokens on the same blockchain, as well as its native crypto-currency (i.e. ethers for Ethereum)

## Investor

Person or legal entity planning to hold, previously holding or currently holding Digital Assets.

## Issuer

Person or legal entity issuing and offering Digital Assets to investors.

## DeFi

Decentralized finance ("DeFi") offers financial instruments without relying on intermediaries such as brokerages, exchanges, or banks. Instead, it uses smart contracts on a blockchain. DeFi allow for example people to lend or borrow funds from othe