Authentication

The current API uses a Rift bearer for /v1/me, while its public EVM reads and calldata builders do not move funds by themselves. The Stellar extension retains that distinction between application identity, transaction preparation, and account signing authority.

Application identity and account linking

We use Rift for the current wallet, but our integration does not support Stellar signing. We plan to add our own Stellar wallet layer and verify the account linked to each user. A Rift extension or another Stellar provider remains an alternative. See wallet infrastructure.

An existing login may identify the BlockFinaX user. Linking a Stellar account requires a network-bound ownership proof. An EVM address returned by Rift is not automatically a Stellar account. Never derive or assume a signing key from an email address or copy private keys between account systems. Account recovery and application login recovery are separate policies; email reset alone does not authorize wallet control transfer.

Reads and builders

Public contract reads can remain unauthenticated. An unsigned builder can be public and rate-limited; it cannot bypass require_auth. Private business records, payment-provider sessions, customer documents, and tenant reports require scoped authentication and ownership checks. Browser credentials must not expose server API or relayer secrets.

Anchor authentication

Use SEP 10 for compatible classic accounts and SEP 45 for contract accounts where the provider supports it. Anchor JWTs are distinct from the app login session. A provider accepting SEP 45 authentication is not proof that every deposit or payout route accepts a C account. See institutional integration.

Signing

The Stellar wallet authorizes the specific contract invocation and asset transfers. Application tokens do not authorize an arbitrary debit. A fee sponsor signs only its own sponsorship role and cannot rewrite a customer's signed intent.