Stellar setup

Before an account can hold or receive an issued asset, it has to set up a trustline to that asset. A missing trustline is the most common problem we see in first integrations.

Every Stellar account needs a small XLM balance to stay active. A brand-new account without that reserve will fail to receive funds, and the errors can look like an asset or API problem.

We use claimable balances for escrow in the current saga. If you're used to EVM, think of the claimable-balance lifecycle as simply the lock and unlock steps.

For Mode 1 self-custody on Stellar, you'll usually add Nuvanté's operator as a co-signer with the right weight and threshold. See Custody models.

On Stellar, Mode 1 means Nuvanté's operator key is allowed to burn and mint directly on your issuing account. We don't need to call your issuer gateway for each transaction. To set it up:

1. Add Nuvanté's operator key as a co-signer on your Stellar issuing account. Use a SetOptions operation with signer type ed25519PublicKey. We'll give you the operator public key during onboarding.
2. Set the weight and threshold. The co-signer's weight has to meet the threshold for payment operations (which is what burns use) on your account. The right number depends on your current signing setup. Please confirm with your Nuvanté integration contact before you change a live account.
3. Declare it in your capability profile with commitPoint: "ON_OBSERVATION" and custodyModel: "DELEGATED_SIGNING". This tells the engine to sign directly and skip calls to an external issuer gateway.

Once you've added the co-signer, we'll call getAccount through the chain adapter to confirm the expected signer is there before onboarding continues. Please talk to your integration contact before you remove the co-signer, because removing it will break any transactions in flight.

Sandbox uses Stellar Testnet, so please keep Stellar Public (mainnet) out of sandbox. The Stellar custody adapter rejects the mainnet passphrase outright.