Security

Never custodialCopy Anchor Link

The API and the SDK build unsigned transactions. Your user's wallet signs them. No endpoint takes a private key, and none returns a transaction Xebra has signed on the user's behalf. Xebra holds no keys that can move a user's USDC.

What each path does with the funds while a transfer is made:

• Out of Stellar, the user is the caller of Circle's burn, and their USDC goes from their wallet to Circle inside the one transaction they sign. Xebra's contract takes only its own fee in that same transaction, and never holds the principal.
• Out of Arc through Xebra's contract, Circle's EVM contract burns from whoever calls it, so the principal passes through Xebra's contract for the length of that one transaction. The contract fails the transaction unless it burned exactly what it should and holds nothing beyond its own fees. (As of 2026-11-12 the API builds transfers out of EVM chains directly against Circle's contract instead; see Fees.)
• Out of other EVM chains and directly from Arc, the user's wallet calls Circle's contract. No Xebra contract is involved. The only guards are the API's and SDK's own checks on the token, domain, recipient and fee, against a chain table pinned in the code.
• Sui to Stellar involves no Xebra contract. Xebra's relayer account pays the Stellar fee to finish the mint; the recipient comes from the burn itself, so the relayer cannot change it.

Every transfer can be finished by anyone once Circle has attested it, so no transfer depends on Xebra being online. See Recovery.

Limits and governanceCopy Anchor Link

The same rules hold on Xebra's contract on Stellar and its contract on Arc:

• Per-transfer limits. Each transfer through a Xebra contract is capped (100 USDC as of 2026-11-12) while the contracts have had no external audit.
• Fee ceilings in code. Xebra's percentage fee can never exceed 1%. Circle's delivery fee can never exceed 2 USDC, a per-destination cap set under the timelock, or a tenth of the transfer.
• Instant pause. A pauser can stop new transfers at once. Only the admin can unpause.
• Instant tightening. The admin or the pauser can switch a destination off or lower a cap at once. Neither can raise anything this way.
• 48-hour timelock on everything that loosens. Raising a fee or a limit, adding a destination, or changing a key is proposed on chain and takes effect only after 48 hours. The pauser can cancel any pending change during that time.
• No upgrades. The contracts have no upgrade function. The USDC and Circle contracts they call are fixed at deployment.
• The user signs the limits. Every transfer request carries the most Xebra may charge on it. A fee change landing in the same moment still cannot overcharge a request already signed.

ContractsCopy Anchor Link

Xebra's contracts, as recorded in the repository's deployments/mainnet.json:

Their roles on Stellar (v2):

And on Arc:

Circle's contracts that transfers call:

The USDC address on each EVM chain is in EVM_CHAINS in @xebra/sdk/core. See Core.

AuditsCopy Anchor Link

The contracts have not had an external audit (as of 2026-11-12). They are tested with unit, property and fork tests, and with real transfers on testnet and mainnet. Per-transfer limits stay low until an audit is done. The source is public: github.com/xebra-org/xebra.

Reporting a problemCopy Anchor Link

Do not open a public issue for anything that could put funds at risk. Use GitHub's private vulnerability reporting on the repository, as described in its SECURITY.md.