Verify user action signature"] end subgraph Authz[2: Authorization] PermCheck["Check user permissions
e.g., Wallets:Sign"] end subgraph Policy[3: Policy Engine] PolicyEval["Evaluate matching policies"] end Blocked([Blocked]) ApprovalRequired["Approval Required"] HumanApproval{"Human Review"} Rejected([Rejected]) Approved["Approved"] subgraph MPC[4: MPC Signing] MPCSign["Distributed key shares
sign collaboratively"] end subgraph Broadcast[5: Broadcast] BroadcastTx["Send to blockchain"] end App --> Auth Auth --> Authz Authz --> Policy Policy --> Blocked Policy --> ApprovalRequired Policy --> MPC ApprovalRequired --> HumanApproval HumanApproval -->|Reject| Rejected HumanApproval -->|Approve| Approved Approved --> MPC MPC --> Broadcast ``` ## Layer 1: Authentication Every API request must prove identity through two mechanisms: ### API Token The `Authorization: Bearer
Share 1"] S2["Signer Node
Share 2"] S3["Signer Node
Share 3"] S4["Signer Node
Share 4"] end Threshold["Threshold Signature
(k-of-n nodes collaborate)"] S1 --> Threshold S2 --> Threshold S3 --> Threshold S4 --> Threshold end ``` Key properties: * **No complete key**: The private key never exists in one place * **Threshold security**: Requires k-of-n shares to sign (not all shares needed) * **Geographic distribution**: Nodes are in different data centers/regions * **Audit trail**: Every signing ceremony is logged ## Layer 5: Broadcast The signed transaction is broadcast to the blockchain network. Dfns monitors for confirmation and updates transaction status. ## Security model summary | Layer | What it protects against | | ------------------- | ------------------------------------- | | Authentication | Unauthorized access | | User action signing | Token theft, replay attacks | | Permissions | Privilege escalation | | Policies | Unauthorized transactions, fraud | | MPC | Key theft, single point of compromise | ## Separation of concerns A critical security property: **credentials and keys are completely separate**. | Credential (Authentication) | Key (Signing) | | ----------------------------------------------------------- | ----------------------------- | | Proves identity | Signs transactions | | Stored on user device (passkey) or server (service account) | Stored in MPC network | | Can be revoked/rotated | Key shares are immutable | | Compromised credential ≠ stolen assets | Protected by all layers above | Even if an attacker steals credentials, they still face: * User action signing requirements * Permission checks * Policy enforcement * MPC threshold requirements ## Related
`webauthn.get` for login and action signing | | challenge | `string` | The challenge returned from the init call | | origin | `string` | The origin in which the app is being executed | | crossOrigin | `boolean` | A flag indicating if the current call is running cross origin; in most cases this should be `false` | #### Example ```typescript theme={null} // Client data as returned by the authenticator during registration eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiWTJndE16bGxORFl0YUdKdGRtMHRPR3gwY1hFemMybzBPRGczWlRkd09BIiwib3JpZ2luIjoiaHR0cHM6Ly9hcHAuZGZucy5uaW5qYSIsImNyb3NzT3JpZ2luIjpmYWxzZX0 // Client data object { "type":"webauthn.create", "challenge":"Y2gtMzllNDYtaGJtdm0tOGx0cXEzc2o0ODg3ZTdwOA", "origin":"https://app.dfns.ninja", "crossOrigin":false } ``` ### Key, Password Protected Key and Recovery credential Unlike when using `Fido2 credential`, the client data object needs to be created manually for `Key credential`. Once created the object needs to be "stringified" and base64url encoded.
key.get for login and action signing |
| challenge | `string` | The challenge returned from the init call. The challenge is already base64url encoded, there is no need to encode it |
#### Example
```typescript theme={null}
// Client data object
{
"challenge":"Y2gtNzloaHQtbXJlb2stOGFwOHFtMmVpZWZ0amxhZw",
"type":"key.create"
}
// Stringify
'{"challenge":"Y2gtNzloaHQtbXJlb2stOGFwOHFtMmVpZWZ0amxhZw","type":"key.create"}'
// Base64url
eyJjaGFsbGVuZ2UiOiJZMmd0Tnpsb2FIUXRiWEpsYjJzdE9HRndPSEZ0TW1WcFpXWjBhbXhoWnciLCJ0eXBlIjoia2V5LmNyZWF0ZSJ9
```
## Attestation Data
This attestation data object is used during [registration](/api-reference/auth/registration-flows) and [new credential](/api-reference/auth/credentials).
### Fido2 credential
When using Fido2, the `attestation data` object is built inside the authenticator and returned to the browser. It is encoded using [CBOR specification](https://cbor.io/). There is no need to modify it.
More information can be found in the [W3C webauthn offical specification](https://w3c.github.io/webauthn/#dom-authenticatorattestationresponse-attestationobject).
It is an opaque object and there is no need to describe it here.
#### Example
```typescript theme={null}
// Attestation Data as returned by the authenticator during registration
o2NmbXRmcGFja2VkZ2F0dFN0bXSjY2FsZyZjc2lnWEcwRQIgVHg5PQ_mEyPi_FRZdkgT-SXmspljVaOWJBcN3M0iDxoCIQC8dJkvMWREoJrEdgECSRWzUxXG0WbrpCiajYEJ8mNF5mN4NWOBWQLdMIIC2TCCAcGgAwIBAgIJANVbnGiXosqIMA0GCSqGSIb3DQEBCwUAMC4xLDAqBgNVBAMTI1l1YmljbyBVMkYgUm9vdCBDQSBTZXJpYWwgNDU3MjAwNjMxMCAXDTE0MDgwMTAwMDAwMFoYDzIwNTAwOTA0MDAwMDAwWjBvMQswCQYDVQQGEwJTRTESMBAGA1UECgwJWXViaWNvIEFCMSIwIAYDVQQLDBlBdXRoZW50aWNhdG9yIEF0dGVzdGF0aW9uMSgwJgYDVQQDDB9ZdWJpY28gVTJGIEVFIFNlcmlhbCAxNzU1MDc3NTg5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAQap0H_qWf7Lo9-qH8Xj2q-EtN-D_jO0JWxfoyafAdQRcIHIhUMixqtqB9fd5M95L0F4zS7Pvbe5EIA_tns7naOBgTB_MBMGCisGAQQBgsQKDQEEBQQDBQQDMCIGCSsGAQQBgsQKAgQVMS4zLjYuMS40LjEuNDE0ODIuMS43MBMGCysGAQQBguUcAgEBBAQDAgUgMCEGCysGAQQBguUcAQEEBBIEEO6IKHlyHEkTl3U9_M6XByowDAYDVR0TAQH_BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAhDTK-uoXyNUKvzPk-mTjRykakGfJx6CXWJHJAR_zdkHQHaNA-SB8z3a2lmn9sBKI2_-9T3Pasj4gaaXiQxqOXbifp8Iv5nz7rKtmmMuur_u4-XMkOo-wLdZvcjwj-jWdX0daFGmRU0Yck4tYw6-Y_hJ_L8mNT_Odu2jqY3--WlZ8T9H-c9BYhz3dG1MCiQpYH_tw5sz0LXuSFrM3tF_0yEehgtwDwANby9OG7KqUf7O0ArvpBcFFPj8lJf_1_6qXkwFSYxZZzKXHwNsumEdpB7is-X6M4sWG_dcl6msj-hQdtWpxokCWzymdlUG5mk541vtzqpMjM6UvREg1wWjoXmhhdXRoRGF0YVjCtP0s4DAIslfywtetyFg4YfWUmc3GcqHTevk0O6OswibFAAAAAe6IKHlyHEkTl3U9_M6XByoAMEmPqgPRjx312Ywh4gex7TgWLwE2kWRNFGsBomlOLuGIceqoSXgbyAXJgksJs_8_nqUBAgMmIAEhWCBJj6oD0Y8d9dmMIeIHCSUgwKr6FKqaytOhNxEZnGoOYiJYIPGzFTyHoPed-ysej7WwkaaHydkatYmz0rInky2TzyiKoWtjcmVkUHJvdGVjdAI
// CBOR decoded Attestation Data
{
"authData" : {
"rpIdHash" : "tP0s4DAIslfywtetyFg4YfWUmc3GcqHTevk0O6OswiY=",
"flags" : -59,
"signCount" : 1,
"attestedCredentialData" : {
"aaguid" : {
"value" : "ee882879-721c-4913-9775-3dfcce97072a",
"bytes" : "7ogoeXIcSROXdT38zpcHKg=="
},
"credentialId" : "SY+qA9GPHfXZjCHiB7HtOBYvATaRZE0UawGiaU4u4Yhx6qhJeBvIBcmCSwmz/z+e",
"cosekey" : {
"1" : "2",
"3" : -7,
"-1" : 1,
"-2" : "SY+qA9GPHfXZjCHiBwklIMCq+hSqmsrToTcRGZxqDmI=",
"-3" : "8bMVPIeg9537Kx6PtbCRpofJ2Rq1ibPSsieTLZPPKIo=",
"1" : 2
}
},
"extensions" : {
"credProtect" : 2
},
"flagUP" : true,
"flagUV" : true,
"flagAT" : true,
"flagED" : true
},
"attStmt" : {
"alg" : -7,
"sig" : "MEUCIFR4OT0P5hMj4vxUWXZIE/kl5rKZY1WjliQXDdzNIg8aAiEAvHSZLzFkRKCaxHYBAkkVs1MVxtFm66Qomo2BCfJjReY=",
"x5c" : [ "MIIC2TCCAcGgAwIBAgIJANVbnGiXosqIMA0GCSqGSIb3DQEBCwUAMC4xLDAqBgNVBAMTI1l1YmljbyBVMkYgUm9vdCBDQSBTZXJpYWwgNDU3MjAwNjMxMCAXDTE0MDgwMTAwMDAwMFoYDzIwNTAwOTA0MDAwMDAwWjBvMQswCQYDVQQGEwJTRTESMBAGA1UECgwJWXViaWNvIEFCMSIwIAYDVQQLDBlBdXRoZW50aWNhdG9yIEF0dGVzdGF0aW9uMSgwJgYDVQQDDB9ZdWJpY28gVTJGIEVFIFNlcmlhbCAxNzU1MDc3NTg5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAQap0H/qWf7Lo9+qH8Xj2q+EtN+D/jO0JWxfoyafAdQRcIHIhUMixqtqB9fd5M95L0F4zS7Pvbe5EIA/tns7naOBgTB/MBMGCisGAQQBgsQKDQEEBQQDBQQDMCIGCSsGAQQBgsQKAgQVMS4zLjYuMS40LjEuNDE0ODIuMS43MBMGCysGAQQBguUcAgEBBAQDAgUgMCEGCysGAQQBguUcAQEEBBIEEO6IKHlyHEkTl3U9/M6XByowDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAhDTK+uoXyNUKvzPk+mTjRykakGfJx6CXWJHJAR/zdkHQHaNA+SB8z3a2lmn9sBKI2/+9T3Pasj4gaaXiQxqOXbifp8Iv5nz7rKtmmMuur/u4+XMkOo+wLdZvcjwj+jWdX0daFGmRU0Yck4tYw6+Y/hJ/L8mNT/Odu2jqY3++WlZ8T9H+c9BYhz3dG1MCiQpYH/tw5sz0LXuSFrM3tF/0yEehgtwDwANby9OG7KqUf7O0ArvpBcFFPj8lJf/1/6qXkwFSYxZZzKXHwNsumEdpB7is+X6M4sWG/dcl6msj+hQdtWpxokCWzymdlUG5mk541vtzqpMjM6UvREg1wWjoXg" ]
},
"fmt" : "packed"
}
```
### Key, Password Protected Key and Recovery credential
Unlike when using `Fido2 credential`, the attestation data object needs to be created manually for `Key credential`. Once created the object needs to be "stringified" and base64url encoded.
Before building the `attestation data` object, the `credential info fingerprint` object needs to be created.
#### Credential Info Fingerprint
The attestation data object contains a `signature`. This section explains how to construct the credential info fingerprint object that is then signed and included in the attestation data object.
| Field | Type | Description |
| ---------------- | ------ | ---------------------------------------------------------------------------------- |
| `clientDataHash` | string | The hex encoded SHA-256 hash of the "stringified" client data object |
| `publicKey` | string | PEM encoded public key that can be used to verify the signature for the credential |
Optional The algorithm/digest that the credential will use to sign data. If the algoritm is not specified the algorithm will be determined by the key. Can be one of the following choices:RSA-SHA256SHA256SHA512
(see [Authentication flows](/api-reference/auth/login-flows)) | To get a token, you can either: * as a User (human 👨) * Follow the [Login](/api-reference/auth/login-flows) flow. You'll get a authentication token at the end of this flow, which expires after a relatively short period of time. * Create a [Personal Access Token](/api-reference/auth/personal-access-tokens) (PAT) [⚠️](#user-content-fn-1)[^1], which is a long-lived authentication token for the User, and that you can use as an authentication token directly. * as a Service Account (machine 🤖) * Create a [Service Account Token](/api-reference/auth/service-accounts) [⚠️](#user-content-fn-1)[^1], which is a long-lived authentication token for the Service Account, and that you can use as an authentication token directly. Note: while registering a new user (see [Registration flows](/api-reference/auth/registration-flows)), the initial step will get you a temporary registration token ([example](/api-reference/auth/create-registration-challenge)) that you should use as a Bearer token in the `Authorization` header for the next step of the registration ([example](/api-reference/auth/complete-user-registration)). [^1]: ⚠️ Once generated, Dfns system do not keep a trace of your Service Account Token or your Personal Access Token, only you will hold on to those. If you lose them, you'll just need to create a new one. ## 2. Sign API requests (User Action Signing) Sign a User Action Challenge using a cryptographic key that you own (referred to Credential Key or just Credentials). This is only required for actions which mutate state (non-readonly API calls). We call that process: "User Action Signing". | Header | Description | | -------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `X-DFNS-USERACTION:
(see [User Action Signing flows](/api-reference/auth/signing-flows)) | To obtain that signature, you need to follow the [User Action Signing flows](/api-reference/auth/signing-flows): 1. You tell Dfns "I want to perform this exact request" 2. Dfns sends you back a challenge to be signed with your Credential. 3. You sign the challenge with your Credentials, and send it to Dfns. 4. Dfns gives you back a "user action signature", which you'll need include in the headers when you perform the actual request (`X-DFNS-USERACTION` header) The credential -- essentially being a cryptographic key -- you'll need to use to sign the challenge will depend on who is calling the api (User / Service Account), see more about that on the [dedicated page](/advanced/credentials). ## Getting current user info There is no `/me` or `/whoami` API endpoint. Instead, decode the JWT token to extract user information. You can use [jwt.io](https://jwt.io) for debugging or any JWT library in your code. ### Decoding the token ```typescript theme={null} // Using jose library import { decodeJwt } from 'jose' const token = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...' const payload = decodeJwt(token) const userId = payload['https://custom/app_metadata'].userId const orgId = payload['https://custom/app_metadata'].orgId const email = payload['https://custom/username'] ``` A decoded token looks like this: ```json theme={null} { "iss": "auth.dfns.io", "aud": "dfns:auth:user", "sub": "or-xxxxx-xxxxx-xxxxxxxxxxxxxxxx", "jti": "uj-xxxxx-xxxxx-xxxxxxxxxxxxxxxx", "https://custom/username": "user@example.com", "https://custom/app_metadata": { "tokenKind": "Token", "userId": "us-xxxxx-xxxxx-xxxxxxxxxxxxxxxx", "orgId": "or-xxxxx-xxxxx-xxxxxxxxxxxxxxxx" }, "iat": 1767947321, "exp": 1767968921 } ``` | Field | Description | | ------------------------------------ | -------------------------------------- | | `https://custom/username` | The user's email address | | `https://custom/app_metadata.userId` | The user's ID | | `https://custom/app_metadata.orgId` | The organization ID | | `exp` | Token expiration time (Unix timestamp) | ## Common errors See [Error codes](/api-reference/error-codes) for a full list of errors. Here are the most common authentication errors: ### 401 Unauthorized Your `Authorization` header is missing, malformed, or the token is invalid/expired. **Solutions:** * Verify the token is included as `Authorization: Bearer
| Field | Description | Type - Optional |
|---|---|---|
type | Ethereum transaction type. 0 for legacy transaction; 2 for EIP-1559 transaction; 4 for EIP-7702 transaction. Default is 2 if undefined. | Integer (optional) |
to | The destination address or target contract. Leave undefined when the transaction is a contract deployment. | String (optional) |
value | The amount of native tokens to transfer in minimum denomination. | String (optional) |
data | ABI encoded function call data in hex format. Can also be the encoded smart contract data when the transaction is a contract deployment. | String (optional) |
nonce | The transaction number to guarantee idempotency. If omitted, it will be provided automatically. Note the same nonce can be submitted multiple times with a higher maxFeePerGas to "overwrite" existing transactions in the mempool. | Integer or String (optional) |
gasLimit | The maximum amount of gas that can be spent for executing the transaction. If omitted, it will be calculated automatically. | String (optional) |
gasPrice | The amount of per unit gas. Only valid for a type 0 legacy transaction. If omitted, it will be calculated automatically. | String (optional) |
maxFeePerGas | The maximum amount of per unit gas willing to be paid for the transaction. Valid for type 2 and type 4 transactions. If omitted, it will be calculated automatically. | String (optional) |
maxPriorityFeePerGas | The maximum amount of per unit gas to be included as a tip to the validator. Valid for type 2 and type 4 transactions. If omitted, it will be calculated automatically. | String (optional) |
authorizationList | A list that indicates what code the signer of each authorization desires to execute in the context of their EOA. Only valid for type 4 transaction. | Authorization (optional) |
TimeoutSeconds
| Positive Integer | If we do NOT receive any updates from Notabene regarding the status of the travel rule message we need to eventually time out and reject the transfer. This is the timeout, in seconds, we wait for a response from Notabene before rejecting the transfer. | | autoClearAfterDelivered
TimeoutSeconds
| Positive Integer(Optional) | This OPTIONAL setting allows you to proceed with a transfer that Notabene has delivered to a counterparty even if the recipient hasn't responded after delivery. | ## Policy Action An action specifies what should happen if a policy rule is triggered. Supported action kinds are: [`Block`](#block-policy-action)`and`[`RequestApproval`](#requestapproval-policy-action). ### `Block` policy action This action means that the activity will be blocked if the policy is triggered. ```json theme={null} { "action": { "kind": "Block" } } ``` ### `RequestApproval` policy action This action means that activity will first require an Approval process to be completed before it can be executed (or be aborted if someone rejects it during the approval process). One or several groups of approvers need to be specified. These groups define who is allowed to approve / reject an activity. The activity will only be executed if all approver groups reach their "quorum" of approvals. Otherwise, if any one user within any approver group rejects, then the activity is aborted and the call is not executed. The example below shows a `RequestApproval` action, configured with one approval group requiring 2 approvals amongst three specific users. ```json theme={null} { "action": { "kind": "RequestApproval", "autoRejectTimeout": 60, // minutes "approvalGroups": [ { "name": "Admins", "quorum": 2, // only 2 approvers required in that group "approvers": { "userId": { "in": ["us-...1", "us-...2", "us-...3"], } }, "initiatorCanApprove": false, } ], } } ``` | property | Type | Description | | ------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | approvalGroups\* | List of Object | List of approval groups. If multiple groups are defined, the approval is complete only when all groups have approved | | approvalGroups\[].name | (Optional) String | Optional name of this group. | | approvalGroups\[].quorum\* | Positive Integer | The quorum is the number of approvals required in this group to reach group consensus. The activity is executed only if all groups reached their approval quorum. | | approvalGroups\[].approvers\* | Object | Defines all users that are allowed to approve in the group. If set to an empty object `{}`, it means that anyone within your organisation can be an approver. Otherwise, you can specify an exact list of allowed approvers, by adding their user IDs in this object: `{ userId: { in: [...] }}` | | approvalGroups\[].initiatorCanApprove | (Optional) Boolean | Whether the initiator of the activity can participate in the approval (defaults to `false`) | | autoRejectTimeout | (Optional) Positive Integer | Number of minutes after which, if the approval has not reach global consensus (all groups reached their consensus), the activity is automatically rejected.If not specified, the activity will never be rejected automatically (the approval process doesn't "expire" / "times out"). |
| filter key | evaluator | Value |
|---|---|---|
policyId | in | List of policy IDs. If the policy being modified is one of these IDs, the policy applies. |
MPC Protected
ID: key-123) %% --- Layer 2: The Dfns Wallets (Addresses) --- subgraph DfnsWallets [" "] direction LR EthWallet[Ethereum Wallet
Address: 0x71C...9A] SolWallet[Solana Wallet
Address: Hv2...xP] BtcWallet[Bitcoin Wallet
Address: bc1q...xy] end %% --- Layer 3: The Actual Blockchain Networks --- subgraph Blockchains [" "] direction LR EthNet[Ethereum Mainnet] SolNet[Solana Mainnet] BtcNet[Bitcoin Network] end %% Connections: Key powers Wallets Key --> EthWallet Key -- Signs transactions for your Dfns Wallets--> SolWallet Key --> BtcWallet %% Connections: Wallets exist on Networks EthWallet --> EthNet SolWallet -- Broadcasts to and indexes from the networks --> SolNet BtcWallet --> BtcNet %% Apply Styles class Key keyNode; class EthWallet,SolWallet,BtcWallet walletNode; class EthNet,SolNet,BtcNet blockchainNode; style DfnsWallets fill:transparent,stroke:none; style Blockchains fill:transparent,stroke:none; ``` ## What each object does ### Key Dfns Keys are the foundational cryptographic component that powers every Dfns Wallet. Think of a Key as the unique digital signature generator that authorizes every action on the blockchain. While Dfns Wallets provide a simple and streamlined interface for managing assets—like viewing balances and making transfers, the underlying Key is what actually signs and validates those transactions. This separation allows for greater flexibility; you can use the same key for multiple wallets (on distinct networks), but you can also interact with Dfns Keys directly to work with a vast number of blockchains or custom smart contracts, even those not fully supported by the high-level Wallets API. The Key is a distributed private key managed by the Dfns MPC network. You never access the key material directly—you reference it by its `keyId` to: * Create wallets on any blockchain that uses a compatible [key format](/networks/supported-key-formats). On compatible networks like EVM chains, wallets derived from the same key share the same address. * Sign transactions or arbitrary messages—even for blockchains Dfns doesn't natively support, as long as they use a compatible key format. This lets you benefit from Dfns key security on private chains or networks we haven't integrated yet. Keys also support [delegated signing](/advanced/delegated-wallets), enabling non-custodial configurations where your end users control their own keys.
Check the full list [here](https://api-docs.uniswap.org/guides/supported_chains) | | UniswapX | The latest version of Uniswap's swap protocol focused on efficient routing, improved UX, and better rates. | Ethereum Mainnet, Arbitrum, Base and Unichain
Check the full list [here](https://api-docs.uniswap.org/guides/supported_chains) | ## How It Works 1. **Select Tokens:** Choose the token you want to swap and the token you want to receive. 2. **Enter Amount:** Specify how much you want to swap. 3. **Review Quote:** Instantly see the best available price, estimated fees, and minimum received. 4. **Set Slippage (Optional):** Adjust your slippage tolerance for added control. 5. **Confirm Swap:** Review all details and confirm your transaction. 6. **Track Status:** Monitor your swap in real time and view your transaction history at any time.
Welcome to Dfns
Welcome to the Dfns APIs! Dfns provides wallet-as-a-service infrastructure that enables crypto developers to forget about private key management so they can focus on building what matters most — their applications. We’ve hired teams of security and cryptography PhDs to build the industry’s leading *Secure Multi-Party Computation*-based *Threshold Signature Scheme* ([MPC](https://en.wikipedia.org/wiki/Secure_multi-party_computation)/[TSS](https://en.wikipedia.org/wiki/Threshold_cryptosystem)) implementation so that you don’t have to.
Feel free to reach out at [https://support.dfns.co](https://support.dfns.co) if you have any question!
Thanks!
User login demo app
1. Credential registration
If not done already, you need to register on this website. Get a Credential Code from the dashboard (Settings > Authentication > Credentials)
Current state: {JSON.stringify(registrationState, null, 2)}
2. User login
| Dashboard only, wallets controlled by your company | Dashboard + API, wallets controlled by your company | Dashboard + API, wallets controlled by your customers | | :---------------: | :--------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------: | :-------------------------------------------------: | :---------------------------------------------------: | |
BitcoinTestnet3 | 1 | N/A | 2 | [https://signetfaucet.com/](https://signetfaucet.com/) | | Bitcoin Cash | No testnet support | 1 | N/A | 15 | | | BOB | BobSepolia | 1 | ERC-20, ERC-721 | 50 | [https://faucets.chain.link/bob-testnet](https://faucets.chain.link/bob-testnet) | | Canton | CantonTestnet | 1 | N/A | N/A | | | Cardano | CardanoPreprod | 1 | Asset | 5 | [https://docs.cardano.org/cardano-testnets/tools/faucet](https://docs.cardano.org/cardano-testnets/tools/faucet) | | Celo[^2] | CeloAlfajores | 1 | ERC-20, ERC-721 | 50 | [https://faucet.celo.org/alfajores](https://faucet.celo.org/alfajores) | | Codex | CodexSepolia | 1 | ERC-20, ERC-721 | 50 | | | Concordium | ConcordiumTestnet | 1 | CIS-2, CIS-7 | 5 | [https://github.com/Concordium/concordium-dapp-examples/tree/main/testnet-faucet](https://github.com/Concordium/concordium-dapp-examples/tree/main/testnet-faucet) | | Cosmos Hub 4 | CosmosIcsTestnet | 1 | N/A | 5 | | | Dogecoin | DogecoinTestnet | 1 | N/A | 40 | | | Ethereum | EthereumHolesky
EthereumHoodi
EthereumSepolia | 1 | ERC-20, ERC-721 | 12 | [https://cloud.google.com/application/web3/faucet/ethereum/sepolia](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) | | Ethereum Classic | EthereumClassicMordor | 1 | N/A | 3000 | | | Fantom Opera | FantomTestnet | 1 | ERC-20, ERC-721 | 5 | [https://faucet.fantom.network/](https://faucet.fantom.network/) | | Flare C-Chain