All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog.
- Renamed properties and environment variables related to Email Registration Support #412
- Renamed
MAX_INVITATION_SMS_RESEND_ATTEMPT
environment variable toMAX_INVITATION_RESEND_ATTEMPTS
- Renamed
organization.sms_resend_interval
toorganization.receiver_invitation_resend_interval_days
- Renamed
organization.sms_registration_message_template
toorganization.receiver_registration_message_template
- Renamed
disbursement.sms_registration_message_template
todisbursement.receiver_registration_message_template
- Renamed
Release of the Stellar Disbursement Platform v2.1.0. This release introduces the option to set different distribution account signers per tenant, as well as Circle support, so the tenant can choose to run their payments through the Circle API rather than directly on the Stellar network.
This version is only compatible with the stellar/stellar-disbursement-platform-frontend version 2.1.0
.
- Update the name of the account types used for Distribution Accounts to be more descriptive. #285, #311
- When provisioning a tenant, indicate the Distribution account signer type #319
- The DistributionAccountResolver now surfaces the tenant's CircleWalletID for Circle-using tenants #328
- Disable asset management calls when the tenant is using Circle #322
- Bump version of github.com/stellar/go to become compatible with Protocol 21.
- Add a new verification type called
YEAR_MONTH
#369 - Add the ability to use different signature types per tenant, allowing for more flexibility in the signature service. #289
- Add support to provision tenants with
accountType=DISTRIBUTION_ACCOUNT.CIRCLE.DB_VAULT
#330 - Circle SDK integration for the backend. #321
- Implement CircleService on top of the CircleClient, in order to automatically route the calls through the correct tenant based on the tenant value saved in the context #331
- Add support for Circle-using tenants when validating the tenant available balance upon disbursement start #309, #336
- Implement joho/godotenv loader #324
- Add support for Circle-using tenants to the
db setup-for-network
CLI command #327 - Implement the
GET /balances
endpoint that returns the Circle balance when the tenant is using Circle #325, #329 - Implement the
PATCH /organization/circle-config
endpoint that allows Circle configuration to be updated for Circle-using tenants #326, #332, #334 - Send Stellar payments through Circle when the tenant uses a CIRCLE distribution account #333
- Implement Circle reconciliation through polling #339, #347
- Add Circle transfer ID to GET /payments endpoints #346
- Add function to migrate data from a single-tenant to a multi-tenant instance #351
- Invalidate Circle Distribution Account Status upon receiving auth error #350, 359
- Add retry for circle 429 requests #362
- Separate Stellar and Circle payment jobs #366, #374
- Misc
- Fix SDP helm charts #323, #375
- Fix CF 429 response and anchor patch transaction job for circle accounts #361
- Select the correct error object used in a crash-reporter alert #365
- Fixes post python migration #367
- Make
PATCH /receivers/:id
validation consistent #371
- Security patch for gorilla/schema and rs/cors #345
- Bump versions of getsentry/sentry-go and gofiber/fiber #352
- Deprecated the use of
DISTRIBUTION_SIGNER_TYPE
, since this information is now provided when provisioning a tenant #319. - Remove Freedom Wallet from the list of pubnet wallets #372
Release of the Stellar Disbursement Platform v2.0.0. This release introduces multi-tenancy support, allowing multiple tenants (organizations) to use the platform simultaneously.
Each organization has its own set of users, receivers, disbursements, etc.
This version is only compatible with the stellar/stellar-disbursement-platform-frontend version 2.0.0
.
- Support multi-tenant CLI
- Use DB connection pool as dependency injection #207
- Make receiver registration handler tenant-aware #117
- Tag log entries with tenant metadata #192
- Use
DistributionAccountResolver
instead of passing around distribution public key #212 - Make provision new tenant an atomic operation #233
- Make
ready_payments_cancellation
job multi-tenant #223
- Tenant Provisioning & Onboarding #84
- Tenant Authentication Middleware #92
- Multi-tenancy connection pool & data source manager #86
- Generate multitenant SEP-1 TOML file #111
- Prepare Signature Service & TSS to support Multi-tenancy
- Add signature service with configurable distribution accounts #174
- Aggregate all tx submission dependencies under
SubmitterEngine
#165 - Add configurable signature service type #160
- Allow signature service to be dependency-injected #158
- Use dependency-injected signature service in
channel-account
CLI commands #156
- '/tenant' endpoint
- Patch incoming TSS events to Anchor platform #134
- Update DB structure so that TSS resources can be shared by multiple SDP tenants
- Add host distribution account awareness #172
- Wire distribution account to tenant admin table during user provisioning #198
- Prepare transaction submission table to reference tenant #142
- Kafka message broker support
- Implement
DistributionAccountDBSignatureClient
#197 - Create tenant distribution account during provisioning #224
- Enable payments scheduler job as an alternative to using Kafka #230
- Add default tenant capability to start the SDP in a single tenant mode #249
- Add script to migrate SDP v1.1.6 to V2.x.x #267
- Admin API authentication/authorization #201
- Enable security protocols for Kafka
- Bump google.golang.org/protobuf from 1.31.0 to 1.33.0. #270
- Bump golang.org/x/crypto from v0.17.0 to v0.21.0. #269
Attention, this version is compatible with the frontend version 1.1.2.
- Update the
PATCH /receivers/{id}
request, so a receiver's verification info is not just inserted but upserted. The update part of the upsert only takes place if the verification info has not been confirmed yet. #205 - Update the order of the verification field that is shown to the receiver during the SEP-24 flow. The order was
(updated_at DESC)
and was updated to the composed sorting(updated_at DESC, rv.verification_field ASC)
to ensure consistency when multiple verification fields share the sameupdated_at
value. - Improve information in the error message returned when the disbursement instruction contains a verification info that is different from an already existing verification info that was already confirmed by the receiver. #178
- When adding an asset, make sure to trim the spaces fom the issuer field. #185
- Bump Go version from 1.19 to 1.22, and upgraded the version of some CI tools. #196
- Add rate-limiter in both in the application and the kubernetes deployment. #195
- Trim whitespaces for all disbursement instruction fields during CSV upload to avoid duplication of data #211
- Upgrade golang version to 1.22.1 for security reasons #216
- Fix the insufficient balance validation by only considering payments with same asset of the disbursement being started #202
- Update
golang.org/x/crypto
version to v0.17.0 for security reasons #202
- SEP-24 registration flow not working properly when the phone number was not found in the DB #187
- Fix distribution account balance validation that fails when the intended asset is XLM #186
- Re-add missing recaptcha script #179
- TSS amount precision #176
- Change
POST /disbursements
to accept different verification types #103 - Change SEP-24 Flow to display different verifications based on disbursement verification type #116
- Add sorting to
GET /users
endpoint #104 - Change read permission for receiver details to include business roles #144
- Add support for unique payment ID to disbursement instructions file as an optional field in
GET /payments/{id}
#131 - Add support for SMS preview & editing before sending a new disbursement #146
- Add metadata for users that created and started a disbursement in disbursement details
GET /disbursements
,GET /disbursements/{id}
#151 - Update CI check to run the exhaustive validator #163
- Preload reCAPTCHA script in attempt to mitigate component loading issues upon login #152
- Validate distribution account balance before starting disbursement #161
- Support automatic cancellation of payments in
READY
status after a certain time period #121 - API endpoint for cancelling payments in
READY
status:PATCH /payments/{id}/status
#130 - Use CI to make sure the helm README is up to date #164
- Verification DOB validation missing when date is in the future #101
- Support disbursements from two or more wallet providers to the same address #87
- [TSS] Stale channel account not cleared after switching distribution keys #91
- Make setup-wallets-for-network tests more flexible #95
- Make
POST /assets
idempotent #122 - Add missing space when building query #121
- Stellar Protocol 20 Horizon SDK upgrade #107
- Coinspect Issues:
- Update log message for better debugging. #125
- Fix client_domain from the Viobrant Assist wallet. #126
- API endpoints for managing Wallet Providers:
- Introduced metrics and Grafana dashboard for monitoring payment transactions in TSS. #21
- TSS documentation. #25
- Phone number validation before sending OTP. #38
- Add Vibrant Assist RC to the list of supported wallets in pubnet #43
- Store Anchor Platform transaction ID in the database when registering a new receiver. #44
- Documentation for
CRASH_TRACKER_TYPE
env variable. #49 - Add a job to periodically sync the transaction status back to the Anchor Platform #55
- Introduce a retry mechanism for SMS invitations. #60
- Add proper error messages when receiver exceeds the maximum number of attempts to validate their PII. #62
- Add validation and flags to countries dropdown during receiver registration. #33
- Update transaction worker to use Crash Tracker on failed transactions #39
- Increase the default maximum number of attempts for a receiver to validate their PII. #56
- Prevent users from deactivating their own accounts. #58
- Stop enforcing ECDSA only and allow any EC public/private keys at least as strong as EC256 #61
- Refactor SMS invitation service #66
- Removed the environment variables
MAX_RETRIES
andMIN_DAYS_BETWEEN_RETRIES
. - Added the environment variable
MAX_INVITATION_SMS_RESEND_ATTEMPTS
to control the maximum number of attempts to send an SMS invitation. The default value is 3.
- Removed the environment variables
- API Tweaks:
- Stellar.Expert URL in env-config.js for dev environment setup. #34
- Patch the correct transaction data fields in AnchorPlatform. #40
- SEP-10 domain configuration for Vibrant wallet on Testnet. #42
- The SMS invitation link for XLM asset. #46
- Added application activity logs for account lifecycle, password management and user access patterns. #29
- Support to XLM disbursements. #1
- Helm chart documentation. #9
PATCH /profile/reset-password
endpoint to reset the password. #18
- Helmchart changes:
- Default
MAX_BASE_FEE
is now higher, to prevent low-fee error responses. #8 - Changed job frequency for more real-time updates. #12
- Change OTP message for better UX. #23
- API tweaks:
- TSS Channel Account management commands now can handle parallel calls. #6
- Horizon error parsing to use the default
HorizonErrorWrapper
class. #13 - API response that should be 401 instead of 500. #14
- Removed CLI flag that could disable private key encryption in the database. $24
- Add job to periodically check if the AP is auth protected. #10
- Add stronger password validation throughout the project. #22
First Release Candidate of the Stellar Disbursement Platform, a tool used to make bulk payments to a list of recipients based on their phone number and a confirmation date. This repository is backend-only, and the frontend version can be found at stellar/stellar-disbursement-platform-frontend. Their version numbers are meant to be kept in sync.
The basic process of this product starts with an organization supplying a CSV file which includes the recipients' phone number, transfer amount, and essential customer validation data such as the date of birth.
The platform subsequently sends an SMS to the recipient, which includes a deep link to the wallet. This link permits recipients with compatible wallets to register their wallet on the SDP. During this step, they are required to verify their phone number and additional customer data through the SEP-24 interactive deposit flow, where this data is shared directly with the backend through a webpage inside the wallet, but the wallet itself does not have access to this data.
Upon successful verification, the SDP will transfer the funds directly to the recipient's wallet. When the recipient's wallet has been successfully associated with their phone number in the SDP, all subsequent payments will occur automatically.