diff --git a/.env.example b/.env.example
new file mode 100644
index 0000000..11f7510
--- /dev/null
+++ b/.env.example
@@ -0,0 +1,9 @@
+# Backend URL reachable by the phone, for example http://192.168.1.25:3000.
+EXPO_PUBLIC_API_URL=
+
+# Public WalletConnect application identifier. Create one at https://dashboard.walletconnect.com/.
+EXPO_PUBLIC_WALLETCONNECT_PROJECT_ID=
+
+# Optional public HTTPS page that identifies SAVE Finance in Freighter.
+# Until one is provided, the app uses https://github.com/FWDP/save-project.
+EXPO_PUBLIC_WALLETCONNECT_METADATA_URL=
diff --git a/.github/workflows/soroban-contract.yml b/.github/workflows/soroban-contract.yml
new file mode 100644
index 0000000..cae6993
--- /dev/null
+++ b/.github/workflows/soroban-contract.yml
@@ -0,0 +1,30 @@
+name: Soroban contract
+
+on:
+ pull_request:
+ paths: ['contract/**', '.github/workflows/soroban-contract.yml']
+ push:
+ branches: [main]
+ paths: ['contract/**', '.github/workflows/soroban-contract.yml']
+
+jobs:
+ contract:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+ - uses: dtolnay/rust-toolchain@stable
+ with:
+ targets: wasm32v1-none
+ components: rustfmt, clippy
+ - uses: Swatinem/rust-cache@v2
+ with:
+ workspaces: contract
+ - name: Format
+ run: cargo fmt --manifest-path contract/Cargo.toml --all -- --check
+ - name: Unit tests
+ run: cargo test --manifest-path contract/Cargo.toml --locked
+ - name: Clippy
+ run: cargo clippy --manifest-path contract/Cargo.toml --all-targets --locked -- -D warnings
+ - name: Build Wasm
+ run: cargo build --manifest-path contract/Cargo.toml --package save-savings-vault --target wasm32v1-none --release --locked
+
diff --git a/.gitignore b/.gitignore
index 221e1f1..0b69b2a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,10 +33,14 @@ yarn-error.*
# local env files
.env*.local
*.env
+/backend/.stellar_integrity_signer_secret
# typescript
*.tsbuildinfo
+# Rust / Soroban
+/contract/target/
+
example
# generated native folders
diff --git a/README.md b/README.md
index d596770..7715880 100644
--- a/README.md
+++ b/README.md
@@ -1,72 +1,253 @@
-# SAVE Project
+
+ 
+
-This project includes:
+# SAVE Finance
-- Expo mobile app for Android/iOS
-- NestJS backend API
-- Next.js admin dashboard
-- MongoDB for primary data persistence
-- Redis for cache and queues
-- MinIO for object storage
-- Docker Compose for local services
+### Personal finance and goal-based saving, with optional Stellar rails
-## Quick start
+Track spending. Plan budgets. Build savings on Stellar Testnet without giving up custody of your wallet.
-1. Install root app dependencies:
+SAVE brings everyday money management, receipt capture, savings goals, and externally signed Stellar transactions into one mobile-first workspace. A NestJS API supports the app, while a Next.js dashboard provides an operational view.
- ```bash
- npm install
- ```
+[Explore the repository](https://github.com/FWDP/save-project) · [Stellar architecture](docs/STELLAR_ARCHITECTURE.md) · [Savings vault contract](docs/CONTRACT.md) · [Test evidence](docs/DELIVERABLES_1_2_TEST_REPORT.md)
-2. Install backend dependencies:
+> [!IMPORTANT]
+> SAVE's blockchain features are alpha software for **Stellar Testnet only**. The project does not support Mainnet or real-value custody. SAVE never asks for or stores a wallet secret seed; an external wallet must approve every transaction.
- ```bash
- cd backend && npm install
- ```
+---
-3. Install admin dashboard dependencies:
+## 🧩 Why SAVE
- ```bash
- cd admin && npm install
- ```
+Personal finances are often split across expense trackers, spreadsheets, receipt folders, bank apps, and crypto wallets. That fragmentation makes it difficult to connect daily spending decisions with longer-term savings goals.
-4. Start local services:
+SAVE combines those workflows while keeping a clear trust boundary: private financial records remain off-chain, public ledger activity is independently verifiable, and signing authority stays in the user's wallet.
- ```bash
- docker compose up -d
- ```
+## 🔁 The SAVE Money Loop
-5. Start the backend:
+**Track → Budget → Save → Sign → Verify**
- ```bash
- cd backend && npm run start:dev
- ```
+| Capability | What SAVE helps you do | Current status |
+| --- | --- | --- |
+| 🧾 Track | Record transactions, organize categories, and capture receipts. | Implemented alpha |
+| 📊 Budget | Plan category budgets and review financial reports. | Implemented alpha |
+| 🎯 Save | Create and manage traditional or Stellar-backed savings goals. | Implemented alpha |
+| ✍️ Sign | Prepare unsigned Testnet transactions and approve them in an external wallet. | Freighter Mobile via WalletConnect v2; SEP-7/XDR fallbacks |
+| 🔎 Verify | Reconcile transaction status through Horizon and Stellar RPC, with explorer links for ledger proof. | Testnet qualification implemented |
-6. Start the admin dashboard:
+## ✨ What You Can Do Today
- ```bash
- cd admin && npm run dev
- ```
+- Track expenses and transactions across configurable categories.
+- Create budgets, savings goals, custom fields, and financial reports.
+- Photograph receipts for expense capture and keep private metadata off-chain.
+- Link a watch-only Stellar Testnet public address without sharing a secret seed.
+- Create savings goals backed by the deployed Soroban savings vault.
+- Prepare goal contributions, completions, withdrawals, and cancellations as unsigned XDR.
+- Approve transactions in Freighter Mobile through WalletConnect v2.
+- Review account activity, contract events, transaction state, and Stellar Expert proof.
+- Use the REST API and Swagger UI to integrate or inspect backend operations.
-7. Start the Expo app:
+## 🌐 How SAVE Uses Stellar
- ```bash
- npm start
- ```
+SAVE uses Stellar as an optional authorization and settlement-verification layer for goal-based saving. It does not place receipts, merchant details, category labels, profiles, or goal names on-chain.
-## Environment files
+| Stellar capability | How SAVE uses it |
+| --- | --- |
+| Wallets and signatures | The app stores a public address only. Freighter Mobile or another compatible external flow approves transaction signatures. |
+| Horizon | The backend reads classic account and payment history and submits supported signed transactions. |
+| Stellar RPC | The backend simulates Soroban calls, checks fees and transaction status, reads vault state, and indexes contract events. |
+| Soroban | `save-savings-vault` holds approved Stellar Asset Contract tokens per goal and enforces lifecycle authorization. |
+| Ledger verification | Prepared requests have deterministic hashes, and submitted transactions remain pending until network reconciliation reports success or failure. |
-- Copy `backend/.env.example` to `backend/.env` and update values as needed.
-- The Expo app can use environment variables as needed later for secure config.
-- The admin app can use its own local `.env.local` file for API URLs and secrets.
+```mermaid
+flowchart LR
+ App[SAVE mobile app] -->|public address and intent| API[SAVE API]
+ API -->|unsigned XDR| App
+ App -->|approval request| Wallet[External wallet]
+ Wallet -->|signed transaction| Stellar[Stellar Testnet]
+ API --> Horizon[Horizon]
+ API --> RPC[Stellar RPC]
+ Horizon --> Stellar
+ RPC --> Stellar
+ API --> Data[(MongoDB)]
+```
-## Stack summary
+The browser or mobile client cannot declare a transaction successful. SAVE reconciles network evidence before it updates the final transaction state.
-- Mobile: React Native + Expo
-- Language: TypeScript
-- Navigation: Expo Router
-- State management: Zustand + TanStack Query
-- Local storage: SQLite + SecureStore + FileSystem + Camera
-- Backend: NestJS + MongoDB + Redis + BullMQ
-- Object storage: MinIO / S3-compatible storage
-- Web/admin: Next.js dashboard for operations and analytics
+## 💡 Design Principles
+
+- **Non-custodial by design:** secret seeds are never generated, accepted, transmitted, logged, or stored by SAVE.
+- **Private data stays private:** sensitive personal-finance records remain in the application data layer, not on the public ledger.
+- **Network evidence over client trust:** wallet responses and callbacks are validated; final state comes from Horizon or Stellar RPC.
+- **Exact amounts:** classic payments use validated decimal strings, while Soroban amounts are converted to atomic integer units.
+- **Explicit release boundaries:** Testnet features, production requirements, and deliberate non-goals are documented separately.
+
+## 👥 Who SAVE Is For
+
+- People who want one mobile workspace for spending, budgets, and savings goals.
+- Testnet users exploring non-custodial, goal-based saving with Soroban.
+- Developers evaluating a React Native, NestJS, and Stellar integration.
+- Reviewers who need repeatable contract tests and public ledger evidence.
+
+## 🔗 Current Testnet Contracts
+
+| Contract | Address | Explorer |
+| --- | --- | --- |
+| SAVE Savings Vault | `CALFEOYNTNJYB5HTUPYHHFHMNNYLYEBOCV43Z73J54G3CQNSH5VCNP7H` | [View on Stellar Expert](https://stellar.expert/explorer/testnet/contract/CALFEOYNTNJYB5HTUPYHHFHMNNYLYEBOCV43Z73J54G3CQNSH5VCNP7H) |
+| Native XLM SAC | `CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC` | [View on Stellar Expert](https://stellar.expert/explorer/testnet/contract/CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC) |
+
+These are public Testnet identifiers, not credentials. Deployments may be replaced as SAVE evolves; update the backend environment and contract documentation together after any redeployment.
+
+## 🛠️ Tech Stack
+
+- **Mobile:** Expo SDK 57, React Native 0.86, React 19, TypeScript, and Expo Router.
+- **Client data:** Zustand, TanStack Query, SQLite, SecureStore, and AsyncStorage.
+- **Device features:** Expo Camera, FileSystem, Local Authentication, and native development builds.
+- **Backend:** NestJS 11, MongoDB/Mongoose, Redis, BullMQ, and Swagger/OpenAPI.
+- **Stellar:** `@stellar/stellar-sdk`, Horizon, Stellar RPC, WalletConnect v2, and Freighter Mobile.
+- **Smart contract:** Rust, Soroban SDK, Stellar CLI, and the SAVE Savings Vault.
+- **Admin:** Next.js 16 and React 19.
+- **Local infrastructure:** Docker Compose, MongoDB, Redis, and MinIO-compatible object storage.
+
+## 🚀 Run SAVE Locally
+
+### Prerequisites
+
+- Node.js LTS and npm.
+- Docker with Docker Compose.
+- Android Studio or Xcode for a native development build.
+- Rust and the Stellar CLI for contract development.
+- A funded Stellar Testnet account and Freighter Mobile for the complete signing flow.
+- A public WalletConnect project ID.
+
+### 1. Install dependencies
+
+From the repository root:
+
+```bash
+npm install
+npm --prefix backend install
+npm --prefix admin install
+```
+
+### 2. Configure the environments
+
+```bash
+cp .env.example .env
+cp backend/.env.example backend/.env
+```
+
+Set `EXPO_PUBLIC_API_URL` to a backend URL reachable by the phone, such as `http://192.168.1.25:3000`. Add your public `EXPO_PUBLIC_WALLETCONNECT_PROJECT_ID`; values prefixed with `EXPO_PUBLIC_` are bundled into the client and must never contain secrets.
+
+Review the local MongoDB, Redis, MinIO, JWT, Stellar Testnet, callback, and contract settings in `backend/.env` before starting the API. The admin app can use `admin/.env.local` for its own API configuration.
+
+### 3. Start local services
+
+```bash
+docker compose up -d
+```
+
+This starts MongoDB on `27017`, Redis on `6379`, MinIO on `9000`, and the MinIO console on `9001`.
+
+### 4. Start the applications
+
+Run each process in a separate terminal from the repository root:
+
+```bash
+npm --prefix backend run start:dev
+npm --prefix admin run dev
+npm start
+```
+
+The API listens on `http://localhost:3000`, with Swagger UI at `http://localhost:3000/docs`. The admin dashboard uses the URL printed by Next.js, normally `http://localhost:3001` when the API already occupies port `3000`.
+
+### 5. Use a native development build
+
+SAVE includes native integrations and `expo-dev-client`, so use a development build for complete device testing:
+
+```bash
+npm run android
+# or, on macOS
+npm run ios
+```
+
+After changing `.env`, restart the development server with a clean Metro cache:
+
+```bash
+npx expo start -c
+```
+
+In the app, open **More → Stellar Testnet → Connect Freighter Mobile**. Use a dedicated Testnet-only wallet, approve the WalletConnect session, create a goal, and approve the prepared XDR in Freighter. Never enter a secret seed in SAVE or the backend.
+
+## 🧪 Test and Validate
+
+Run the application checks from the repository root:
+
+```bash
+npm run lint
+npx tsc --noEmit
+npm --prefix backend test
+npm run admin:build
+```
+
+Run the Soroban contract suite and build its Wasm artifact:
+
+```bash
+npm run contract:test
+npm run contract:build
+```
+
+The contract artifact is written to `contract/target/wasm32v1-none/release/save_savings_vault.wasm`. See the [test report](docs/DELIVERABLES_1_2_TEST_REPORT.md) for repeatable runtime checks and existing Testnet evidence.
+
+## 🚢 Deploy the Savings Vault
+
+Contract deployment is an explicit operator action. Use a funded Stellar CLI identity—never put its secret key in a command, environment file, application, or repository.
+
+Read the [contract deployment guide](docs/CONTRACT.md) before deploying. It documents the build artifact, current Wasm hash, deployment command, configuration update, and pre-Mainnet security requirements.
+
+> [!CAUTION]
+> A working Testnet deployment is not evidence of Mainnet readiness. Independent review, stronger invariant testing, recovery procedures, key custody, asset allowlists, operational controls, and legal review are required before real-value use.
+
+## 📦 Repository Map
+
+```text
+.
+├── src/ # Expo Router mobile application
+├── assets/ # App icons and image assets
+├── android/ # Native Android project
+├── ios/ # Native iOS project
+├── backend/ # NestJS API, persistence, and Stellar integration
+├── admin/ # Next.js operations dashboard
+├── contract/ # Soroban workspace and savings-vault contract
+├── docs/ # Architecture, contract, and verification evidence
+├── scripts/ # Project utility scripts
+├── docker-compose.yml # MongoDB, Redis, and MinIO services
+└── eas.json # Expo Application Services build profiles
+```
+
+## 📚 Documentation
+
+- [Stellar architecture](docs/STELLAR_ARCHITECTURE.md) — network decisions, trust boundaries, reconciliation, and non-goals.
+- [Savings vault contract](docs/CONTRACT.md) — interface, events, deployment, and security review.
+- [Deliverables 1–2 test report](docs/DELIVERABLES_1_2_TEST_REPORT.md) — acceptance evidence and repeatable verification.
+- [Combined Stellar implementation](docs/COMBINED_SOROBAN_STELLAR_IMPLEMENTATION.md) — implementation context across the app, API, and contract.
+
+## ⚠️ Alpha Boundaries
+
+Before evaluating SAVE, keep these constraints in view:
+
+- Blockchain flows target Stellar Testnet only.
+- Wallet linking is watch-only; SAVE does not provide custody or recovery.
+- Native XLM through its Testnet Stellar Asset Contract is the currently approved vault asset.
+- Mainnet, fiat ramps, yield, stablecoin trustlines, anchors/KYC, DeFi, rewards, sponsored fees, shared vaults, and smart-wallet recovery are not enabled.
+- A phone must be able to reach the backend and its wallet callback URL during end-to-end testing.
+- Offline or client-reported data is never represented as ledger-final.
+- Testnet assets have no real-world value, and the software has not completed a production security audit.
+
+## 🤝 Contributing
+
+Keep changes focused, preserve the non-custodial and off-chain privacy boundaries, and add tests beside behavior changes. Before opening a pull request, run the relevant mobile, backend, admin, and contract checks. Include screenshots for visible interface changes and update the associated architecture or contract document when a trust boundary changes.
+
+## 📄 License
+
+This repository includes an [MIT license](LICENSE).
diff --git a/STELLAR_SOROBAN_INTEGRATIONS.md b/STELLAR_SOROBAN_INTEGRATIONS.md
deleted file mode 100644
index 9b6e35a..0000000
--- a/STELLAR_SOROBAN_INTEGRATIONS.md
+++ /dev/null
@@ -1,292 +0,0 @@
-# Stellar and Soroban Integration Options for SAVE
-
-Assessment date: 2026-08-27
-
-## Purpose and scope
-
-This document catalogs the meaningful Stellar and Soroban integrations that fit the current SAVE project. It is a product and technical options map, not a claim that every option should be built.
-
-The current repository contains:
-
-- an Expo 57 / React Native client for Android, iOS, and web;
-- a NestJS API;
-- a Next.js admin application;
-- transaction, category, and budget features;
-- offline SQLite caching and Zustand state;
-- SecureStore, local authentication, linking, and web-browser capabilities; and
-- planned MongoDB, Redis/BullMQ, and object storage infrastructure.
-
-This is a strong base for a non-custodial savings and payments application. The recommended first product is a Stellar account/wallet plus stablecoin payments, followed by a Soroban savings-vault contract. Running an issuer, exchange, lending product, or custodial wallet is possible but changes the legal, operational, and security scope substantially.
-
-## Recommended product direction
-
-| Priority | Integration | Why it fits SAVE |
-| --- | --- | --- |
-| P0 | Read-only Stellar portfolio and transaction import | Adds real financial data without custody or signing risk. |
-| P0 | Connect or create a non-custodial account | Establishes the user's on-chain identity and balance source. |
-| P0 | Send/receive XLM and selected stablecoins | Maps directly to the existing income/expense and receipt flows. |
-| P0 | Sponsored account reserves and fee-bump transactions | Removes most XLM onboarding friction. |
-| P1 | Anchor deposit/withdrawal and KYC flows | Lets users move between fiat and Stellar assets. |
-| P1 | Soroban goal vault | Turns the current budgets/savings concept into enforceable on-chain savings rules. |
-| P1 | RPC event ingestion and reconciliation | Keeps mobile, backend, and admin views consistent with final ledger state. |
-| P2 | Cross-asset path payments and quotes | Allows “pay in one asset, receive another.” |
-| P2 | Shared savings, allowances, and recovery policies | Adds differentiated programmable-finance features. |
-| P3 | Rewards asset, DeFi, remittance operator, or custody | Valuable only after product demand and regulatory review are established. |
-
-## Integration catalog
-
-### 1. Accounts, wallets, and signing
-
-| Option | User experience | SAVE implementation | Notes |
-| --- | --- | --- | --- |
-| Watch-only account | Paste/scan a `G...` or `C...` address and view balances/activity. | Client validates the address; backend indexes it through Stellar RPC. | Safest first integration; no signing or custody. |
-| External wallet connection | User approves each transaction in a compatible wallet. | Build unsigned XDR or a SEP-7 request, deep-link to the wallet, then reconcile the submitted hash. | Best default when mobile wallet compatibility meets requirements. No secret key enters SAVE. |
-| App-managed non-custodial classic account | SAVE generates/imports an Ed25519 account and signs locally. | Encrypt the secret locally, gate signing with device authentication, and never send the secret to NestJS. | Requires backup/recovery, threat modeling, device-change flows, and a security audit. SecureStore alone is not a recovery strategy. |
-| Soroban smart wallet / contract account | Seedless passkey-style signing with programmable controls. | A Rust contract implements `__check_auth`; the app supplies passkey/device signatures and a relayer can submit transactions. | Strong future fit for spend limits, allowlists, recovery, session keys, and multi-factor policies. Passkey tooling must be proven on native Expo builds, not assumed from browser examples. |
-| Classic multisig account | Multiple people/devices approve sensitive actions. | Configure account signers, weights, and thresholds; collect signatures before submission. | Useful for joint savings, treasury, issuer, sponsor, and admin accounts. |
-| Custodial/omnibus wallet | SAVE controls funds and exposes internal user balances. | HSM/KMS signing, pooled account with muxed IDs or memos, withdrawals, reconciliation, risk controls, and compliance operations. | Not recommended for the first release. This is a materially different regulated and security-sensitive business. |
-| Account recovery | User recovers after losing a key/device. | SEP-30 recovery servers for classic accounts, or contract-account recovery policies. | Design before allowing material balances; never treat email login alone as sufficient authorization to move funds. |
-
-Relevant standards and guides: [wallet overview](https://developers.stellar.org/docs/build/apps/overview), [Wallet SDK](https://developers.stellar.org/docs/build/apps/wallet), [smart wallets](https://developers.stellar.org/docs/build/guides/contract-accounts/smart-wallets), [multisig](https://developers.stellar.org/docs/learn/fundamentals/transactions/signatures-multisig), and [active SEPs, including SEP-30](https://developers.stellar.org/docs/learn/fundamentals/stellar-ecosystem-proposals).
-
-### 2. Network data and portfolio features
-
-SAVE can add:
-
-- XLM, issued-asset, and contract-token balances;
-- trustlines and authorization status;
-- pending, successful, and failed on-chain transactions;
-- payment, transfer, mint, burn, clawback, and contract events;
-- claimable balances;
-- active offers and liquidity-pool positions;
-- account signers, thresholds, sponsorships, and reserve requirements;
-- Soroban contract state and savings-vault positions;
-- transaction explorer links and human-readable operation details; and
-- cost-basis or fiat-value reporting when paired with a separate trusted price source.
-
-Use Stellar RPC for live state, contract simulation/submission, recent transactions, and filtered events. RPC's recent transaction retention is limited, so the backend should persist normalized events and cursors. Use Hubble or Galexie for historical analytics rather than treating a public endpoint as the permanent accounting database. Horizon should be limited to integrations that still require its parsed resources, because Stellar marks it as nearing end-of-life. See the official [API comparison](https://developers.stellar.org/docs/data/apis) and [unified payment-event guide](https://developers.stellar.org/docs/build/guides/transactions/send-and-receive-payments).
-
-### 3. Payments and money movement
-
-| Integration | Application to SAVE |
-| --- | --- |
-| Native XLM payments | Send, receive, request, and record XLM. |
-| Issued-asset payments | Support selected stablecoins or other assets after validating code and issuer together. |
-| Contract-account payments | Transfer Stellar assets between classic `G...` and contract `C...` addresses through the Stellar Asset Contract (SAC). |
-| Payment requests | Produce QR codes and deep links for a prefilled destination, asset, amount, memo, or callback. SEP-7 supports delegated signing and payment requests. |
-| Contacts and aliases | Save verified addresses locally/server-side; optionally resolve human-readable addresses through SEP-2 federation. |
-| Pooled account routing | Use muxed accounts or memos to associate inbound funds with a user when operating a shared account. Enforce memo requirements where an exchange/anchor requires them. |
-| Claimable balances | Send an asset before a recipient has a trustline, add time predicates, or create time-bounded gifts/rewards. Include a reclaim path to avoid permanent unclaimed entries. |
-| Batched payments | Bundle up to the protocol's allowed operation count in a classic transaction for reimbursements or distributions. Smart-contract transactions have different one-operation constraints. |
-| Fee sponsorship | Pay users' network fees using fee-bump transactions without taking control of their funds. |
-| Reserve sponsorship | Sponsor account creation, trustlines, signers, offers, and other reserve-bearing entries. |
-| Merchant/receipt matching | Attach a stable internal reference using a memo where appropriate, then reconcile the chain event with the scanned receipt. Never place private receipt details on-chain. |
-
-References: [send and receive payments](https://developers.stellar.org/docs/build/guides/transactions/send-and-receive-payments), [SEP-7](https://developers.stellar.org/docs/build/apps/wallet/sep7), [claimable balances](https://developers.stellar.org/docs/build/guides/transactions/claimable-balances), [sponsored reserves](https://developers.stellar.org/docs/build/guides/transactions/sponsored-reserves), and [fee-bump transactions](https://developers.stellar.org/docs/build/guides/transactions/fee-bump-transactions).
-
-### 4. Fiat on/off-ramps, KYC, and remittances
-
-SAVE can consume an existing anchor rather than becoming one:
-
-- SEP-1: discover an anchor and its supported assets from `stellar.toml`;
-- SEP-10: authenticate a classic Stellar account to the anchor;
-- SEP-45: authenticate a contract account to an anchor;
-- SEP-12/SEP-9: collect and update required KYC fields;
-- SEP-24: open a hosted interactive deposit or withdrawal flow;
-- SEP-6: implement programmatic deposits and withdrawals;
-- SEP-38: show indicative or firm conversion quotes; and
-- SEP-31: participate in cross-border payment flows where the provider relationships and compliance model support it.
-
-The current `expo-web-browser`, `expo-linking`, and `saveproject` custom scheme can handle hosted-flow callbacks. Production should also configure HTTPS universal/app links and use development builds for realistic callback tests. The [Expo 57 Linking API](https://docs.expo.dev/versions/v57.0.0/sdk/linking/) warns that Expo Go URLs are not stable for authorization callbacks. Anchor support is described by the [Wallet SDK guide](https://developers.stellar.org/docs/build/apps/wallet/intro) and [Anchor Platform](https://developers.stellar.org/docs/platforms/anchor-platform).
-
-Becoming an anchor is also technically possible: the existing Docker/NestJS stack could run a business server beside Stellar Anchor Platform and implement KYC, quote, transaction-status, settlement, and callback endpoints. That option requires banking/payment partners, liquidity, sanctions and AML controls, data-retention policies, incident response, and jurisdiction-specific legal review. It should be treated as a separate program, not an ordinary app feature.
-
-### 5. Asset conversion and liquidity
-
-| Integration | What SAVE could expose | Risk/constraint |
-| --- | --- | --- |
-| Path payment | User spends XLM while the recipient receives a stablecoin, or vice versa. | Quote expiration, slippage bounds, trustlines, and route availability must be shown before signing. |
-| SDEX order | Buy/sell assets with limit offers and show open-order status. | Asset verification, thin liquidity, price impact, and user education. |
-| Liquidity-pool deposit/withdrawal | Track or manage LP positions. | Impermanent loss, reserve requirements, and financial-product disclosures. |
-| Soroban DEX/DeFi adapter | Route swaps or deposits to reviewed third-party contracts. | Contract, oracle, liquidity, upgrade, and governance risk; use allowlisted contract IDs by network. |
-
-Classic path payments can route through the Stellar decentralized exchange and protocol liquidity pools. See [path payments](https://developers.stellar.org/docs/build/guides/transactions/path-payments) and [Stellar liquidity](https://developers.stellar.org/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools).
-
-### 6. Soroban savings and finance contracts
-
-These are the most relevant custom-contract opportunities for SAVE:
-
-| Contract feature | Core behavior | Suggested priority |
-| --- | --- | --- |
-| Goal vault | Deposit XLM or an approved SAC asset toward a named goal; withdraw under defined owner and deadline rules. | P1 |
-| Time-locked savings | Prevent ordinary withdrawal until a timestamp/ledger deadline, with a clearly defined emergency path. | P1 |
-| Shared savings pot | Multiple members contribute; withdrawal requires threshold or role-based approval. | P2 |
-| Envelope vaults | Keep auditable balances for categories or goals while assets remain in contract custody. | P2 |
-| Allowance/spending policy | Permit a capped amount per period, recipient allowlist, or dual approval. | P2; often best as a smart-wallet policy. |
-| Milestone escrow | Release funds after payer/payee approval, deadline, or an authorized arbiter decision. | P2 |
-| Matching contribution | Sponsor matches eligible deposits up to a cap. | P2 |
-| Rewards distribution | Distribute an existing Stellar asset for savings streaks or program participation. | P2/P3 |
-| Round-up aggregation | Accumulate computed round-ups and periodically deposit them into a goal. | P2; computation and triggering remain off-chain. |
-| Recurring contribution | Store a schedule/allowance and let an authorized keeper submit due contributions. | P2; contracts do not initiate transactions by themselves. |
-| Conditional disbursement | Release funds based on approved attestations or oracle data. | P3; oracle trust must be explicit. |
-| Group lending / rotating savings | Contributions and scheduled payouts for a savings circle. | P3; high contract, default, identity, and regulatory risk. |
-| DeFi yield adapter | Deposit eligible assets into a reviewed lending/liquidity protocol and account for shares/yield. | P3; do not advertise principal safety or fixed yield. |
-| Governance | Member voting over shared treasury rules or upgrades. | P3. |
-| Proof/attestation | Publish a hash or minimal event proving a milestone or approved record. | Optional; never publish personal finance data. |
-
-Soroban contracts are Rust programs compiled to Wasm. They can authorize both account and contract addresses and can interact with Stellar assets through the SAC, but they cannot directly invoke the SDEX, claimable-balance, or sponsorship operations. Those classic operations must be composed outside the contract in separately authorized transactions. See the [Soroban overview](https://developers.stellar.org/docs/build/smart-contracts/overview), [contract authorization](https://developers.stellar.org/docs/build/guides/auth/contract-authorization), and [SAC documentation](https://developers.stellar.org/docs/tokens/stellar-asset-contract).
-
-### 7. Assets and tokens
-
-SAVE has four possible levels of token integration:
-
-1. **Display and transfer existing assets.** This is the recommended baseline. Maintain a reviewed allowlist keyed by `(network, asset code, issuer)` or contract ID.
-2. **Use existing assets in a vault.** Deploy/use their built-in SAC and accept only configured token contract IDs.
-3. **Issue a SAVE rewards asset.** A classic Stellar asset is normally preferable for a transferable loyalty/reward unit because it gains wallet, exchange, anchor, and SAC compatibility. Publish complete metadata in `/.well-known/stellar.toml`, separate issuer and distribution accounts, and protect issuer authority with cold/multisig controls.
-4. **Build a SEP-41 contract token or regulated token.** Do this only when protocol assets cannot express the required behavior. Custom tokens add contract and interoperability work; regulated/RWA tokens add identity, transfer restriction, clawback, disclosure, reserve, and legal obligations.
-
-Stellar explicitly recommends a protocol-issued asset plus SAC when it is sufficient. See [asset and contract-token comparison](https://developers.stellar.org/docs/tokens), [issuing an asset](https://developers.stellar.org/docs/tokens/how-to-issue-an-asset), [publishing asset information](https://developers.stellar.org/docs/tokens/publishing-asset-info), and the [token interface](https://developers.stellar.org/docs/tokens/token-interface).
-
-### 8. Authentication and identity protocols
-
-Possible additions include:
-
-- wallet ownership login using SEP-10 for classic accounts or SEP-45 for contract accounts;
-- an app session linked to one or more Stellar addresses;
-- KYC state and anchor customer IDs without putting PII on-chain;
-- federation names for easier addressing;
-- verified domain and asset/service discovery through SEP-1;
-- regulated-asset approval flows (SEP-8) where required; and
-- account/address identicons (SEP-33) to reduce address-selection mistakes.
-
-Wallet authentication proves control of an address; it does not prove a legal identity. Keep the current app user ID distinct from account address, KYC customer ID, and device credential.
-
-### 9. Admin, reconciliation, and operations
-
-The Next.js admin and NestJS backend can support:
-
-- per-network contract and asset allowlists;
-- sponsor account balance/reserve/fee monitoring;
-- transaction submission queue and idempotent retries;
-- RPC cursor checkpoints and reprocessing;
-- ledger-confirmation and failed-transaction reconciliation;
-- unmatched deposit, memo, receipt, and internal-record review;
-- vault totals and contract-event dashboards;
-- anchor transaction and KYC status support tools;
-- signer/threshold and issuer/distribution-account monitoring;
-- suspicious activity and velocity alerts;
-- contract Wasm hash, deployment, upgrade, and TTL tracking; and
-- audit exports that distinguish on-chain facts from editable app metadata.
-
-Redis/BullMQ is suitable for polling, retry, and reconciliation work, but MongoDB should contain durable idempotency records and the last processed ledger/cursor. A queue acknowledgement is not evidence of ledger finality.
-
-## Proposed architecture
-
-| Layer | Responsibility |
-| --- | --- |
-| Expo app | Address management, balance views, transaction review, local signing or wallet handoff, biometric confirmation, QR/deep links, anchor browser flows, and offline read cache. |
-| NestJS API | User/address associations, policies, unsigned transaction preparation, fee sponsorship, RPC access, event normalization, idempotency, anchor callbacks, and notifications. |
-| Soroban contracts | Minimal enforceable vault, escrow, shared-control, or smart-wallet rules; token custody only where the product requires it. |
-| MongoDB | Users, linked accounts, app metadata, normalized operations/events, reconciliation state, anchor references, and audit records. |
-| Redis/BullMQ | Event polling, retryable submissions, reconciliation, quote expiry, notification, and TTL-maintenance jobs. |
-| Next.js admin | Contract/asset configuration, exception handling, sponsor health, reconciliation, compliance status, and audit views. |
-| Stellar RPC | Current ledger state, simulation, submission, recent transaction lookup, and events. |
-| Hubble/Galexie or managed indexer | Long-range historical and analytical data when required. |
-
-## Required data-model changes
-
-The existing `ApiTransaction` is an app finance record and is not sufficient as a blockchain transaction. Preserve it, but add separate entities such as:
-
-- `StellarAccount`: user ID, network, address, account kind, label, custody mode, and verification status;
-- `Asset`: network, type, code, issuer or contract ID, decimals, home domain, and allowlist status;
-- `LedgerTransaction`: hash, envelope/result XDR references, source, ledger, timestamps, fee, status, and paging cursor;
-- `LedgerOperation` / `ContractEvent`: operation/event type, source, destination, asset, exact decimal amount, contract ID, topics, and raw reference;
-- `SigningRequest`: unsigned XDR, network passphrase, summary, expiration, nonce/idempotency key, signer set, and status;
-- `VaultPosition`: contract ID, owner, asset contract ID, deposited/withdrawn amounts, goal, deadline, and state;
-- `AnchorTransaction`: SEP type, anchor domain, external ID, status, quote ID, KYC customer ID, and sanitized callback data; and
-- `ChainLink`: relationship between a user-entered income/expense record and one or more ledger operations/events.
-
-Never store Stellar amounts in JavaScript `number` or MongoDB floating-point fields. Preserve the network's exact decimal string/integer representation and format only at the UI boundary. A ledger transaction may contain multiple operations, while one finance record may match multiple ledger events, so do not overload the current single `id/type/amount` record.
-
-## Expo 57 integration notes
-
-- The installed `expo-secure-store` is appropriate for small encrypted values, tokens, or a wrapped-key reference, but secrets need an explicit backup/recovery design. Review the exact [Expo 57 SecureStore API](https://docs.expo.dev/versions/v57.0.0/sdk/securestore/).
-- The installed `expo-local-authentication` can gate signing; Face ID requires a development build and its iOS permission configuration. See [Expo 57 LocalAuthentication](https://docs.expo.dev/versions/v57.0.0/sdk/local-authentication/).
-- The existing custom scheme supports callbacks, but production wallet/anchor flows should add verified universal/app links and strict route/parameter validation. See [Expo 57 Linking](https://docs.expo.dev/versions/v57.0.0/sdk/linking/).
-- `expo-web-browser` can host SEP-24/KYC flows, returning through the configured link. Never assume browser success means an on-chain transfer succeeded; reconcile with the anchor and ledger.
-- `@stellar/stellar-sdk` officially targets browser and Node.js environments. React Native compatibility and any required crypto/Buffer polyfills must be validated in an Expo development build before choosing client-side signing. A backend-only SDK integration avoids native bundling issues but cannot provide non-custodial signing by itself. See [Stellar client SDKs](https://developers.stellar.org/docs/tools/sdks/client-sdks).
-- The TypeScript Wallet SDK covers common wallet and anchor flows; use lower-level SDK/RPC calls for advanced operations and Soroban. Validate its native runtime behavior in this exact Expo/React Native version before adopting it.
-
-## Security, privacy, and correctness requirements
-
-- Default to Testnet until end-to-end reconciliation, recovery, and failure handling are proven.
-- Make the selected network unmistakable and bind every signature to the expected network passphrase.
-- Never send a user secret seed, decrypted key, passkey private material, or recovery secret to the backend or logs in a non-custodial design.
-- Show a decoded transaction summary—asset and issuer/contract, amount, destination, memo, contract, function, arguments, and maximum fee—before signing.
-- Simulate Soroban transactions immediately before signing and enforce resource-fee and expiration bounds.
-- Treat all deep links, wallet callbacks, anchor responses, RPC responses, and contract events as untrusted input.
-- Use destination, asset, issuer/contract, and network allowlists where a feature does not require arbitrary values.
-- Use idempotency keys and reconcile by transaction hash, ledger, operation/event identity, and cursor. Never mark a payment final from a client callback alone.
-- Keep PII, receipt images, budget names, notes, categories, and KYC documents off-chain. Store only minimal public identifiers or commitments when essential.
-- Separate sponsor, relayer, issuer, distribution, admin, and operational keys. Protect privileged keys with HSM/KMS or cold multisig; never place them in the mobile bundle or ordinary environment files.
-- Audit any contract that can custody or control value. Use property/fuzz tests, invariant tests, Testnet deployments, reproducible Wasm builds, verified source, upgrade controls, and an incident/pausing strategy appropriate to the custody model.
-- Plan contract storage TTL and restoration. TTL expiry is not a safe deadline mechanism, and extending/restoring state costs fees. See [Soroban storage guidance](https://developers.stellar.org/docs/build/guides/storage/storage-strategies).
-- Obtain legal review before custody, fiat ramps, rewards with monetary value, swaps, yield, lending, pooled funds, remittances, securities/RWAs, or operation in regulated jurisdictions.
-
-## Known limitations and non-goals
-
-- Soroban contracts do not execute on a timer and cannot initiate a transaction. Recurring deposits require a user, relayer, or keeper to submit an authorized invocation.
-- A Soroban contract cannot directly operate the classic SDEX, claimable balances, or sponsorships. The client/backend must build the relevant classic transactions.
-- Blockchain data is public; encryption elsewhere does not make an on-chain amount, address, or event private.
-- A Stellar address is not a verified person, and a confirmed transaction is not automatically a correctly categorized income/expense record.
-- On-chain balances do not provide historical fiat prices, tax lots, merchant identity, or exchange-rate truth. Those require separate data and accounting policies.
-- Offline mode can display cached data and queue intent, but it cannot truthfully confirm sequence numbers, simulation results, quotes, fees, or finality until reconnected.
-- “Stablecoin” does not guarantee redemption, price stability, liquidity, or regulatory availability. SAVE must verify issuers and communicate asset-specific risks.
-- Smart-contract programmability does not remove custody, consumer-protection, tax, sanctions, AML, or securities obligations.
-
-## Delivery roadmap
-
-### Phase 0 — Decisions and proof of compatibility
-
-1. Choose non-custodial external wallet, app-managed key, smart wallet, or watch-only scope.
-2. Choose Testnet asset allowlist and a managed/public RPC provider.
-3. Prove `@stellar/stellar-sdk`, Wallet SDK, required polyfills, deep links, SecureStore, and biometric confirmation in Android/iOS development builds and web.
-4. Define exact amount, network, account, ledger-event, and idempotency models.
-5. Write threat, custody, recovery, compliance, and privacy decisions before handling value.
-
-### Phase 1 — Read-only vertical slice
-
-1. Link a Testnet address.
-2. Import balances and payment events through RPC.
-3. Store cursors and normalized ledger data in the backend.
-4. Display explorer-verifiable activity and link it to optional SAVE categories.
-5. Add admin reconciliation and RPC-health views.
-
-### Phase 2 — Payments
-
-1. Build, decode, review, sign, submit, and reconcile Testnet payments.
-2. Add receive/request QR and deep-link flows.
-3. Add fee-bump and reserve sponsorship with strict quotas.
-4. Add trustline and claimable-balance handling for one reviewed stablecoin.
-5. Test timeout, duplicate submission, sequence conflict, fee surge, bad memo, wrong network, and callback spoofing cases.
-
-### Phase 3 — Fiat access
-
-1. Integrate one reviewed test anchor using SEP-1/10/12/24/38.
-2. Handle browser callbacks, anchor status, ledger status, and cancellation independently.
-3. Add production KYC/privacy/legal controls before any Mainnet launch.
-
-### Phase 4 — Goal vault
-
-1. Specify owner, asset, deposit, withdrawal, deadline, emergency, upgrade, fee, and TTL invariants.
-2. Implement and test the minimal Rust contract.
-3. Generate typed client bindings, simulate every invocation, and index contract events.
-4. Audit, deploy to Testnet, verify Wasm/source, and complete failure/recovery drills before Mainnet.
-
-### Phase 5 — Optional expansion
-
-Add shared savings, smart-wallet policies, path payments, recovery, rewards, remittances, or reviewed DeFi adapters only in response to a validated product need. Each should receive its own threat model and go/no-go review.
-
-## Final recommendation
-
-Build the first release as a non-custodial, Testnet-first wallet companion: watch/link an account, import balances and payments via RPC, send and request a reviewed asset with external or locally protected signing, sponsor fees/reserves, and reconcile every action through the backend. Then add one deliberately small Soroban goal-vault contract. This path reuses nearly every existing part of SAVE while keeping custody, contract, and regulatory risk bounded.
diff --git a/backend/.env.example b/backend/.env.example
index 79bed9c..eb3875c 100644
--- a/backend/.env.example
+++ b/backend/.env.example
@@ -10,3 +10,19 @@ S3_ACCESS_KEY=save-access-key
S3_SECRET_KEY=save-secret-key
JWT_SECRET=replace_with_secure_secret
+
+# Stellar Testnet only. Do not put secret seeds in this file.
+STELLAR_NETWORK=TESTNET
+STELLAR_NETWORK_PASSPHRASE=Test SDF Network ; September 2015
+STELLAR_HORIZON_URL=https://horizon-testnet.stellar.org
+STELLAR_RPC_URL=https://soroban-testnet.stellar.org
+STELLAR_FRIENDBOT_URL=https://friendbot.stellar.org
+STELLAR_VAULT_CONTRACT_ID=CALFEOYNTNJYB5HTUPYHHFHMNNYLYEBOCV43Z73J54G3CQNSH5VCNP7H
+STELLAR_XLM_SAC_ID=CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC
+# Maximum assembled Soroban fee in stroops (1000000000 = 100 XLM).
+STELLAR_MAX_SOROBAN_FEE=1000000000
+STELLAR_EVENT_POLL_MS=15000
+STELLAR_CALLBACK_BASE_URL=http://localhost:3000
+STELLAR_ORIGIN_DOMAIN=
+STELLAR_INTEGRITY_SIGNER_SECRET_FILE=
+EXPO_PUBLIC_WALLETCONNECT_PROJECT_ID=219c5a0dcc9ced2856f12d0df4a2d484
diff --git a/backend/android/.gitignore b/backend/android/.gitignore
new file mode 100644
index 0000000..1ea9b64
--- /dev/null
+++ b/backend/android/.gitignore
@@ -0,0 +1,19 @@
+# OSX
+#
+.DS_Store
+
+# Android/IntelliJ
+#
+build/
+.idea
+.gradle
+local.properties
+*.iml
+*.hprof
+.cxx/
+
+# generated inline modules
+app/src/main/java/inline/
+
+# Bundle artifacts
+*.jsbundle
diff --git a/backend/android/app/build.gradle b/backend/android/app/build.gradle
new file mode 100644
index 0000000..f2ae924
--- /dev/null
+++ b/backend/android/app/build.gradle
@@ -0,0 +1,182 @@
+apply plugin: "com.android.application"
+apply plugin: "org.jetbrains.kotlin.android"
+apply plugin: "com.facebook.react"
+
+def projectRoot = rootDir.getAbsoluteFile().getParentFile().getAbsolutePath()
+
+/**
+ * This is the configuration block to customize your React Native Android app.
+ * By default you don't need to apply any configuration, just uncomment the lines you need.
+ */
+react {
+ entryFile = file(["node", "-e", "require('expo/scripts/resolveAppEntry')", projectRoot, "android", "absolute"].execute(null, rootDir).text.trim())
+ reactNativeDir = new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsoluteFile()
+ hermesCommand = new File(["node", "--print", "require.resolve('hermes-compiler/package.json', { paths: [require.resolve('react-native/package.json')] })"].execute(null, rootDir).text.trim()).getParentFile().getAbsolutePath() + "/hermesc/%OS-BIN%/hermesc"
+ codegenDir = new File(["node", "--print", "require.resolve('@react-native/codegen/package.json', { paths: [require.resolve('react-native/package.json')] })"].execute(null, rootDir).text.trim()).getParentFile().getAbsoluteFile()
+
+ enableBundleCompression = (findProperty('android.enableBundleCompression') ?: false).toBoolean()
+ // Use Expo CLI to bundle the app, this ensures the Metro config
+ // works correctly with Expo projects.
+ cliFile = new File(["node", "--print", "require.resolve('@expo/cli', { paths: [require.resolve('expo/package.json')] })"].execute(null, rootDir).text.trim())
+ bundleCommand = "export:embed"
+
+ /* Folders */
+ // The root of your project, i.e. where "package.json" lives. Default is '../..'
+ // root = file("../../")
+ // The folder where the react-native NPM package is. Default is ../../node_modules/react-native
+ // reactNativeDir = file("../../node_modules/react-native")
+ // The folder where the react-native Codegen package is. Default is ../../node_modules/@react-native/codegen
+ // codegenDir = file("../../node_modules/@react-native/codegen")
+
+ /* Variants */
+ // The list of variants to that are debuggable. For those we're going to
+ // skip the bundling of the JS bundle and the assets. By default is just 'debug'.
+ // If you add flavors like lite, prod, etc. you'll have to list your debuggableVariants.
+ // debuggableVariants = ["liteDebug", "prodDebug"]
+
+ /* Bundling */
+ // A list containing the node command and its flags. Default is just 'node'.
+ // nodeExecutableAndArgs = ["node"]
+
+ //
+ // The path to the CLI configuration file. Default is empty.
+ // bundleConfig = file(../rn-cli.config.js)
+ //
+ // The name of the generated asset file containing your JS bundle
+ // bundleAssetName = "MyApplication.android.bundle"
+ //
+ // The entry file for bundle generation. Default is 'index.android.js' or 'index.js'
+ // entryFile = file("../js/MyApplication.android.js")
+ //
+ // A list of extra flags to pass to the 'bundle' commands.
+ // See https://github.com/react-native-community/cli/blob/main/docs/commands.md#bundle
+ // extraPackagerArgs = []
+
+ /* Hermes Commands */
+ // The hermes compiler command to run. By default it is 'hermesc'
+ // hermesCommand = "$rootDir/my-custom-hermesc/bin/hermesc"
+ //
+ // The list of flags to pass to the Hermes compiler. By default is "-O", "-output-source-map"
+ // hermesFlags = ["-O", "-output-source-map"]
+
+ /* Autolinking */
+ autolinkLibrariesWithApp()
+}
+
+/**
+ * Set this to true in release builds to optimize the app using [R8](https://developer.android.com/topic/performance/app-optimization/enable-app-optimization).
+ */
+def enableMinifyInReleaseBuilds = (findProperty('android.enableMinifyInReleaseBuilds') ?: false).toBoolean()
+
+/**
+ * The preferred build flavor of JavaScriptCore (JSC)
+ *
+ * For example, to use the international variant, you can use:
+ * `def jscFlavor = 'org.webkit:android-jsc-intl:+'`
+ *
+ * The international variant includes ICU i18n library and necessary data
+ * allowing to use e.g. `Date.toLocaleString` and `String.localeCompare` that
+ * give correct results when using with locales other than en-US. Note that
+ * this variant is about 6MiB larger per architecture than default.
+ */
+def jscFlavor = 'io.github.react-native-community:jsc-android:2026004.+'
+
+android {
+ ndkVersion rootProject.ext.ndkVersion
+
+ buildToolsVersion rootProject.ext.buildToolsVersion
+ compileSdk rootProject.ext.compileSdkVersion
+
+ namespace 'com.pjpbrionfwdpeers.saveapi'
+ defaultConfig {
+ applicationId 'com.pjpbrionfwdpeers.saveapi'
+ minSdkVersion rootProject.ext.minSdkVersion
+ targetSdkVersion rootProject.ext.targetSdkVersion
+ versionCode 1
+ versionName "1.0.0"
+
+ buildConfigField "String", "REACT_NATIVE_RELEASE_LEVEL", "\"${findProperty('reactNativeReleaseLevel') ?: 'stable'}\""
+ }
+ signingConfigs {
+ debug {
+ storeFile file('debug.keystore')
+ storePassword 'android'
+ keyAlias 'androiddebugkey'
+ keyPassword 'android'
+ }
+ }
+ buildTypes {
+ debug {
+ signingConfig signingConfigs.debug
+ }
+ release {
+ // Caution! In production, you need to generate your own keystore file.
+ // see https://reactnative.dev/docs/signed-apk-android.
+ signingConfig signingConfigs.debug
+ def enableShrinkResources = findProperty('android.enableShrinkResourcesInReleaseBuilds') ?: 'false'
+ shrinkResources enableShrinkResources.toBoolean()
+ minifyEnabled enableMinifyInReleaseBuilds
+ proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
+ def enablePngCrunchInRelease = findProperty('android.enablePngCrunchInReleaseBuilds') ?: 'true'
+ crunchPngs enablePngCrunchInRelease.toBoolean()
+ }
+ }
+ packagingOptions {
+ jniLibs {
+ def enableLegacyPackaging = findProperty('expo.useLegacyPackaging') ?: 'false'
+ useLegacyPackaging enableLegacyPackaging.toBoolean()
+ }
+ }
+ androidResources {
+ ignoreAssetsPattern '!.svn:!.git:!.ds_store:!*.scc:!CVS:!thumbs.db:!picasa.ini:!*~'
+ }
+}
+
+// Apply static values from `gradle.properties` to the `android.packagingOptions`
+// Accepts values in comma delimited lists, example:
+// android.packagingOptions.pickFirsts=/LICENSE,**/picasa.ini
+["pickFirsts", "excludes", "merges", "doNotStrip"].each { prop ->
+ // Split option: 'foo,bar' -> ['foo', 'bar']
+ def options = (findProperty("android.packagingOptions.$prop") ?: "").split(",");
+ // Trim all elements in place.
+ for (i in 0.. 0) {
+ println "android.packagingOptions.$prop += $options ($options.length)"
+ // Ex: android.packagingOptions.pickFirsts += '**/SCCS/**'
+ options.each {
+ android.packagingOptions[prop] += it
+ }
+ }
+}
+
+dependencies {
+ // The version of react-native is set by the React Native Gradle Plugin
+ implementation("com.facebook.react:react-android")
+
+ def isGifEnabled = (findProperty('expo.gif.enabled') ?: "") == "true";
+ def isWebpEnabled = (findProperty('expo.webp.enabled') ?: "") == "true";
+ def isWebpAnimatedEnabled = (findProperty('expo.webp.animated') ?: "") == "true";
+
+ if (isGifEnabled) {
+ // For animated gif support
+ implementation("com.facebook.fresco:animated-gif:${expoLibs.versions.fresco.get()}")
+ }
+
+ if (isWebpEnabled) {
+ // For webp support
+ implementation("com.facebook.fresco:webpsupport:${expoLibs.versions.fresco.get()}")
+ if (isWebpAnimatedEnabled) {
+ // Animated webp support
+ implementation("com.facebook.fresco:animated-webp:${expoLibs.versions.fresco.get()}")
+ }
+ }
+
+ if (hermesEnabled.toBoolean()) {
+ implementation("com.facebook.react:hermes-android")
+ } else {
+ implementation jscFlavor
+ }
+}
diff --git a/backend/android/app/debug.keystore b/backend/android/app/debug.keystore
new file mode 100644
index 0000000..364e105
Binary files /dev/null and b/backend/android/app/debug.keystore differ
diff --git a/backend/android/app/proguard-rules.pro b/backend/android/app/proguard-rules.pro
new file mode 100644
index 0000000..551eb41
--- /dev/null
+++ b/backend/android/app/proguard-rules.pro
@@ -0,0 +1,14 @@
+# Add project specific ProGuard rules here.
+# By default, the flags in this file are appended to flags specified
+# in /usr/local/Cellar/android-sdk/24.3.3/tools/proguard/proguard-android.txt
+# You can edit the include path and order by changing the proguardFiles
+# directive in build.gradle.
+#
+# For more details, see
+# http://developer.android.com/guide/developing/tools/proguard.html
+
+# react-native-reanimated
+-keep class com.swmansion.reanimated.** { *; }
+-keep class com.facebook.react.turbomodule.** { *; }
+
+# Add any project specific keep options here:
diff --git a/backend/android/app/src/debug/AndroidManifest.xml b/backend/android/app/src/debug/AndroidManifest.xml
new file mode 100644
index 0000000..3ec2507
--- /dev/null
+++ b/backend/android/app/src/debug/AndroidManifest.xml
@@ -0,0 +1,7 @@
+
+
+
+
+
+
diff --git a/backend/android/app/src/debugOptimized/AndroidManifest.xml b/backend/android/app/src/debugOptimized/AndroidManifest.xml
new file mode 100644
index 0000000..3ec2507
--- /dev/null
+++ b/backend/android/app/src/debugOptimized/AndroidManifest.xml
@@ -0,0 +1,7 @@
+
+
+
+
+
+
diff --git a/backend/android/app/src/main/AndroidManifest.xml b/backend/android/app/src/main/AndroidManifest.xml
new file mode 100644
index 0000000..b006a48
--- /dev/null
+++ b/backend/android/app/src/main/AndroidManifest.xml
@@ -0,0 +1,32 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainActivity.kt b/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainActivity.kt
new file mode 100644
index 0000000..0ac3371
--- /dev/null
+++ b/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainActivity.kt
@@ -0,0 +1,61 @@
+package com.pjpbrionfwdpeers.saveapi
+
+import android.os.Build
+import android.os.Bundle
+
+import com.facebook.react.ReactActivity
+import com.facebook.react.ReactActivityDelegate
+import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.fabricEnabled
+import com.facebook.react.defaults.DefaultReactActivityDelegate
+
+import expo.modules.ReactActivityDelegateWrapper
+
+class MainActivity : ReactActivity() {
+ override fun onCreate(savedInstanceState: Bundle?) {
+ // Set the theme to AppTheme BEFORE onCreate to support
+ // coloring the background, status bar, and navigation bar.
+ // This is required for expo-splash-screen.
+ setTheme(R.style.AppTheme);
+ super.onCreate(null)
+ }
+
+ /**
+ * Returns the name of the main component registered from JavaScript. This is used to schedule
+ * rendering of the component.
+ */
+ override fun getMainComponentName(): String = "main"
+
+ /**
+ * Returns the instance of the [ReactActivityDelegate]. We use [DefaultReactActivityDelegate]
+ * which allows you to enable New Architecture with a single boolean flags [fabricEnabled]
+ */
+ override fun createReactActivityDelegate(): ReactActivityDelegate {
+ return ReactActivityDelegateWrapper(
+ this,
+ BuildConfig.IS_NEW_ARCHITECTURE_ENABLED,
+ object : DefaultReactActivityDelegate(
+ this,
+ mainComponentName,
+ fabricEnabled
+ ){})
+ }
+
+ /**
+ * Align the back button behavior with Android S
+ * where moving root activities to background instead of finishing activities.
+ * @see onBackPressed
+ */
+ override fun invokeDefaultOnBackPressed() {
+ if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.R) {
+ if (!moveTaskToBack(false)) {
+ // For non-root activities, use the default implementation to finish them.
+ super.invokeDefaultOnBackPressed()
+ }
+ return
+ }
+
+ // Use the default back button implementation on Android S
+ // because it's doing more than [Activity.moveTaskToBack] in fact.
+ super.invokeDefaultOnBackPressed()
+ }
+}
diff --git a/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainApplication.kt b/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainApplication.kt
new file mode 100644
index 0000000..82a3159
--- /dev/null
+++ b/backend/android/app/src/main/java/com/pjpbrionfwdpeers/saveapi/MainApplication.kt
@@ -0,0 +1,45 @@
+package com.pjpbrionfwdpeers.saveapi
+
+import android.app.Application
+import android.content.res.Configuration
+
+import com.facebook.react.PackageList
+import com.facebook.react.ReactApplication
+import com.facebook.react.ReactNativeApplicationEntryPoint.loadReactNative
+import com.facebook.react.ReactPackage
+import com.facebook.react.ReactHost
+import com.facebook.react.common.ReleaseLevel
+import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint
+
+import expo.modules.ApplicationLifecycleDispatcher
+import expo.modules.ExpoReactHostFactory
+
+class MainApplication : Application(), ReactApplication {
+
+ override val reactHost: ReactHost by lazy {
+ ExpoReactHostFactory.getDefaultReactHost(
+ context = applicationContext,
+ packageList =
+ PackageList(this).packages.apply {
+ // Packages that cannot be autolinked yet can be added manually here, for example:
+ // add(MyReactNativePackage())
+ }
+ )
+ }
+
+ override fun onCreate() {
+ super.onCreate()
+ DefaultNewArchitectureEntryPoint.releaseLevel = try {
+ ReleaseLevel.valueOf(BuildConfig.REACT_NATIVE_RELEASE_LEVEL.uppercase())
+ } catch (e: IllegalArgumentException) {
+ ReleaseLevel.STABLE
+ }
+ loadReactNative(this)
+ ApplicationLifecycleDispatcher.onApplicationCreate(this)
+ }
+
+ override fun onConfigurationChanged(newConfig: Configuration) {
+ super.onConfigurationChanged(newConfig)
+ ApplicationLifecycleDispatcher.onConfigurationChanged(this, newConfig)
+ }
+}
diff --git a/backend/android/app/src/main/res/drawable-hdpi/splashscreen_logo.png b/backend/android/app/src/main/res/drawable-hdpi/splashscreen_logo.png
new file mode 100644
index 0000000..31df827
Binary files /dev/null and b/backend/android/app/src/main/res/drawable-hdpi/splashscreen_logo.png differ
diff --git a/backend/android/app/src/main/res/drawable-mdpi/splashscreen_logo.png b/backend/android/app/src/main/res/drawable-mdpi/splashscreen_logo.png
new file mode 100644
index 0000000..ef243aa
Binary files /dev/null and b/backend/android/app/src/main/res/drawable-mdpi/splashscreen_logo.png differ
diff --git a/backend/android/app/src/main/res/drawable-xhdpi/splashscreen_logo.png b/backend/android/app/src/main/res/drawable-xhdpi/splashscreen_logo.png
new file mode 100644
index 0000000..e9d5474
Binary files /dev/null and b/backend/android/app/src/main/res/drawable-xhdpi/splashscreen_logo.png differ
diff --git a/backend/android/app/src/main/res/drawable-xxhdpi/splashscreen_logo.png b/backend/android/app/src/main/res/drawable-xxhdpi/splashscreen_logo.png
new file mode 100644
index 0000000..d61da15
Binary files /dev/null and b/backend/android/app/src/main/res/drawable-xxhdpi/splashscreen_logo.png differ
diff --git a/backend/android/app/src/main/res/drawable-xxxhdpi/splashscreen_logo.png b/backend/android/app/src/main/res/drawable-xxxhdpi/splashscreen_logo.png
new file mode 100644
index 0000000..4aeed11
Binary files /dev/null and b/backend/android/app/src/main/res/drawable-xxxhdpi/splashscreen_logo.png differ
diff --git a/backend/android/app/src/main/res/drawable/ic_launcher_background.xml b/backend/android/app/src/main/res/drawable/ic_launcher_background.xml
new file mode 100644
index 0000000..883b2a0
--- /dev/null
+++ b/backend/android/app/src/main/res/drawable/ic_launcher_background.xml
@@ -0,0 +1,6 @@
+
+ -
+
+
+
\ No newline at end of file
diff --git a/backend/android/app/src/main/res/drawable/rn_edit_text_material.xml b/backend/android/app/src/main/res/drawable/rn_edit_text_material.xml
new file mode 100644
index 0000000..5c25e72
--- /dev/null
+++ b/backend/android/app/src/main/res/drawable/rn_edit_text_material.xml
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+