Introduction

dolphinze is a cloud-based SaaS platform providing chain-agnostic, compliant, and programmable payroll infrastructure for global contractors. The system supports both fiat and crypto payouts, streamlining multi-currency disbursements for businesses and platforms that engage contractors.

The infrastructure serves two primary users:

• Employers / Payers — who create and manage contracts, schedule payrolls, and fund payouts.
• Contractors / Payees — who receive payments, set payout preferences, manage work relationships, and off-ramp earnings to their local ecosystem.

Architecture Overview

Physical Architecture

At a high level, the platform follows standard platforms for web-based SaaS platforms. There’s a frontend hosted in Netlify and a backend exposing an API. The backend stores data in PostgreSQL and includes a number of background services which handle asynchronous responsibilities. The backend is hosted in DigitalOcean. User management is delegated to firebase which is a google service for user authentication.

Technical Architecture

Explanation:

• Information enters the system synchronously via route handlers and asynchronously via the command queue.

  • Most input comes in the form of API requests which are generated by the frontend.
  • Some input comes in the from of webhooks which are registered with third party APIs to track external changes.
  • Other input comes in the form of background subscriptions. The above diagram depicts the stellar transactions event source as one such entrypoint.

• Regardless of the source, information is persisted into an immutable event store and then used to evolve an in-memory state representing various aggregates (employers, contracts, payments, contractors, accounts, etc)

• The event store servers a number of distinct functions:

  • Regeneration of application state on startup and deployment
  • Functional mechanism for propagating changes to external entities via persistent subscribers reacting to these changes.
    • These subscribers are encoded as yellow in the diagram.
  • Projections in the form of read models which are query-friendly representations of transactions, users, contracts etc.

• Persistence - all input is persisted in terms of an immutable event store which serves as an authoritative history of past events that define the current state of the system and functions as a mechanism for a set of subscribers to react by emitting necessary info in the form of API requests to their party APIs.

  • Example events include PaymentApproved, PaymentStarted, PaymentCompleted, ContractExecuted, ContractDelivered, EmployerKCYSuceeded and so on.

  Application Schematic Diagram

  

This diagram illustrates the interaction between user roles, services, and integrations:

• Employers: Configure contracts, fund payroll via the Funding UI, and manage disbursements through approval workflows.
• Contractors: Choose payout preferences (e.g., crypto splits, bank off-ramps), generate invoices, and manage contracts within their portal.