REFI2 Security Architecture

Overview

REFI2 data is encrypted in transit and at rest on every layer, access is gated by strong identity, and signed documents are cryptographically sealed. The controls below are built against the AICPA SOC 2 Trust Services Criteria for Security, Availability, and Confidentiality. No independent SOC 2 examination has been performed yet. This document describes the controls an auditor would test.

The platform has three applications. The investor portal serves the web application, the on-chain dashboard, and the administrative console. The data room shares confidential documents with investors. The e-signature service executes agreements. All three run on managed cloud infrastructure whose providers hold their own SOC 2 Type II and ISO/IEC 27001 attestations, listed in the Infrastructure section.

Encryption in transit

Every connection to the platform is encrypted with TLS, and all three applications negotiate TLS 1.3 with modern clients (verified October 14, 2026).

TLS terminates at a global edge network that also absorbs volumetric DDoS traffic before it reaches the application. Traffic between the application runtime and the managed databases travels either over TLS or over the hosting provider’s encrypted private network, and never crosses the public internet in clear text.

TLS 1.3 removes every cipher and handshake mode that earlier versions were attacked through (RC4, CBC padding oracles, RSA key transport, and renegotiation). With AEAD ciphers, any modification of data in flight is detected and the connection is dropped.

Encryption at rest

The storage layer encrypts all stored data. Secrets that must stay protected even if the whole database leaks are encrypted a second time by the application.

Application-layer encryption keys live only in the runtime environment, separate from the database. A copy of the database alone is not enough to recover a second-factor secret or a protected link password.

XChaCha20-Poly1305 is an authenticated cipher, so any change to the ciphertext makes decryption fail instead of returning altered data. Its 192-bit nonce is generated randomly per value, which removes the nonce-reuse risk that affects shorter-nonce ciphers.

The identity verification flow keeps personal data on the server. The administrative console receives masked values (“M. W.”, partially hidden emails), and revealing one full record is a separate, logged request.

Identity and access control

Every request is authenticated before it reaches application logic, and the most powerful role on the platform cannot be granted by a single person.

Administrative authority over the on-chain protocol (mint, freeze, and emergency pause) sits in an M-of-N multisignature wallet. No single key, laptop, or employee can execute a privileged action. The same member list decides who may open the administrative console, so revoking a member on chain removes their console access as well.

Passkeys (WebAuthn/FIDO2) bind the credential to the domain, which makes phishing pages unable to replay it. Login and sensitive endpoints are rate limited, and forms open to the public carry bot protection with a privacy-preserving challenge.

Access to production systems, the administrative console, and the multisignature wallets is reviewed manually every quarter. With a small team every grant is checked by name, and access is revoked immediately when someone leaves. Enterprise single sign-on (SAML) and SCIM provisioning are not offered, because the number of accounts on each side is small enough to manage directly.

Document integrity

A signed agreement on the platform cannot be altered, backdated, or have an event silently removed without the change being detectable.

Each completed document is sealed with an X.509 digital signature over the PDF. Any byte changed after sealing breaks the signature, and standard PDF readers show the document as modified. Every seal carries an RFC 3161 trusted timestamp from an independent timestamp authority, proving when the document existed in its final form. In production the service refuses to seal a document if no timestamp authority is reachable.

The signing audit trail is tamper-evident. Every event (sent, opened, signed, declined, or completed) is written with the actor’s identity, time, IP address, and user agent, and hashed with HMAC-SHA256 together with the hash of the previous event. Each document keeps an anchor over the event count and the latest hash.

The chain logic has a dedicated test suite that runs in CI against a disposable database on every change, guarded so it can never run against a production database.

Application security

The applications are hardened against the OWASP Top 10 classes of attack with layered browser and server controls.

Browser features the platform does not use, such as the camera and geolocation, are disabled through Permissions-Policy. Secrets never reach the client bundle. Server-only modules are marked so the build fails if one is imported into browser code.

Change management and secure development

Code reaches production only through version control and automated checks, and nobody edits a running server by hand.

1. Work happens on feature branches and merges into the main branch through pull requests with a standard template.
2. Pre-commit hooks lint staged files and enforce structured commit messages.
3. Continuous integration runs on every pull request and every push to main and runs type checking, linting, and unit and integration tests. The on-chain programs additionally run Clippy with warnings treated as errors and cargo deny against known-vulnerable and disallowed dependencies.
4. Toolchain versions are pinned (Rust, Solana, Anchor, Node, and the CI runner image), and the build fails if an installed version drifts.
5. Deployments are built from the main branch by the hosting platform, producing immutable versions that can be rolled back instantly.

CI is built on least privilege. Workflow tokens are read-only, every secret is scoped to the single step that needs it, and repository credentials are not persisted for later steps. Secrets are excluded from source control in every repository, including signing certificates and private keys.

Components built on open source projects publish their modified source as their licenses require, so the code that handles documents is open to independent inspection.

Infrastructure and subprocessors

The platform runs no self-managed servers. Compute, storage, databases, and identity are delegated to providers that are independently audited, so physical security, hardware disposal, host patching, and network isolation are covered by their attestations (the standard carve-out model in a SOC 2 report).

Applications run as serverless functions and isolated containers built from version-controlled images.

Full provider SOC 2 reports are distributed under NDA and can be requested directly through each trust center.

Backups and disaster recovery

Production databases are dumped daily, encrypted before they leave the hosting environment, and stored in AWS S3, separate from the primary infrastructure.

Applications are stateless and redeploy from version control in minutes, so recovery time is driven by the database restore. A provider outage is handled by restoring the latest dump into a fresh managed database and pointing the application at it.

Logging, monitoring and incident response

Application and platform logs are centralized and kept for one year. Alerts on errors and security-relevant events reach the engineering team directly.

Incidents follow a written response plan with severity levels, a named incident lead, containment, root-cause analysis, and a written post-incident review. Customers affected by a confirmed security incident involving their data are notified within 72 hours.

Data retention and deletion

Data is kept only as long as the service or the law requires.

Vulnerability disclosure

Security issues can be reported privately to security@refi2.com. Every application publishes an RFC 9116 security.txt at /.well-known/security.txt with the same contact.

SOC 2 criteria mapping

The technical controls above map to the following 2017 Trust Services Criteria (revised points of focus, 2022).