Contact Us  Try the demo
/ Programmable trust infrastructure /

Make your money aware of the contract.

Don't gamble on trust. Program it.

A non-custodial, programmable escrow. Funds locked under your own control, released on multi-party validation. Disputes resolved by integrated arbitration, enforceable in 170+ countries.

Contact us: deal@paycifi.com
Escrow lifecycle
Buyer
$
$
$
$
$
$
Circle Alliance
Fiat ramp in EUR/USD via SEPA & ACH EURC, USDC, and any ERC-20 on demand Available in 110+ countries
/ The gap /

High-value private transactions still settle on blind trust.

Every high-value private transaction faces the same structural question: who holds the money between signing and completion, and what happens if the parties disagree?

lost yearly to wire fraud on traditional escrow accounts
FBI IC3, 2024
of cross-border M&A deals blocked by entity and SPV setup failures.
CSC · 200 DEALMAKERS · 2026
2-4 years
average cross-border dispute duration with no pre-agreed arbitration
US Courts, ICC, 2024
of M&A professionals report lengthening signing-to-close timelines
CSC, 200 dealmakers, 2026
/ What Paycifi does /

Four building blocks. One settlement layer.

001 / 002 / 003 / 004
001

Programmable Escrow

Multi-party, cross-border, instant settlement. Funds locked in a smart escrow at signing, released milestone by milestone on multi-party validation. Up to 10 beneficiaries per agreement. No unilateral control: not the buyer, not the seller, not Paycifi.

002

Conditional Release & Controls

Settlement only happens when everyone agrees. Before that, funds can always come back. Add compliance partners as validators. Set deadlines with automatic refund on expiry. Every condition is programmable, every release is auditable.

003

Multi-Recipient Payouts

One escrow, many beneficiaries. Seller, advisors, lenders, brokers: each paid their share automatically at completion. Replaces five manual wires with one programmed settlement.

004

Treasury & Cross-Border Payments

Send and receive stablecoins across borders, backed by a regulated fiat ramp. Built-in KYB/KYC so treasury and payment flows stay compliant by design.

/ The mechanism /

From signing to settlement in five steps.

01 Structure

Parties define the agreement: amounts, milestones, beneficiaries, deadlines, designated arbitrator.

02 Fund

Funder locks the amount in the smart escrow. EUR or USD via regulated fiat ramp, or directly in stablecoins.

03 Deliver

The transaction proceeds. Closing conditions, asset delivery, transfer of title, completion accounts.

04 Validate

Each party confirms its milestones. Multi-party validation releases funds automatically and instantly.

05 Resolve (if needed)

Disagreement? Any party calls the designated arbitrator. ICC standards, Geneva seat, enforceable in 170+ countries. The arbitrator allocates the escrowed funds directly.

New Tab
paycifi.com/dashboard
Paycifi dashboard
PIN authentication
Safeguards

Early withdrawal available during acceptance phase. Automatic refund if validation deadline passes without resolution.

Onboarding

No wallets, no seed phrases, no crypto expertise. Parties onboard with email and PIN. Web3-native parties can connect their own wallet.

/ See it work /

Try a live escrow agreement.

Agreement
Fine Art Acquisition
You (Buyer) · Gallery Laurent (Seller) · Arbitrator: ICC-certified
in escrow of $50,000
M1
Deposit
50% of the purchase price, $25,000
M2
Delivery & Inspection
Balance on confirmed condition, $25,000
Arbitration
Dispute filed: condition of artwork does not match description.
Award enforceable in 170+ countries under the New York Convention
Ledger
Gallery Laurent
Returned to you
Settlement time

Simplified simulation. The production flow adds KYB verification, funding rails and the full arbitration workflow.

/ Built for /

The settlement layer for private markets.

/ What makes us different /

The only escrow with a built-in way out of a dispute.

Every incumbent stops at holding funds. When parties disagree, money freezes and the dispute moves to court, for years. Paycifi couples custody logic with resolution logic.

Designated at inception

Arbitrator agreed by all parties at agreement creation, not after the dispute starts.

ICC standards, global enforcement

Geneva seat. Awards enforceable in 170+ countries under the New York Convention (1958).

Resolution = Execution

The arbitrator allocates the escrowed funds directly. An enforceable and executed outcome in one motion. No court, no freeze, no years.

/ Trust infrastructure /

Institutional guarantees. Programmable execution.

No Counterparty Risk

Funds in a dedicated smart contract, not on Paycifi's balance sheet. Paycifi never holds or controls client funds during the life of the agreement.

Regulated settlement

USDC and EURC, fully reserved digital dollars and euros by Circle (MiCA-approved EMT Issuer). Any ERC-20 stablecoin enabled on request for specific corridors.

Circle Alliance

Paycifi is an official Circle Alliance partner, building on the leading regulated stablecoin infrastructure.

KYB / KYC / AML

Compliance verification on all parties before funds move. B2B only. Fiat ramp via regulated PSP partner.

Built on Base

Ethereum Layer 2 by Coinbase. Enterprise-grade infrastructure. ERC-4337 smart accounts.

Legal framework

The agreement between the parties always prevails. Where it is silent, our terms and conditions apply as a fallback, backed by ICC arbitration.

/ Pricing /

Transparent. Proportional. All-in.

One fee on the escrowed amount. No setup fees, no monthly custody, no per-wire charges.

Standard · Self-serve
Direct access

Escrow from the first euro. Accessible directly, no commitment.

Stablecoin escrow
USDC & EURC, non-custodial
0.5%
With fiat on / off ramp
EUR & USD via regulated PSP
≤ 1.5%
  • Programmable escrow, multi-party logic & arbitration framework
  • Up to 10 beneficiaries per agreement
  • KYB / KYC compliance included
  • No setup fees, no monthly custody, no per-wire charges
› Try the demo
Enterprise · Large volumes
Tailored settlement

For high-volume desks and recurring corporate flows.

On request
Degressive pricing, no volume ceiling.
  • Volume-based degressive rates
  • Dedicated corridors & custom ERC-20 stablecoins
  • Priority onboarding & support
  • Compliance-as-a-validator options
› Contact us
/ What's next /

The programmable settlement layer keeps growing.

V2
Waterfall Escrow

Priority-based distribution to multiple stakeholders. For PE exits, structured finance, trade receivables.

V2
Yield on Locked Funds

Earn on escrowed capital via regulated DeFi integrations while funds wait.

V2
Oracle-Triggered Payments

External data feeds (Chainlink) trigger conditional releases. Delivery confirmed? Payment moves.

V2
Compliance-as-a-Validator

Add any compliance partner as a required validator on any agreement.

Structure your next transaction on Paycifi.

Walk through a live agreement in 20 minutes, on your deal structure.

/ M&A settlement infrastructure /

Secure the space between signing and closing.

Programmable escrow for holdbacks, earnouts, and multi-party closings. Available from the first euro. No bank minimum, no setup delay.

Below €250M, M&A escrow is still improvised.

Above the threshold, Representations & Warranties insurance dominates (85-95% penetration). Below it, where most transactions happen, the options are a bank escrow (minimum too high), a lawyer trust account (single-party risk, no dispute mechanism), or nothing. SRS Acquiom reports that 91% of the deals it handles include an escrow holdback at a median of 10% of deal value. The infrastructure exists at the top. The mid-market deserves the same protection.

Every M&A mechanism, programmable.

01
Indemnification holdbacks & warranty escrows

Funds locked at signing, released at the end of the survival period or upon claim resolution. Available from the first euro, no institutional minimum.

02
Pre-funded earnout tranches

Milestone-based release tied to agreed performance metrics. Each tranche validates independently.

03
Completion accounts & price adjustments

Post-closing adjustment mechanisms with escrowed amounts released on agreed final accounts.

04
Multi-party closings

Up to 10 beneficiaries paid from a single escrow: seller, advisors, lenders, broker. One programmed settlement replaces five manual wires.

05
Deal deposits

Secure exclusivity deposits before full due diligence. Funds returned automatically if conditions are not met by deadline.

How it compares.

VectorTraditional banksLegacy digital escrowCrypto-native escrowPaycifi
Custody riskWire freezes — High exposure to arbitrary compliance holds.Counterparty risk — Funds tied to a single intermediary and manual approvals.Key loss — Permanent loss via private-key mismanagement.Non-custodial MPC — Funds never under our control; seamless wallet recovery.
Setup velocityWeeks — Bureaucratic friction, manual compliance & paperwork.Slow wires — Bottlenecked by legacy international rails.Complexity — Cognitive barrier, zero business logic, raw UX.Minutes — Fast deployment via seamless Web2 onboarding.
Workflow flexibilityRigid & manual — Struggles with multi-party distributions across jurisdictions.Bilateral only — Built for simple buyer-to-seller retail flows, not corporate deals.Highly flexible — Requires custom smart contracts and Web3 expertise.Dynamic & ready — Enterprise multi-party flows out-of-the-box, no Web3 knowledge required.
Dispute resolutionYears — Slow, cost-prohibitive multi-jurisdictional courts.Opaque — Centralized, slow, subjective internal mediation.Unpredictable — Community voting rejected by corporate legal teams.ICC Standard — Built-in arbitration & lawyer network across 170 countries.
See how it works on your deal structure.

When the deal goes wrong, the money doesn't freeze for years.

Warranty claim disputed? The arbitrator designated at signing resolves the claim and allocates the escrowed funds directly. An enforceable outcome, not a court date.

Designated at inception

Agreed by all parties when the escrow is created, not after the dispute starts.

Resolution = Execution

ICC standards, Geneva seat, enforceable in 170+ countries. The award executes on the escrow itself.

Walk through your next holdback in 20 minutes.

Settlement for private assets

Kill the fake escrow problem.

Art, collectible cars, superyachts: the private sales channel has no standard settlement infrastructure. Payment-versus-delivery synchronization, with integrated arbitration, for every asset class.

No one holds the money. Everyone takes the risk.

In a private asset sale, one of two things happens: the buyer wires first and hopes the asset arrives, or the seller ships first and hopes the payment follows. Counterfeit escrow schemes are a documented and growing fraud vector. Nearly 700 fraud reports were logged between 2021 and 2023 by the Better Business Bureau in the hypercar segment alone, including explicit fake-escrow schemes. The art world found it necessary to create a dedicated arbitration court (CAfA, 2018) because ordinary courts were ill-equipped for provenance and condition disputes. No player has ever coupled that resolution capability with the funds themselves.

/ Who it's for /

Two audiences, one settlement layer.

For OTC brokers
Payment-versus-delivery, programmed
  • Payment locked before the asset moves, released on confirmed delivery and condition
  • Brokerage commissions programmed into the same escrow, paid automatically at completion
  • Condition and authenticity disputes routed to the designated arbitrator
  • Buyer and seller in different jurisdictions settle instantly, without correspondent banking
For family offices & wealth managers
Discreet settlement, any asset class
  • Payment-versus-delivery synchronization on any private acquisition or disposal
  • Direct investments into private companies with milestone-based release
  • Discretion by design: no public listing, amounts visible only to participants
  • One settlement framework across asset classes and jurisdictions

Asset classes.

Fine Art

Provenance disputes, condition at delivery, chain of title. The arbitrator resolves, the smart escrow executes.

Collectible Cars & Hypercars

Payment on confirmed delivery and inspection. Broker commissions included. Fake-escrow risk eliminated.

Superyachts

Brokerage commission disputes, vessel condition at handover, multi-jurisdiction closings.

Digital Assets (OTC)

T+0 counterparty-protected settlement on block trades. Any ERC-20 stablecoin enabled on request for specific corridors.

Secure your next private acquisition in 20 minutes.

/ Legal /

Regulatory Position Overview

This overview summarises Paycifi's regulatory self-assessment across the frameworks most relevant to its activity. It does not constitute a legal opinion. A more detailed internal memorandum, and formal legal confirmation of the points noted below, are available on request as part of due diligence.

Overview

As part of building its infrastructure, Paycifi has proactively assessed its regulatory position under the European and MENA frameworks most relevant to programmable escrow and stablecoin-based payment infrastructure: MiCA, the UAE's VARA and ADGM regimes, and PSD2. This assessment is grounded in the platform's technical architecture, which is designed so that Paycifi's operating entity, BE Blockchain SRL, never holds or controls user funds at any point.

Summary

Framework Status Basis
MiCA (EU)Outside CASP scopeFormalised in BE Blockchain SRL's Terms of Service, based on the platform's non-custodial architecture.
VARA (Dubai)Outside custody-licence scopeSame control-based test as MiCA; consistent with the platform's architecture.
ADGM (Abu Dhabi)Likely outside scopeRecent framework (January 2026) on fiat-referenced tokens; application to non-custodial models under review.
PSD2 (EU)Not yet confirmedTeam's working position is non-applicability, based on absence of control over funds. This has not been confirmed by external counsel.

Across custody-based regimes (MiCA, VARA, ADGM), the platform's non-custodial architecture supports a position of being outside licensing scope. PSD2 applies a different test, based on the substance of the commercial relationship rather than custody alone; formal confirmation of this point is in progress with specialised counsel.

Architectural basis

Private keys are fragmented via Circle's MPC (Multi-Party Computation) infrastructure and held exclusively by the user's device, Circle's servers, and a backup mechanism. BE Blockchain SRL holds no key fragment at any point. Funds are released either by the parties' own cryptographic signatures, or, in the event of a dispute, by an independent arbitrator holding a separate signature key. BE Blockchain SRL's own wallet is used solely for the automated, hard-coded collection of service fees, and confers no power to modify, suspend, or redirect transactions.

This architecture is formalised in Paycifi's Terms of Service, which state that BE Blockchain SRL "does not qualify as a Crypto-Asset Service Provider (CASP) within the meaning of Article 3(1)(13) of MiCA and does not hold a CASP authorisation."

PSD2: current status

PSD2 is the one framework where the applicable test is not purely custody-based, and where formal confirmation of Paycifi's position remains outstanding. The team's working assessment is that PSD2 does not apply, given the platform never possesses or controls user funds. This assessment will be formalised through a dedicated legal opinion with specialised counsel, and this note will be updated once that opinion is obtained.

Continued investment in regulatory robustness

The current architecture already routes disputed funds to an independent, professionally liable arbitrator rather than to Paycifi. BE Blockchain SRL is developing a next-generation, fully non-custodial arbitration mechanism that will remove this step entirely, holding disputed funds in a dedicated escrow smart contract with pre-programmed allocation rules. This reflects an ongoing design commitment to minimising custody exposure across every part of the platform, not only the base transaction flow.

Further detail, including jurisdiction-specific analysis and the full internal legal memorandum, is available on request.

End of Regulatory Position Overview.

/ Privacy /

Privacy Policy

Last updated: February 2, 2026

1. Introduction

BE Blockchain SRL (“Paycifi”, “we”, “us”, or “our”) operates the Paycifi platform, a software-as-a-service (SaaS) infrastructure designed for professional users to execute conditional payments and programmable escrow mechanisms based on blockchain technology. We are committed to protecting the privacy and personal data of our professional users and their representatives, in compliance with the General Data Protection Regulation (EU) 2016/679 (“GDPR”). Note: Paycifi is a B2B platform and is not intended for consumers.

2. Data controller

BE Blockchain SRL, registration number 0736.494.076, 49 rue du Centre, 5003 Saint-Marc, Belgium.
Email: privacy@paycifi.com · Website: beblockchain.be

3. Personal data collected and purposes

3.1 Categories of data collected: identification data (first name, last name, professional email); company data (name, registration/VAT number, registered office address, business sector); technical and usage data (authentication tokens, IP addresses, technical logs and security events).

3.2 Purposes: account creation and authentication; execution and operation of Paycifi services; platform security, fraud prevention and abuse detection; compliance with legal and regulatory obligations (including AML/KYB); service communications and technical notifications.

4. Legal basis for processing

Under GDPR Article 6: performance of a contract (account creation and service execution); compliance with legal obligations (AML, KYB, accounting); legitimate interests (platform security, fraud prevention, service integrity and improvement); consent (optional communications such as newsletters, withdrawable at any time).

5. Zero-storage policy and third-party providers

Paycifi implements a Zero-Storage policy for sensitive financial and identity documentation. Certain services are provided by independent third parties: KYB & identity verification (Aiprise.com), fiat on/off-ramp (Getjoin.io), integrated digital wallet infrastructure (Circle). Paycifi does not store sensitive identity documents (passports, ID cards, incorporation certificates) on its own servers — only a technical unique identifier (UID) enabling secure interaction with these providers' APIs. Users should consult these providers' own privacy policies.

6. Blockchain-specific considerations

6.1 Privacy by design: no personal or sensitive data (names, emails, identity documents) is stored on-chain. 6.2 Pseudonymity: transactions are pseudonymised through public wallet addresses; blockchain data is publicly accessible and traceable by design. 6.3 Paycifi is exploring privacy-enhancing technologies (privacy-preserving stablecoins, zero-knowledge proofs), not guaranteed and subject to technical, regulatory and third-party constraints. 6.4 Immutability: blockchain transactions are permanent and irreversible; the right to erasure cannot apply to on-chain data, which users expressly acknowledge upon initiating a transaction.

7. Hosting and international data transfers

The application layer (website and interface) is hosted by OVHcloud on servers located within the European Union. Where third-party providers process data outside the EU, Paycifi ensures appropriate safeguards (European Commission adequacy decisions or Standard Contractual Clauses).

8. Cookies and analytics

Paycifi uses secure authentication tokens strictly necessary for session management, and may use analytics tools (including Google Analytics) for aggregated, anonymised usage statistics, deployed in accordance with applicable cookie consent requirements. Users may configure or withdraw consent via the platform's cookie settings.

9. Communications

Account creation implies agreement to receive essential service communications (security alerts, system updates, service disruptions). Newsletters or non-essential communications are opt-in and may be withdrawn at any time via the unsubscribe link.

10. Data retention

In accordance with Belgian legal, accounting and tax obligations, Paycifi retains basic account and contractual data for ten (10) years following the end of the business relationship. Technical logs are retained only as long as necessary for security and compliance.

11. Your rights

Under GDPR, users may access, rectify, or request erasure of their personal data; restrict or object to certain processing; request data portability; and withdraw consent at any time. Some rights may be limited by legal, contractual or technical constraints, particularly for blockchain-related data. Requests: privacy@paycifi.com (response within 30 days). Users may also lodge a complaint with the Belgian Data Protection Authority (APD-GBA).

12. Updates to this policy

This Privacy Policy may be updated to reflect legal, technical or operational changes. The latest version is always available on the Paycifi website.

End of Privacy Policy.

/ Terms and conditions /

Terms and Conditions of Use and Service

Last updated: July 2026

Preliminary warning and consent

PLEASE READ THESE GENERAL TERMS AND CONDITIONS CAREFULLY PRIOR TO ANY USE.

By accessing the Paycifi platform and utilizing our conditional payment infrastructure services, you hereby acknowledge that you have read and accepted, without reservation, the entirety of these General Terms and Conditions, as well as all terms incorporated herein by reference (including, without limitation, the policies of our third-party service providers).

Your attention is specifically directed to the following:

  • Exclusive B2B Use: Access is strictly restricted to professional entities. By continuing, you certify that you are not acting in the capacity of a consumer.
  • Technical Liability: Paycifi acts as a Software-as-a-Service (SaaS) provider and exercises no control or custody over the funds of Users or the underlying blockchain networks utilized.
  • Technological Risks: The utilization of decentralized protocols and Smart Contracts involves inherent risks that you represent and warrant you understand and accept.
  • Regulatory Framework: The Paycifi platform operates under the legal framework described in Article 5 of these Terms. The use of USDC and EURC stablecoins is subject to MiCA compliance provisions as set out herein.
IT IS YOUR SOLE RESPONSIBILITY TO REVIEW THESE TERMS PRIOR TO EACH USE. If you do not expressly agree to all of these terms, you are not authorized to access our websites or utilize our services. Under such circumstances, you must immediately cease all navigation on the platform.

1. Preamble

Paycifi is a software platform for conditional payments and programmable escrow, based on Smart Contracts deployed on public blockchains. It is designed to enable professional parties to secure the financial execution of their contractual relationships, without substituting for the underlying contracts or existing legal mechanisms.

Paycifi acts exclusively as a provider of technical infrastructure and a software execution layer. The platform does not provide any legal, financial, banking, asset custody, or advisory services, and does not intervene in the contractual relationship between the utilizing parties.

The use of Paycifi implies full and unreserved acceptance of these Terms, which exclusively govern the relationship between the user and the platform editor, without prejudice to any contracts that may be entered into between the users themselves.

Paycifi's functionalities are based on:

  • Smart Contracts deployed on public blockchains;
  • Integrations with independent third-party providers (specifically for digital wallets, KYB compliance procedures, and crypto/fiat conversion services);
  • USDC and EURC stablecoins issued by Circle Internet Financial, Ltd., which are compliant with Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCA).

These third-party providers deliver their services under their own liability and according to their own contractual terms. BE Blockchain SRL acts neither as a financial intermediary, nor as a custodian of funds, nor as a provider of regulated services within the meaning of banking or financial law.

For any questions relating to the platform or these Terms, BE Blockchain SRL can be contacted at: contact@paycifi.com or via our official websites: https://beblockchain.be and https://paycifi.com.

2. Who we are

Paycifi is a platform published and operated by BE Blockchain SRL (hereinafter "BE Blockchain" or "the Publisher"), a Belgian law private limited company specialising in the design, development, and operation of software solutions based on blockchain and Web3 technologies.

BE Blockchain SRL is a private limited company (SRL/BV) under Belgian law, with a share capital of 15,000 euros, whose registered office is located at 49, rue du Centre, 5003 Saint-Marc, Belgium, registered with the Crossroads Bank for Enterprises under number 0736.494.076, and subject to VAT under number BE0736.494.076.

BE Blockchain SRL designs and operates technical infrastructures intended for professional use, particularly in the fields of programmable payments, Smart Contracts, tokenisation, and blockchain interoperability. Paycifi is one of the platforms developed and operated by BE Blockchain SRL.

3. Definitions

  1. User: Any natural person (acting on behalf of a professional) or legal entity accessing the platform.
  2. Partner: Any person who is a party to a Contract, agreeing to be bound by their cryptographic signature.
  3. Initiator: The Partner who creates and sets the conditions of a contract (expiration dates, amounts, addition of Partners, fund allocation, choice of arbitrator).
  4. Payer: The Partner responsible for depositing funds into the Smart Contract.
  5. Beneficiary(ies): The Partner(s) designated to receive the funds after validation of the service or arbitral decision.
  6. Arbitrator: An independent third party, chosen by the Partners. A distinction is made between:
    • Referenced Arbitrator: A dispute resolution professional listed by Paycifi. Although selected for their expertise and subject to a due diligence process conducted by Paycifi, these arbitrators act with complete independence. Paycifi does not guarantee the outcome of their arbitrations.
    • External Arbitrator: Any third party (e.g., lawyer, industry expert) directly invited by the Partners via their email address or Wallet. Paycifi exercises no control, competence verification, or curation over these profiles. The Partners alone assume the risks associated with the choice of an External Arbitrator.

4. Functional glossary

  1. Contract: The conditional payment agreement generated via Paycifi, governed by a Smart Contract deployed on a public blockchain.
  2. Smart Contract: A self-executing computer program, deployed on a blockchain, whose terms and conditions are inscribed directly in the code. It automatically executes transactions (such as blocking or releasing funds) once the predefined conditions, validated by the Partners' cryptographic signatures, are met, without intervention from Paycifi.
  3. Cryptographic Signature: Unalterable proof of consent generated by a User's Wallet to accept a contract or validate a service.
  4. Wallet (Digital Wallet): Interface allowing interaction with the blockchain.
    • External Wallet: A Wallet over which the User retains sole custody (e.g., MetaMask).
    • Circle Wallet: A solution integrated by Paycifi for a simplified experience, based on Circle's MPC (Multi-Party Computation) infrastructure.
  5. Deposit: The action of transferring the Payer's funds to the Escrow Smart Contract on a blockchain.
  6. Blockchain: A decentralised and secure distributed ledger technology, acting as the basic infrastructure on which Paycifi's Smart Contracts are deployed and transactions are irreversibly recorded.
  7. Stablecoin: A digital asset issued on a blockchain (USDC or EURC) whose value is pegged to a fiat currency (the Dollar or the Euro respectively), issued by Circle Internet Financial, Ltd., and compliant with Regulation (EU) 2023/1114 (MiCA).
  8. Source Available Software: Software whose source code is made publicly available for inspection and audit purposes, but whose use, reproduction, modification, or distribution remains subject to the restrictions set out in Article 5 of these Terms.

5. Regulatory framework and MiCA compliance

5.1 MiCA Status and Applicable Framework

The Paycifi platform exclusively uses USDC (USD Coin) and EURC (Euro Coin) as settlement currencies. Both assets are issued by Circle Internet Financial, Ltd., an entity that has obtained the necessary authorisations to issue Electronic Money Tokens (EMTs) within the meaning of Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on Markets in Crypto-Assets ("MiCA"), which entered into full application on 30 December 2024.

5.2 Position of BE Blockchain SRL

BE Blockchain SRL operates Paycifi as a technology infrastructure provider and software execution layer. BE Blockchain SRL does not, in the context of the services described in these Terms:

  • hold, transfer, or exchange crypto-assets on behalf of Users;
  • provide investment advice or portfolio management services in crypto-assets;
  • operate a trading platform or exchange for crypto-assets;
  • issue or offer crypto-assets to the public.

Accordingly, BE Blockchain SRL does not qualify as a Crypto-Asset Service Provider (CASP) within the meaning of Article 3(1)(13) of MiCA and does not hold a CASP authorisation. The Publisher reserves the right to update this assessment at any time in the event of a change in applicable law, regulatory guidance, or the scope of services offered by the platform.

5.3 Responsibility of the User

The User acknowledges and accepts that:

  • The stability, liquidity, and MiCA-compliance of USDC and EURC are the exclusive responsibility of Circle Internet Financial, Ltd.;
  • Any loss of parity (de-peg), regulatory suspension, or regulatory action against the stablecoin issuer falls outside the scope of Paycifi's responsibility;
  • Users operating as CASPs, payment institutions, or regulated entities under applicable law are solely responsible for ensuring that their use of the Paycifi platform complies with their own regulatory obligations.
Part A — Legal framework and technical infrastructure

6. Service publisher and contact

The Paycifi platform is published and operated by BE Blockchain SRL, a Belgian law private limited company, registered with the BCE under number 0736.494.076, whose registered office is located at 49, rue du Centre, 5003 Saint-Marc, Belgium (hereinafter "Paycifi" or "the Publisher"). Contact: contact@paycifi.com.

7. Object and legal qualification

These Terms govern access to Paycifi as a software solution (SaaS). Paycifi acts exclusively as a provider of technical services offering an intermediation infrastructure for the execution of conditional payments.

The User expressly acknowledges and accepts the following principles, inherent in the technical architecture and functioning of the Paycifi platform:

  1. Absence of Control over User Funds: The Publisher exercises no discretionary technical control over the funds held in Paycifi's Escrow Smart Contracts. BE Blockchain SRL operates a separate wallet address designated solely for the automated collection of service fees as programmed in the Smart Contract. This fee-collection wallet does not confer upon BE Blockchain SRL any power to modify, suspend, cancel, or redirect transactions between Partners, nor any access to escrowed funds. Paycifi has no power to modify, suspend, or cancel fund-release transactions once they are recorded on the blockchain.
  2. Neutrality: The Publisher is never a party to the Contracts concluded between the Partners.
  3. Non-Custody of Assets: The Publisher does not hold, control, or manage the funds of Users at any time. The funds are exclusively under the control of the Smart Contracts and the Partners' cryptographic signatures.
  4. Network Independence: The Publisher exercises no control over the blockchain networks or any decentralised infrastructure used.
  5. Absence of Advice: The Publisher does not provide any legal, financial, or investment advisory services.

8. Use of third-party providers and subcontracting

To ensure the operation of the Platform and the compliance of the services, Paycifi relies on various specialised providers (notably for identity verification, risk analysis, wallet infrastructure, or hosting).

  1. Authorisation: The User expressly authorises Paycifi to use any subcontractor or partner of its choice for the execution of the Services.
  2. Independence: With the exception of simple technical integration, these providers act independently. Paycifi's liability shall not be engaged for acts, omissions, or service interruptions attributable to these third parties.
  3. Personal Data: The list of subcontractors processing personal data and the modalities of this processing are detailed and updated in the Privacy Policy available at https://paycifi.com/privacy, which the User is invited to consult.

9. Eligibility and strict exclusion of B2C

The platform is strictly reserved for professional use (B2B).

  1. Access is prohibited to any person acting for purposes outside the scope of their trade, business, craft, or profession. By accessing the platform, the User represents and warrants that they are acting exclusively in a professional capacity.
  2. The User guarantees their professional status and undertakes to indemnify Paycifi for any damage resulting from a false declaration in this regard.
  3. In the event of use by a non-professional, Paycifi disclaims all liability related to any consumer protection provisions that may be claimed under any applicable law.

10. Wallet access and security

The User freely chooses their mode of interaction with the platform, which determines their liability regime.

10.1 External Wallets (Non-Custodial)

The User may choose to connect their own third-party Wallet (e.g., MetaMask, Ledger). In this case:

  1. Responsibility: The User is solely responsible for the custody of their private keys and the security of their Wallet.
  2. Absence of Access: Paycifi has no access, no control, and no possibility of recovering funds in case of loss of key, theft, or hacking of the external Wallet.

10.2 Integrated Wallets (Circle MPC Infrastructure)

By opting for a standard registration method via email and password, the User benefits from the integrated Wallet solution provided by Circle (Programmable Wallets). This choice entails the User's express adhesion to Circle's terms of use, including full understanding and acceptance of the following:

  1. MPC Technology: This solution is exclusively provided and operated by the third-party provider Circle. The private key is fragmented into several computer shares distributed between the User's device, Circle's servers, and a backup method. Paycifi never has access to the key or the funds.
  2. Responsibility: Paycifi's responsibility is exclusively limited to the proper technical integration of the Circle API and the provision of the user interface. The User is responsible for the security of their identifiers and their device.
  3. Recovery Procedure: The User is solely responsible for the choice and memorisation of the security backup questions configured during the creation of their integrated Wallet. It is technically impossible to restore account access without the exact provision of the answers to these security questions. Paycifi, having no access to these answers, cannot under any circumstances intervene to unblock an account in case of loss.
  4. Third-Party Failure: Paycifi cannot be held responsible for a bug, service interruption, loss of access, inability to reconstitute a key, or asset freeze resulting from Circle's technical infrastructure. The User accepts Circle's general terms and conditions independently.

11. Compliance, AML, and suspension of services

11.1 Sanctions Warranty

The User declares and warrants that they are not targeted, directly or indirectly, by international sanctions (notably OFAC, European Union, UN) and that they are not using the platform on behalf of persons subject to such measures.

11.2 Anti-Money Laundering and Counter-Terrorist Financing

BE Blockchain SRL implements risk-based compliance measures proportionate to its role as a technology infrastructure provider. The platform applies Know-Your-Business (KYB) verification procedures for all Users prior to accessing its services, through its third-party compliance provider. Notwithstanding the foregoing, BE Blockchain SRL reserves the right, at its sole discretion, to:

  • suspend or terminate a User's access to the platform's front-end interface in the event of suspected fraudulent, illicit, or sanctions-violating activity;
  • cooperate with competent authorities, including financial intelligence units and supervisory authorities, upon receipt of a lawful request;
  • decline to process or facilitate transactions involving addresses flagged by blockchain analytics providers.

The User acknowledges that, by virtue of Paycifi's non-custodial architecture, BE Blockchain SRL does not have the technical ability to reverse, cancel, or intercept transactions that have been validated on the blockchain. Suspension of access to the platform interface does not affect the autonomous execution of Smart Contracts already deployed on the blockchain.

11.3 Use of Stablecoins and Right to Freeze

The payment infrastructure uses USDC and EURC stablecoins issued by Circle Internet Financial, Ltd. The User is expressly informed that the token issuer has technical functions enabling it to freeze assets in a Wallet in case of suspicion of illicit activity or violation of its own compliance rules. Paycifi cannot be held responsible for the impossibility of executing a Contract, a loss of access, or the inability to recover funds resulting from such a freeze measure applied by Circle.

11.4 Suspension of the Service Layer

Paycifi reserves the right to suspend or restrict access to its interface (web, API, fiat ramp) in case of:

  • Regulatory Non-Compliance: Failure or expiration of KYB verifications;
  • Suspicion of Fraud: Suspicious activities or transactions linked to risky addresses;
  • Legal Obligation: Request from an administrative or judicial authority;
  • Third-Party Provider Decision: Suspension imposed by Circle or our financial service providers.

The User acknowledges that the suspension of the Paycifi interface does not affect the existence or autonomous execution of the Smart Contract on the blockchain.

12. Exclusion of liability related to networks and decentralised protocols

Paycifi does not guarantee the continuous operation of blockchain networks and disclaims all liability in case of:

  1. Network congestion, increase in transaction fees (gas fees), or confirmation delays;
  2. Malfunction, bug, "fork," or definitive shutdown of the blockchain protocol used;
  3. Security vulnerabilities or loss of parity (de-peg) related to the functioning of Stablecoins. The User acknowledges that the stability, liquidity, and convertibility of these assets depend exclusively on the third-party issuer (Circle) and not on Paycifi.

13. Force majeure and systemic events

Neither Party shall be held responsible for a total or partial failure to fulfil any of its obligations under these Terms when such failure results from a force majeure event within the meaning of Belgian law, as interpreted by the case law of the Belgian courts.

The following are notably considered force majeure events, without this list being exhaustive:

  1. A massive breakdown, prolonged unavailability, or serious malfunction of one or more public blockchain networks used by the platform;
  2. A hard fork, soft fork, critical bug, cyber-attack (notably 51% attack, Smart Contract exploit, cryptographic vulnerability), or any technical evolution of the protocol rendering the execution of Smart Contracts impossible, altered, or unpredictable;
  3. A significant interruption, suspension, or failure of services provided by essential third-party providers (notably wallet providers, Stablecoin issuers, compliance services, fiat/crypto conversion services);
  4. A sudden legislative or regulatory change, an administrative prohibition, a judicial decision, or an injunction from a competent authority directly or indirectly affecting the use of digital assets, Stablecoins, or the services offered by Paycifi;
  5. The adoption or extension of international sanctions, embargoes, or restrictive measures (notably OFAC, European Union, United Nations) impacting Users, third-party providers, blockchain networks, or the financial flows concerned.

In the event of such an occurrence, Paycifi may suspend all or part of the access to the platform or its functionalities, without affecting the existence or the autonomous execution of the Smart Contracts deployed on the blockchain, which remain subject to the technical rules of the network concerned.

No compensation may be claimed from Paycifi on account of a force majeure event, the User expressly acknowledging the systemic, regulatory, and technological risks inherent in the use of blockchain technologies and digital assets.

Part B — Economic model and service fees

14. Paycifi service fees (protocol commission)

In consideration for the development of the Smart Contracts, the provision of the application interface (front-end), and the continuous evolution of access services, Paycifi collects service fees.

  1. Rate: The applicable commission rate is programmed immutably (hard-coded) within the Smart Contract at the time of its deployment on the blockchain. The applicable rate for each version of the Smart Contract is displayed in the platform interface prior to the User's cryptographic signature. Standard rates are published on https://paycifi.com. For enterprise agreements and bespoke Smart Contract deployments, rates may be negotiated separately pursuant to Article 18 of these Terms.
  2. Version Scalability: The User acknowledges that this rate corresponds to the specific version of the Smart Contract used for their Contract. Paycifi reserves the right to deploy new versions of the protocol with different fee structures. The applicable rate will be explicitly mentioned in the interface for each new version of the Smart Contract offered.
  3. Deduction: The commission is deducted automatically and irreversibly by the Smart Contract upon the final release of the funds (or upon the call for arbitration).
  4. Specific Agreements and Cashback: Specific commercial agreements may provide for mechanisms for partial fee reimbursement (cashback) or derogating tariffs for large volumes. These agreements are subject to a separate contract and do not modify the automatic deduction carried out by the Smart Contract.
  5. Acceptance: By cryptographically signing a Contract, the User accepts the execution of this computer code and the associated automatic deduction.

15. Identity verification fees and re-invoicing

Access to certain functionalities of the platform requires professional identity verification (KYB).

  1. These verification fees are billed by Paycifi to the User during the registration procedure.
  2. The amount collected corresponds to the fees billed to Paycifi by the third-party verification providers, at cost and without markup. These fees are due regardless of the verification result (acceptance or refusal of the profile).
  3. Paycifi reserves the right to adjust the amount of verification fees based on changes in the tariffs applied by third-party providers, with prior notice to the User where reasonably practicable.

16. Network fees (gas fees) and sponsoring

The User acknowledges that interaction with the blockchain generates network fees:

  1. Integrated Experience (Circle Wallets): To date, for Users utilising the integrated Wallets provided by Circle, Paycifi covers (sponsors) the network fees (gas fees) necessary for transactions. Paycifi reserves the right to terminate this sponsoring in case of abuse or changes in network pricing conditions.
  2. External Wallets: For any use of an External Wallet (e.g., MetaMask), the User must bear the entirety of the network fees (gas fees) alone.

17. Conversion fees (fiat ramp)

Fees related to the Fiat Ramp (fiat currency/crypto conversion) are billed directly by the conversion provider. Paycifi does not intervene in this financial flow and does not receive any commission on this operation, unless otherwise stated in a specific commercial agreement.

18. Specific agreements and volumes (enterprise)

For large volumes or personalised Smart Contract needs, adapted fee structures may be negotiated via a separate service contract derogating from these standard fees. Enterprise agreements may provide for bespoke commission rates, custom Smart Contract deployments, and volume-based discounts, all of which are governed by the terms of the applicable separate contract.

19. Arbitration fees

The Arbitrator's fees are set by the latter independently. The User acknowledges that Paycifi does not receive any retro-commission on arbitration fees and does not intervene in their negotiation.

Part C — Specific conditions for escrow contracts

20. Independence of contracts

The Contract generated via Paycifi constitutes the technical and cryptographic translation of the financial commitments between the Partners. This technical agreement is autonomous and distinct from any commercial or civil contract concluded elsewhere between the Partners. Paycifi is a third party to the contractual relations of the Partners and assumes, as such, no obligation or responsibility regarding the Payer's solvency, or the conformity or quality of the Beneficiary's services.

21. Programmable escrow mechanism

The funds are locked in a Smart Contract whose code is public, auditable, and verifiable on the block explorers of the blockchain used. This Smart Contract acts as an automated and neutral execution layer, whose operation is strictly limited to the programmed instructions validated by the Partners' cryptographic signatures. BE Blockchain SRL has no technical ability to modify, pause, redirect, or intervene in the execution of any Smart Contract once deployed, regardless of the circumstances, including in cases of fraud, regulatory action, or force majeure. The Partners expressly acknowledge and accept this architecture as a defining feature of the platform.

The User acknowledges that this mechanism operates as follows:

  1. Right of Withdrawal Before Acceptance: As long as all required Partners have not affixed their cryptographic signature to accept the Contract, the Payer retains the right to unblock and retrieve their funds at any time, without the agreement of the other parties.
  2. Irrevocability After Acceptance: Once the Contract has been accepted by all Partners and funded, the funds are locked. They can only be released by:
    • Unanimous validation by the Partners via cryptographic signature (release to the Beneficiary(ies));
    • Unanimous cancellation via cryptographic signature (return to the Payer);
    • An arbitration decision triggered by one of the Partners (if an Arbitrator has been designated).
  3. Programmed Unblocking by Expiration (Payer Security):
    • Acceptance Expiration: If the contract is not accepted by all Partners before the offer's expiration date, the funds are unblocked for the Payer. This unblocking becomes effective automatically on the scheduled due date.
    • Execution Expiration: In case of inaction by the Partners beyond the final execution date provided for in the contract, the funds are unblocked for the Payer, thereby terminating the escrow.

The Partners acknowledge that the exclusive remedies available to them in respect of any locked funds are those described in this Article and in Article 22. No other mechanism of intervention, recovery, or redirection exists within the platform architecture.

22. Dispute resolution and ICC arbitration

22.1 Designation of the Arbitrator

The Partners are free to pre-designate an arbitrator of their choice at the time of Contract creation, either from the list of Referenced Arbitrators available on the platform or as an External Arbitrator invited directly via email address or Wallet. By pre-designating an arbitrator, the Partners expressly agree that such person shall conduct the arbitration in accordance with the ICC Rules of Arbitration on an ad hoc basis. For the avoidance of doubt, arbitration conducted pursuant to these Terms is not administered by the ICC International Court of Arbitration. The ICC International Court of Arbitration shall only intervene to appoint the arbitrator if the pre-designated arbitrator is unable or unwilling to serve, or if no arbitrator was designated by the Partners at the time of Contract creation.

Referenced Arbitrators listed on the platform are independent professionals selected by Paycifi on the basis of professional qualifications and relevant expertise. They are not appointed by or affiliated with the ICC International Court of Arbitration. Paycifi guarantees neither the neutrality nor the competence of External Arbitrators.

22.2 ICC Expedited Arbitration

Failing an amicable settlement within thirty (30) days, the dispute shall be finally settled under the Rules of Arbitration of the International Chamber of Commerce (ICC). The parties expressly opt into the ICC Expedited Procedure Provisions pursuant to Article 30(3) of the ICC Rules of Arbitration (2021), regardless of the amount in dispute. The arbitration shall be conducted before a sole arbitrator appointed in accordance with Article 22.1.

22.3 Seat and Language

The seat of arbitration shall be Geneva, Switzerland. The language of the arbitration shall be English, unless otherwise agreed in writing by the Partners prior to the initiation of arbitration proceedings.

22.4 Technical Execution by Paycifi (Current Architecture – V1)

In the current version of the platform (V1), upon initiation of a formal Dispute Notification by a Partner, the Smart Contract enables the technical release of escrowed funds to the pre-designated Arbitrator's Wallet address, as recorded in the Smart Contract at the time of its creation. This transfer is executed autonomously by the Smart Contract upon the cryptographic instruction of the initiating Partner, without any discretionary intervention by BE Blockchain SRL. BE Blockchain SRL does not hold, control, or direct these funds at any point in this process. From the moment of transfer, the Arbitrator assumes sole custody of the funds as an independent fiduciary, acting under their own professional responsibility and subject to the ICC Rules of Arbitration. BE Blockchain SRL's technical mission in respect of the concerned Contract is concluded upon execution of this transfer.

This mechanism is transitional. BE Blockchain SRL is actively developing a V2 non-custodial arbitration architecture in which disputed funds will be held in a new independent escrow Smart Contract with pre-programmed allocation rules, eliminating the requirement for funds to transit through the Arbitrator's personal wallet. Users will be notified of the migration to V2 in accordance with Article 30 of these Terms.

22.5 Residual Jurisdiction

For disputes between the Partners themselves, arbitration pursuant to Article 22.2 shall be the exclusive method of resolution. For any dispute between a Partner and BE Blockchain SRL (as Publisher and operator of the Paycifi platform), and for any urgent, conservatory, or provisional measures required before the constitution of the arbitral tribunal, the courts of Belgium shall have exclusive jurisdiction. This provision does not affect the exclusive competence of Swiss courts to support the arbitration proceedings pursuant to the Swiss Private International Law Act (PILA) at the seat of arbitration in Geneva. Users established outside the European Union acknowledge that this forum selection constitutes a valid and binding clause under applicable international private law rules, without prejudice to their right to seek urgent or conservatory relief before any court of competent jurisdiction in their country of establishment.

22.6 Arbitrator's Status and Liability

Referenced Arbitrators listed on the platform have been subject to a due diligence review by Paycifi covering professional qualifications and relevant expertise. Notwithstanding such review, Referenced Arbitrators act as fully independent professionals. Prior to engaging with any Arbitrator (Referenced or External), the Partners are solely responsible for verifying that the Arbitrator holds adequate professional indemnity insurance commensurate with the value of the transaction. The Partners are invited to request confirmation of insurance coverage directly from the Arbitrator as a condition precedent to the designation. Paycifi does not provide professional liability insurance for any Arbitrator and disclaims all liability for any fault, negligence, or misconduct of the Arbitrator once the funds have been transferred from the Smart Contract to the Arbitrator's Wallet.

22.7 Transfer Conditions

The transfer of funds to the Arbitrator is only technically possible if:

  1. An Arbitrator has been pre-designated and accepted by all Partners at the time of Contract creation;
  2. A formal "Dispute Notification" has been initiated via the interface by a Partner justifying the opening of a procedure in accordance with the ICC Rules.

22.8 Amicable Settlement and Consent Award

The parties may, at any stage of the arbitration procedure and prior to the issuance of a final award, reach an amicable settlement of their dispute. In such event, the parties may jointly request the arbitrator to record the settlement in the form of a consent award (also referred to as an "award on agreed terms") pursuant to Article 32 of the ICC Rules of Arbitration (2021).

A consent award has the same legal force and effect as a final award on the merits and is enforceable in the same manner, including under the New York Convention on the Recognition and Enforcement of Foreign Arbitral Awards of 1958, in all signatory states.

Upon notification of an amicable settlement prior to the issuance of a final award, the ICC Court shall fix the fees of the arbitrator and the ICC administrative expenses taking into account the stage reached in the proceedings. Any balance remaining from the advance on costs paid by the parties shall be reimbursed in accordance with the ICC Rules.

23. Liability and warranty

Paycifi provides its Services on a best-efforts basis (an obligation of means) and "as is." BE Blockchain SRL disclaims all liability regarding:

  1. The Substance of Transactions: Disputes between Partners relating to the execution or quality of services are provided for in their private contracts.
  2. Arbitration: Decisions rendered by Arbitrators (Referenced or External) and the financial or operational consequences resulting therefrom for the Partners.
  3. Technological Risks: Events inherent in blockchain technology, as well as failures, interruptions, or asset freezes attributable to third-party providers (notably Circle).
  4. Excluded Damages: Expressly excluded from any compensation are losses of profit, losses of opportunity, losses of data, damage to image, or any missed commercial opportunity by the User.

24. Limitation of the Publisher's liability

To the extent permitted by applicable law:

  1. Indemnification Cap: The total and cumulative liability of BE Blockchain SRL / Paycifi, for any cause whatsoever, is strictly capped at the amount of service fees actually collected by Paycifi under the Contract that is the subject of the dispute.
  2. Annual Reference: Failing the ability to link the dispute to a specific contract, this cap is set at the total amount of fees paid by the User to Paycifi during the twelve (12) months preceding the generating event.
  3. Indirect Damages: BE Blockchain SRL shall under no circumstances be held liable for indirect, incidental, or consequential damages resulting from the use or the inability to use the platform.

25. Indemnification by the User

The User undertakes to warrant, indemnify, and hold harmless BE Blockchain SRL (as well as its directors and employees) from any claim, legal action, damage, loss, or sanction (including attorney's fees) resulting from:

  1. Use of the platform outside its professional scope or in violation of these Terms;
  2. A violation of applicable laws, regulations, or international sanctions by the User;
  3. A deliberate attempt to harm the integrity of Paycifi, BE Blockchain SRL, or the interests of other Users (notably via cyber-attacks or KYC or KYB fraud).
Part D — Intellectual property

26. Intellectual property and source available licence

26.1 Ownership

All intellectual property rights in and to the Paycifi platform, including but not limited to the Smart Contract source code, front-end interfaces, application programming interfaces (APIs), algorithms, documentation, trademarks, and visual identity, are and remain the exclusive property of BE Blockchain SRL or its licensors.

26.2 Source Available Licence (Business Source Licence – BSL 1.1)

The Smart Contract source code underlying the Paycifi platform is made publicly available ("Source Available") to enable independent security audits, academic research, and transparency verification. The publication of the source code does not constitute an open-source licence within the meaning of the Open Source Initiative (OSI) definition.

Subject to the terms and conditions of this Article, BE Blockchain SRL grants to any person who accesses the published source code a limited, non-exclusive, non-transferable, non-sublicensable, royalty-free licence to:

  • read and inspect the source code for the sole purposes of security auditing, academic research, or personal education;
  • verify the behaviour of deployed Smart Contracts against the published source code.

The following uses are expressly prohibited without prior written authorisation from BE Blockchain SRL:

  • any commercial use of the source code or any derivative thereof, including but not limited to operating a competing service, licensing the code to third parties, or integrating the code into any product or service offered for remuneration;
  • any reproduction, distribution, public communication, or creation of derivative works based on the source code;
  • any use of the source code, in whole or in part, to train, fine-tune, or otherwise develop artificial intelligence or machine learning models.

This licence shall automatically convert to the Apache Licence, Version 2.0 (Apache 2.0) on the date that is four (4) years after the initial public release of the relevant version of the Smart Contract source code (the "Change Date"), at which point the source code will be freely usable under the terms of the Apache 2.0 Licence, available at https://www.apache.org/licenses/LICENSE-2.0.

26.3 Trademarks

The names "Paycifi" and "BE Blockchain," as well as all associated logos, trade names, and visual identities, are the exclusive property of BE Blockchain SRL. No use of these marks is permitted without prior written consent.

26.4 Feedback

Any feedback, suggestions, or improvements communicated to BE Blockchain SRL by a User in connection with the platform shall be deemed non-confidential and may be freely used by BE Blockchain SRL without any obligation of compensation to the User.

Part E — General provisions and applicable law

27. Maintenance and "as is"

The service is provided "as is" and "as available." Paycifi reserves the right to suspend the user interface for maintenance without prior notice, which does not affect the persistence of Contracts on the blockchain.

28. Applicable law and jurisdiction

These Terms are governed by Belgian law. Any dispute between a User and BE Blockchain SRL relating to the use of the platform or the Publisher's liability (as opposed to disputes between Partners, which are governed by Article 22) shall be subject to the exclusive jurisdiction of the courts of Liège, Namur division, Belgium, without prejudice to any mandatory provisions of applicable law and to the provisions of Article 22.5 regarding the support jurisdiction of the Swiss courts at the seat of arbitration.

29. Severability clause

If any provision of these Terms is deemed invalid or unenforceable by a court, the other provisions shall remain in full force and effect. The invalid clause shall be replaced by a valid provision that most closely approximates the original economic intent.

30. Modification of the General Terms and Conditions

  1. Paycifi reserves the right to modify, supplement, or update these General Terms and Conditions at any time, notably in order to: (a) take into account the evolution of the services, functionalities, or technical architecture of the platform; (b) comply with any legal, regulatory, or jurisprudential developments; (c) integrate new versions of Smart Contracts or new third-party providers.
  2. Notwithstanding Article 30.1, any amendment to the dispute resolution and arbitration clauses shall not apply to Contracts already in escrow at the time of the update. Furthermore, Users will be notified at least thirty (30) days prior to the entry into force of any substantial change affecting service fees or fund release mechanisms.
  3. Any substantial modification of the General Terms and Conditions will be brought to the User's attention via notification through the interface, email, or publication on Paycifi's official website.
  4. Unless otherwise provided or required by mandatory legal provision, the modified General Terms and Conditions shall enter into force as of their publication or the date indicated in the notification.
  5. The continued use of the platform after the entry into force of the modified General Terms and Conditions constitutes the User's full and unreserved acceptance thereof.
  6. In case of disagreement with the new Terms, the User has the option to cease using the services, without affecting the autonomous and irreversible execution of the Smart Contracts already deployed on the blockchain.
  7. The General Terms and Conditions applicable to a given Contract are those in force on the date of its cryptographic signature by the Partners, without retroactive effect on Contracts already concluded, unless otherwise required by mandatory legal provision.
Schedule 1 — Third-party service providers and terms

Preliminary notice: To provide its infrastructure services, Paycifi integrates solutions from independent third-party providers. By accepting the Paycifi Terms and Conditions, the User expressly acknowledges and agrees to be bound by the respective terms and conditions of the following providers, which govern the specific services they deliver.

1. Identity Verification & Compliance (KYB/KYC)

2. Fiat-to-Crypto On/Off Ramp

  • Provider: JOIN Global SAS (Join Payments)
  • Service: Conversion services between fiat currencies (EUR/USD) and digital assets (stablecoins), as well as associated payment processing.
  • Applicable Terms: https://getjoin.io/terms

3. Digital Asset Infrastructure & Stablecoins

  • Provider: Circle Internet Financial, Ltd.
  • Service: Issuance and management of USDC/EURC stablecoins (MiCA-compliant Electronic Money Tokens) and provision of the Programmable Wallets (MPC) infrastructure used by Paycifi.
  • Applicable Terms: https://www.circle.com/en/legal

4. Payment Processing for Compliance Services

  • Provider: Stripe (Stripe Payments Europe, Ltd.)
  • Service: Processing of payments specifically related to the settlement of KYB (Know Your Business) verification fees.
  • Applicable Terms: https://stripe.com/fr-be/legal

5. Web3 Connectivity Protocol

  • Provider: WalletConnect (WalletConnect, Inc.)
  • Service: Communication protocol enabling the secure connection between the User's external wallet and the Paycifi interface.
  • Applicable Terms: https://walletconnect.com/terms

End of Terms and Conditions.

/ Developers /

API documentation

Onboard payers and partners, authenticate them with externally owned wallets, and operate the programmable escrow lifecycle — directly through the Paycifi REST API and the on-chain DShare contract.

Overview

Welcome to the Paycifi public API. These endpoints let you onboard payers and partners, authenticate them with externally owned wallets, interface with already-provisioned programmable wallets, and manage their business profile — without relying on the Paycifi frontend.

Getting started

  1. Provision or connect a wallet externally — create or attach a wallet using your own custody solution (EOA, your Circle tenant, etc.). Paycifi never provisions wallets for you.
  2. Authenticate via wallet signature — call GET /auth/nonce then POST /auth/nonce to issue access/refresh tokens for the connected wallet.
  3. Complete profile details (optional) — call POST /users/register once you collect the role-specific metadata required for agreements or arbitrators.
  4. Use agreement & protocol endpoints — operate the escrow lifecycle with the Agreements REST APIs plus the on-chain DShare contract.
  5. Maintain sessions — securely store the access/refresh tokens returned by wallet login and refresh them as needed.

Entry points

  • Wallet loginGET /auth/nonce + POST /auth/nonce for signature-based authentication using wallets fully controlled by the integrator.
  • Profile completion / arbitrator activationPOST /users/register with accountType set to arbitrator plus the additional fields listed in the Profile completion guide.

Integration path

Wallet (externally provisioned)
              │
              ▼
  GET /auth/nonce + POST /auth/nonce
              │
              ▼
POST /users/register  (if profile data required)
              │
              ▼
  Ready for Paycifi agreement & escrow endpoints

After completing wallet setup, authentication, and any required profile updates, the account is ready to create escrow agreements and operate through the rest of the Paycifi platform.

Note — Email/password authentication and delegate wallets are available only through Paycifi-managed products and are not part of the public integration surface.

Authentication

Authentication endpoints issue access and refresh tokens for users authenticating with externally owned wallets. Wallet creation and custody remain entirely under your control.

Wallet signature login

When should I use this?

Use when users own a wallet and prefer signing challenges instead of creating credentials. Wallets are fully provisioned and controlled externally by you or your users; Paycifi does not manage wallet creation in this flow. Required for wallets that skipped the email/password signup path. If the wallet address is not yet known, Paycifi automatically creates a new user record associated with that wallet during authentication.

Purpose

Authenticate owned-wallet users via nonce signing without using email/password credentials.

Preconditions

  • Client ensures a supported wallet extension/app is installed and connected.
  • Wallet creation happens outside Paycifi; only wallets you already manage can authenticate here.
  • This flow is intended exclusively for owned wallets and cannot be used to authenticate Paycifi-managed delegate wallets.
  • Client can display wallet modal interactions and capture signatures.

Client responsibilities

  • MUST verify that the wallet provider is installed and connected before requesting the nonce.
  • MUST present the nonce to the user for signing and capture the signature output.
  • SHOULD disconnect the wallet if the verification response lacks tokens.

API flow

  1. Client checks wallet availability. If absent, abort and display no-wallet.
  2. Client ensures the wallet is connected; otherwise, trigger wallet connection. Abort on failure with wallet-connection-error.
  3. Client calls GET /auth/nonce to retrieve { nonce, backSig }.
  4. User signs the nonce via the wallet. Abort on signature errors.
  5. Client submits POST /auth/nonce with { userAddress, frontSig, nonce, backSig }.
  6. Backend validates payload integrity, links or creates the user, generates JWTs, stores the refresh token, and returns { user, accessToken, refreshToken }.

Example request

POST/auth/nonce
POST /auth/nonce
Content-Type: application/json

{
  "userAddress": "0x92c5...bc10",
  "frontSig": "0x7c9c5b...",
  "nonce": "Please connect your wallet by signing the following message:\nnonce:5a84c3e98d9c",
  "backSig": "f8f1337dc5b5d5703f7d7a8b9814d9ebfca4d0f7f2bb1d3a39c2b1c4ab3d8e90"
}

Example response

{
  "user": {
    "userId": "6ce832d9-64a8-40f7-a8c9-61f8d7d00101",
    "walletAddress": "0x92c5...bc10",
    "walletType": "owned_wallet",
    "firstname": "Lena",
    "lastname": "Signer",
    "accountType": "standard"
  },
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Response handling

  • Success — persist tokens and user data, then proceed with any post-login flows.
  • Failure — inspect errorCode to guide user messaging (e.g., wallet missing, signature failure). Disconnect the wallet if instructed.

Error codes

  • no-wallet — wallet provider not detected.
  • wallet-connection-error — wallet could not connect or disconnected mid-flow.
  • signature-error / invalid-signature — user declined or wallet returned an invalid signature.
  • missing-data — nonce verification payload incomplete.
  • invalid-nonce — integrity check failed for nonce/backSig.
  • user-check-error, user-creation-error, refresh-token-update-error — backend persistence issues.

Related endpoints

  • GET /auth/nonce
  • POST /auth/nonce
Note — Email/password authentication exists only for Paycifi-managed delegate wallets and is not available to external integrators.

Profile completion & role activation

When should I use this?

Run immediately after the user authenticates via wallet signature (nonce login) and before granting access to any agreement workflow. Use for every wallet-authenticated user whenever you must capture legal/business details (name, address, arbitrator info) to participate in Paycifi agreements.

Purpose

Attach off-chain identity (email, name, business metadata) to the wallet that was already authenticated so Paycifi can route invitations, identify participants, and register arbitrators. POST /users/register completes or updates the authenticated user profile. The email captured here is required for agreement invitations, notifications, and participant identification — not for authentication.

Preconditions

  • Client session already carries valid tokens from the completed wallet signature authentication flow.
  • Wallet ownership has been verified and the wallet address is available from the token; this endpoint does not create or provision wallets.
  • Client has collected the required identity fields (firstname, lastname, email) plus any optional business metadata.

Client responsibilities

  • MUST include the Authorization header with the current accessToken.
  • MUST normalize emails to lowercase before sending them to the API.
  • SHOULD validate arbitrator-specific requirements (e.g., website) before submitting.
  • SHOULD set accountType to arbitrator only when the user meets the extra data requirements listed below.

API flow

  1. (Optional but recommended) Verify email availability via GET /auth/check-email-available/:email. Abort if available: false.
  2. Submit user data to POST /users/register (requires Authorization header). Payload must include firstname, lastname, normalized email, phone/address fields as collected, and accountType. Arbitrators must also provide website.
  3. Backend completes or updates the authenticated user profile, ensures wallet linkage, registers arbitrators when requested, and sends a welcome email.
  4. Backend returns the inserted user payload (and wallet metadata if applicable).

Arbitrator requirements

  • Set accountType to arbitrator.
  • Provide website (mandatory) and phone if available.
  • Include additionalInfo with context that will be shown to agreement participants.

Example request

POST/users/register
POST /users/register
Authorization: Bearer <accessToken>
Content-Type: application/json

{
  "firstname": "Paula",
  "lastname": "Integrator",
  "email": "ops@partner.com",
  "phone": "+32470001122",
  "country": "BE",
  "region": "Brussels",
  "city": "Brussels",
  "address1": "123 Rue Royale",
  "postalCode": "1000",
  "accountType": "arbitrator",
  "website": "https://arbitrators.paycifi.com"
}

Example response

{
  "userId": "f3f4d6f2-8f1e-4a08-9b90-2ec2d0b6f001",
  "firstname": "Paula",
  "lastname": "Integrator",
  "email": "ops@partner.com",
  "accountType": "standard",
  "walletAddress": "0x1234...abcd",
  "additionalInfo": null
}

Role activation & routing

The accountType field returned by /users/register dictates post-login routing: arbitrator accounts should be redirected to arbitrator dashboards / agreement-review flows; all other accounts should be routed to the standard agreement workspace. Persist this value so subsequent logins can immediately direct users to the correct feature set.

Error codes

  • wrong-user-id — Authorization missing or userId absent from token.
  • missing-data — firstname, lastname, email, or walletAddress not supplied.
  • email-already-exists — result from /auth/check-email-available.
  • user-insert-error — database failure while inserting user profile.
  • wallet-insert-error — internal data inconsistency while ensuring wallet linkage.
  • register-arbitrator-error — arbitrator-specific persistence failure.
  • registration-tx-error — generic transaction failure (rolled back).

Related endpoints

  • GET /auth/check-email-available/:email
  • POST /users/register

Agreements — Deal creation

When should I use this?

After the user has authenticated, completed wallet linking, and finished profile completion, when a payer is ready to formalize scope, participants, fees, and deadlines for a programmable escrow. Run this before any funding challenges or participant acceptance workflows, because those steps depend on the agreement ID generated here.

Purpose

Create a programmable deal that binds the payer, service providers, and an optional arbitrator around defined tasks, amounts, and deadlines. The backend stores the agreement, provisions invitations, and mirrors the payload on-chain; from that point, acceptance, validation, funding, arbitration, and payouts are enforced directly by the DShare smart contract while the backend supplies orchestration utilities and status reads.

Preconditions

  • Authentication — caller MUST include a valid Authorization: Bearer <accessToken> header. Only Paycifi-issued tokens are accepted; unauthenticated external wallets cannot invoke this endpoint.
  • Account state — the creator’s profile MUST be complete (POST /users/register done) and wallet setup finished so payer funding can occur later.
  • Participants & creator role — payload MUST include at least one payer and one provider. Exactly one participant MUST have owner: true, and agreementInfo.ownerUserId MUST match that participant’s userId and the authenticated user. The owner can be either the payer or a provider.
  • Arbitrator (optional) — send name, email, walletAddress, and optionally phone/additionalInfo. If the email already exists on a non-arbitrator user, the backend aborts with agreement-creation-service-error; otherwise it reuses or auto-registers the arbitrator and sends an invitation.

Client responsibilities

  • MUST provide normalized lowercase emails for all participants and arbitrator data.
  • MUST ensure agreementInfo.ownerUserId equals both the authenticated user ID and the participant flagged with owner: true.
  • MUST supply acceptanceDeadline and completionDeadline as UNIX timestamps in seconds.
  • MUST choose a supported currency code defined by Paycifi (agreementInfo.currency).
  • SHOULD ensure every agreementItems entry references an existing participant ID and includes the required pricing fields.

Arbitrator discovery

Use the dedicated arbitrator endpoint to fetch curated (Paycifi-approved) or non-curated arbitrators before calling POST /agreements.

GET/arbitrators?isCurated=true|false
  • Auth — requires the standard Authorization: Bearer <accessToken> header.
  • Query paramisCurated is mandatory. true lists curated arbitrators Paycifi already validated; false lists all non-curated arbitrators in your workspace.
  • Response — returns sanitized arbitrator objects { id, name, email, isAvailable } to pre-fill arbitrationSettings.
  • Availability check — to confirm whether a known arbitrator email is currently available, call GET /arbitrators/availability?email=<email>; it returns { success, available, arbitrator }.
GET /arbitrators?isCurated=true
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

[
  { "id": "23c44f2e-865e-4c2f-8f85-2d3c5d2a9e11", "name": "DShare Arbitration Desk", "email": "panel@paycifi.com", "isAvailable": true },
  { "id": "6a89e5fd-9342-4dbe-8b39-2064c3914ea4", "name": "Global Escrow Partners", "email": "team@global-escrow.io", "isAvailable": false }
]

Deadline handling

  • Deadlines are required and validated strictly. Inputs must be UNIX timestamps in seconds (milliseconds are normalized by dividing by 1000).
  • acceptanceDeadline must be greater than the current block timestamp.
  • completionDeadline must be strictly greater than acceptanceDeadline.
  • completionDeadline cannot exceed the current timestamp by more than ~100 years.
On-chain execution — funding, validation, arbitration, and payouts are executed directly on the DShare smart contract. Paycifi does not proxy these on-chain transactions for externally owned wallets; integrators perform blockchain interactions with their own tooling once the agreement is created and mirrored on-chain.

Example request

POST/agreements
POST /agreements
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "participants": [
    {
      "id": "payer-temp",
      "userId": "3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101",
      "participantType": "payer",
      "name": "Acme Corp",
      "email": "payer@acme.com",
      "owner": true,
      "additionalInfo": "Main funding entity"
    },
    {
      "id": "provider-temp",
      "userId": "92a4b2b6-45f5-4501-8e71-0d371cbb9011",
      "participantType": "provider",
      "name": "Studio Nova",
      "email": "studio@nova.io",
      "additionalInfo": "Creative agency"
    }
  ],
  "agreementInfo": {
    "title": "Website Localization Sprint",
    "description": "Localize the main marketing site in FR/DE",
    "currency": "USDC",
    "totalAmount": 1800,
    "feePayerStrategy": "payer",
    "acceptanceDeadline": 1735603200,
    "completionDeadline": 1738281600,
    "ownerUserId": "3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101",
    "network": "base"
  },
  "agreementItems": [
    { "id": "item-1", "participantId": "provider-temp", "description": "Landing page localization", "quantity": 1, "unitPrice": 900, "fees": 45 },
    { "id": "item-2", "participantId": "provider-temp", "description": "Product tour localization", "quantity": 1, "unitPrice": 900, "fees": 45 }
  ],
  "arbitrationSettings": {
    "name": "DShare Panel",
    "email": "arbitration@paycifi.com",
    "phone": "+33180000000",
    "additionalInfo": "Escrow arbitration panel",
    "walletAddress": "0x0000000000000000000000000000000000000000"
  }
}

Example response

{
  "success": true,
  "agreementId": "a55f1c3c-7de1-4ed3-8c90-9cf52a4b1d1a",
  "agreementInfo": {
    "id": "a55f1c3c-7de1-4ed3-8c90-9cf52a4b1d1a",
    "title": "Website Localization Sprint",
    "status": "pending",
    "currency": "USDC",
    "acceptanceDeadline": "2024-12-31T00:00:00.000Z",
    "completionDeadline": "2025-01-31T00:00:00.000Z",
    "payerTotalAmountWithFees": 1889.1
  },
  "participants": [
    { "id": "e0d1b4c5-0b80-4c08-8a58-90a8e4481f10", "participantType": "payer", "owner": true, "agreementStatus": "pending" },
    { "id": "17ce72bf-9b1a-4b70-8618-2afcce9f5f80", "participantType": "provider", "agreementStatus": "pending" },
    { "id": "db5a9fef-29ce-4cde-bc41-1881c5f5b24c", "participantType": "arbitrator", "agreementStatus": "pending" }
  ],
  "blockchainAgreement": {
    "agreementId": "0x613535f163332d6465312d34...",
    "contractAddress": "0xabc123...",
    "tokenAddress": "0xdef456...",
    "rpcUrl": "https://base-mainnet.g.alchemy.com/v2/...",
    "acceptanceDeadline": 1735603200,
    "completionDeadline": 1738281600
  }
}

Response handling

  • Success — persist agreementId, participants, and blockchainAgreement. Use participant IDs to drive acceptance and funding flows.
  • Validation errors (400) — inspect errorCode/missingData to fix payload issues (e.g., missing-data, missing-acceptance-deadline, bad-completion-deadline).
  • Role or currency errors (400)unknown currency indicates an unsupported code; deadline-too-far indicates completion is beyond the allowed horizon.
  • Server errors (500)fees-calculation-error, agreement-creation-error, agreement-creation-service-error, or agreement-creation-controller-error require retry after verifying payload and backend health.

Error codes

  • missing-data
  • fees-calculation-error
  • missing-currency
  • missing-acceptance-deadline
  • missing-completion-deadline
  • bad-acceptance-deadline
  • bad-completion-deadline
  • deadline-too-far
  • agreement-creation-error
  • agreement-creation-service-error
  • agreement-creation-controller-error

Related endpoints

  • POST /agreements — create the agreement and deploy it on-chain.
  • PATCH /agreements/participants/:participantId/status — collect accept/decline responses from each participant.
  • POST /agreements/:agreementId/recalculate-status — recompute the overall state after participant updates (optional helper).

Agreements — Invitations & acceptance

What an invitation means

  • When an agreement is created, the backend records all participants (payers, providers, arbitrators) and marks them with agreement_status = pending.
  • An “invitation” is an off-chain notification mechanism only. It does not grant access, permissions, or state changes on-chain.
  • Invitations are identity-based (email + role) rather than wallet-based. They do not pre-bind, reserve, or prove any wallet address.

Example invitation payload

{
  "agreementId": "d9b6da1a-432c-47d8-8b0d-9ac01aa4f1ce",
  "network": "polygon",
  "contractAddress": "0xabc123...789",
  "role": "provider",
  "email": "studio@nova.io"
}

This payload is informational. It does not include or reserve any wallet address.

Retrieve agreement data (required)

After receiving an invitation, the discovery step is to fetch the off-chain agreement snapshot:

GET/api/v1/agreements/:agreementId

This provides the participants and their emails, the participant’s partnerId (participants[].id) required for on-chain acceptance, and the expected role plus current agreement_status. It is a discovery/synchronization utility — the escrow protocol itself does not require this call if the participant already knows their partnerId through another trusted channel.

Acceptance is an on-chain action

Accepting an agreement is not an API call. Acceptance happens only when the participant’s wallet submits acceptAgreement(agreementId, partnerId) on the DShare smart contract. Both agreementId and partnerId are bytes32-encoded UUIDs.

acceptAgreement(bytes32(agreementIdUuid), bytes32(partnerIdUuid))

Wallet address binding happens at acceptance

At creation and invitation time, partner wallet addresses are not known on-chain. The contract binds the wallet address only when the participant accepts: the first successful acceptAgreement call records msg.sender as the wallet address for that partnerId. This binding is permanent and cannot be changed afterward.

The contract verifies the agreement is still Pending, the participant has not already accepted, the referenced partnerId exists, and no wallet is yet set for that partnerId. If valid, it marks the participant accepted, emits PartnerAccepted, and updates acceptance counters.

How to determine your partnerId

The partnerId is the participant UUID that identifies the partner entry in the agreement. Fetch the agreement details and match the invitation email to the returned participants list.

{
  "participants": [
    { "id": "17ce72bf-9b1a-4b70-8618-2afcce9f5f80", "participantType": "provider", "email": "studio@nova.io", "agreement_status": "pending" },
    { "id": "e0d1b4c5-0b80-4c08-8a58-90a8e4481f10", "participantType": "payer",    "email": "payer@acme.com",  "agreement_status": "pending" }
  ]
}

Here the invitation email studio@nova.io maps to partnerId = 17ce72bf-9b1a-4b70-8618-2afcce9f5f80.

No authentication requirement

Participants do not need to authenticate with Paycifi to accept an agreement. Any wallet can accept directly on-chain as long as it controls the address that will be recorded for that participant and knows the agreementId and partnerId. This lets external or unauthenticated wallets fully participate after receiving an invitation.

Optional off-chain synchronization

After a participant accepts on-chain, integrators may optionally call PATCH /agreements/participants/:participantId/status to synchronize off-chain status for dashboards. This is not required for on-chain acceptance and does not grant or revoke on-chain permissions. Declining off-chain does not perform any on-chain action; the DShare contract has no on-chain “decline invitation” operation.

Trust model

The Paycifi backend is not an authority for acceptance. The DShare smart contract is the single source of truth for acceptance state, role permissions, and lifecycle transitions. Use events such as PartnerAccepted and AgreementApproved as the authoritative feed; REST updates are optional synchronization helpers only.

Minimal end-to-end flow

Invitation received
        ↓
GET /api/v1/agreements/:agreementId
        ↓
Resolve partnerId by matching invitation email to participants[].email
        ↓
acceptAgreement(agreementId, partnerId)   (on-chain)
        ↓
PartnerAccepted event
        ↓
AgreementApproved event   (once all required participants accept and conditions are met)

Agreements — Retrieve user agreements

When should I use this?

Whenever a signed-in user needs a consolidated list of agreements they created or joined: dashboards, recent-activity views, or any post-login screen that must show ongoing deals, pending actions, or archived work.

Purpose

Expose the agreements visible to the authenticated user so clients can build list views, highlight pending obligations, and deep-link into details without duplicating backend filtering. The endpoint returns Paycifi’s indexed agreement summaries and participant metadata; on-chain funding, validation, arbitration, and payout events settle independently on DShare and are reconciled asynchronously.

Preconditions

  • A valid Paycifi session (Authorization: Bearer <accessToken> via the populateUser middleware). Malformed or expired tokens are rejected.
  • The userId path parameter MUST belong to the authenticated user; the backend rejects attempts to read another user’s agreements.
  • The user MUST be a participant (payer, provider, or arbitrator) in the agreements to see them.

API flow

  1. RequestGET /api/v1/agreements/user/:userId?status=<optional> with an Authorization header. The optional status must match an agreement_statuses.label value (e.g., pending, funded, completed).
  2. Visibility rules — only agreements where userId appears in any role are returned. Agreements the user archived (is_archived = true) are excluded regardless of status.
  3. Sorting & shaping — results are ordered by acceptance_deadline ascending and returned as summary objects with agreement metadata, role context (isOwner, selfParticipantType, userStatus, providersEmails), a nested payer snapshot, and the arbitrator name when present.

Example request

GET/api/v1/agreements/user/:userId?status=pending
GET /api/v1/agreements/user/3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101?status=pending
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Example response

[
  {
    "id": "d9b6da1a-432c-47d8-8b0d-9ac01aa4f1ce",
    "creationDate": "2025-01-04T11:22:03.145Z",
    "title": "Design Sprint Retainer",
    "description": "4-week design sprint with Nova Studio",
    "network": "polygon",
    "currency": "USDC",
    "totalAmount": 12000,
    "status": "pending",
    "arbitrationStatus": null,
    "acceptanceDeadline": 1736371200,
    "completionDeadline": 1738972800,
    "ownerUserId": "3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101",
    "isOwner": true,
    "selfParticipantType": "payer",
    "userStatus": "pending",
    "arbitratorName": null,
    "providersEmails": ["studio@nova.io"],
    "payer": {
      "id": "f0629825-ea62-4a79-83e0-020b4b3f07c1",
      "userId": "3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101",
      "name": "Acme Corp",
      "email": "payer@acme.com",
      "participantType": "payer",
      "owner": true,
      "status": "pending"
    }
  }
]

Response handling

  • Empty array — the user is not part of any agreement (or archived all of them). Show a zero-state and allow creation or invitation flows.
  • Partial visibility — use isOwner and selfParticipantType to tailor actions. The API never exposes agreements where the user is not a participant.
  • Navigation — use the returned id to fetch full details via GET /api/v1/agreements/:agreementId.

Error codes

HTTPError codeWhen it occurs
400missing-userIduserId path parameter is absent.
500agreements-retrieval-controller-errorUnexpected failure inside the controller when fetching agreements.
500agreementIds-retrieval-service-errorDatabase failure while assembling the agreement summary.

Agreements — Retrieve agreement details

When should I use this?

Immediately after a user selects an agreement from the list to render a full detail view, confirm readiness before funding, drive participant acceptance, or review arbitration activity. It is the prerequisite for any lifecycle action that depends on the latest snapshot of the agreement.

Purpose

Return the complete agreement payload — participants, items, deadlines, funding data, and blockchain references — so integrators can present accurate state and determine which follow-up actions (funding, acceptance, arbitration, unlock) are currently available.

Preconditions

  • Authentication — provide a valid Paycifi access token whenever retrieving this off-chain metadata (populateUser middleware). Reading the DShare contract directly on-chain does not require Paycifi authentication, but this REST snapshot does.
  • Access scope — the backend does not enforce participant-based filtering; clients MUST request only agreements their signed-in user is entitled to view.
  • Path parameteragreementId MUST be a valid UUID referencing an existing agreement with an on-chain contract address.

Example request

GET/api/v1/agreements/:agreementId
GET /api/v1/agreements/d9b6da1a-432c-47d8-8b0d-9ac01aa4f1ce
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Example response

{
  "agreementId": "d9b6da1a-432c-47d8-8b0d-9ac01aa4f1ce",
  "agreementInfo": {
    "title": "Design Sprint Retainer",
    "ownerUserId": "3f6f6b4f-9c7d-4b9b-9f5a-43b0d4c2f101",
    "acceptanceDeadline": 1736371200,
    "completionDeadline": 1738972800,
    "feesPct": 2.5,
    "feePayerStrategy": "payer_covers_all",
    "network": "polygon",
    "contractAddress": "0xabc123...789",
    "currency": "USDC",
    "totalAmount": 12000,
    "status": "pending",
    "arbitratorStatus": null
  },
  "participants": [
    { "id": "f0629825-...", "fullname": "Acme Corp", "email": "payer@acme.com", "participantType": "payer",    "agreement_status": "pending", "owner": true },
    { "id": "92a4b2b6-...", "fullname": "Studio Nova","email": "studio@nova.io","participantType": "provider", "agreement_status": "pending", "realisation_status": "not_started", "owner": false },
    { "id": "23c44f2e-...", "fullname": "DShare Arbitration Desk", "email": "panel@paycifi.com", "participantType": "arbitrator", "agreement_status": "pending", "owner": false }
  ],
  "agreementItems": [
    { "id": "agreement-name", "description": "Design Sprint Retainer", "isAgreementName": true },
    { "id": "9c442ff5-...", "description": "Sprint fee", "quantity": 4, "unitPrice": 3000, "participantId": "92a4b2b6-...", "providerStatus": "pending", "payerStatus": "pending" }
  ],
  "arbitrationSettings": { "id": "23c44f2e-...", "name": "DShare Arbitration Desk", "email": "panel@paycifi.com", "walletAddress": "0x5555...9999" },
  "blockchain": { "rpcUrl": "https://polygon.rpc.paycifi.com", "contractAddress": "0xabc123...789", "tokenAddress": "0xdef456...321", "createdAtBlock": 53288123 },
  "blockchainAgreement": { "agreementId": "0x646462...", "payer": "0x1111...", "provider": "0x2222...", "amount": "12000000000", "state": "Pending", "unlockFundsTxHash": null }
}

Response handling

  • 404 vs 409404 agreement-not-found indicates an invalid ID; 409 agreement-missing-contract-address means the record exists but lacks an on-chain contract, so blockchain data cannot be fetched.
  • State awareness — use agreementInfo.status, item statuses, and participant agreement_status to determine whether to show funding, acceptance, realization, or arbitration actions.
  • Next actions — only a payer participant with owner: true should see the “Fund” action, executed by calling the DShare contract from a wallet that signs transactions on-chain.

Error codes

HTTPError codeWhen it occurs
400missing-agreementIdPath parameter was omitted.
404agreement-not-foundNo agreement matches the provided ID.
409agreement-missing-contract-addressAgreement exists but has no contract address.
500agreement-detail-retrieval-controller-errorFailure while reading agreement data from the database.
500blockchainAgreement-retrieval-controller-errorFailure while fetching the on-chain snapshot.
Next step — from here, agreement behavior is no longer driven by REST APIs. Fund movements, validation outcomes, arbitration, refunds, and completion are governed entirely by the DShare on-chain escrow protocol (see below).

Protocol — Using the escrow

1. High-level overview

  • The DShare smart contract is the single source of truth for every state change after agreement creation.
  • Fund movements happen inside contract functions. When conditions are met, transfers execute immediately within the transaction that satisfied those conditions.
  • validateService is the core lifecycle function: it records participant decisions and automatically routes funds to partners, funders, or the mediator depending on the outcome.

2. Roles & on-chain permissions

  • Creator (on-chain) — the wallet that submits the createAgreement transaction (msg.sender). In the current architecture this is a backend-controlled signer acting on behalf of the initiating user, so creator-only actions such as cancelAgreement are authorized exclusively to the backend signer.
  • Funder (payer) — the wallet that deposits funds via fundAgreement. ONLY the funder can call unlockFunds or unlockAfterCompletionTimeout.
  • Partners / providers — each participant added to the agreement. ONLY a partner can call acceptAgreement for their partnerId, and partners share validateService permissions with the funder.
  • Mediator — optional address set at creation. ONLY the mediator can call mediatorApprove. Any validator (partner or funder) can escalate via ServiceState.CalledMediator.

3. Agreement lifecycle (authoritative)

Phase 1 — Acceptance

Each partner calls acceptAgreement(agreementId, partnerId) once their wallet is ready. The contract emits PartnerAccepted for every acceptance. When all partners have accepted and the funder has already locked funds, DShare automatically emits AgreementApproved. No funds move during acceptance; balances remain locked in escrow.

Phase 2 — Service validation (core logic)

validateService(agreementId, ServiceState state) can be called by any approved partner or the funder. ServiceState encoding:

0 = Pending
1 = Validated
2 = Declined
3 = CalledMediator

Every call updates the caller’s service state and the global counters. DShare moves funds inside this function as soon as the relevant condition is satisfied.

  • All validators approve — when the final validator submits Validated (1) and numApprovedServices == validatorCount, the same transaction pays each approved partner via ERC-20 transfers, sets fundState = Distributed / serviceState = Validated, and emits AgreementValidated. unlockFunds is not involved.
  • All validators decline — when the final validator submits Declined (2) and numDeclinedServices == validatorCount, the same transaction refunds the funder in full (protocol fees remain collected), sets fundState = UnlockedFund / serviceState = Cancelled, and emits UnlockFunds.
  • Arbitration escalation — any validator can pass CalledMediator (3) provided a mediator was set. The transaction immediately transfers the entire net amount to the mediator, sets serviceState = Mediation, and emits AgreementMediated. This bypasses unlock logic and is irreversible.

4. Fallback & emergency paths

These functions do not run during the normal lifecycle. They exist for exceptional cases and always require a manual transaction from the funder.

  • unlockFunds — callable only by the funder while globalState == Pending, serviceState == Pending, and funds are still locked. Early exit before approval: refunds the funder immediately and emits UnlockFunds.
  • unlockAfterCompletionTimeout — callable only by the funder after the completion deadline has passed, provided the agreement is not cancelled, not in mediation, and funds remain locked. Deadline-based manual refund; emits UnlockFundsAfterTimeout.

5. Cancellation

cancelAgreement(agreementId) can be executed only by the creator while the agreement is pending. If escrow funds were locked, the same transaction refunds the funder and sets fundState = UnlockedFund before emitting AgreementCancelled. No automatic cancellation exists.

6. Event-driven integration

Integrators MUST subscribe to events to track the escrow without polling:

  • PartnerAccepted, AgreementApproved, AgreementValidated, AgreementMediated, UnlockFunds, FundsUnlocked (ERC-20 payout confirmation), UnlockFundsAfterTimeout.

Events are emitted in the exact transaction that moved funds or changed state, making them the authoritative feed for dashboards, accounting, and alerts.

7. Transaction signing model

The DShare escrow protocol is wallet-agnostic. Any Ethereum-compatible wallet (EOA, smart wallet, MPC, custodial service) can interact with the contract, provided the wallet address matches the role stored on-chain (creator, funder, partner, or mediator). The protocol relies exclusively on msg.sender equality checks for authorization.

8. Summary

ScenarioFunction that moves fundsTriggering roleAutomatic / explicit
All validators approvevalidateService (final call, ServiceState.Validated)Approving validatorAutomatic (inside the call)
All validators declinevalidateService (final call, ServiceState.Declined)Declining validatorAutomatic refund
Arbitration escalationvalidateService (ServiceState.CalledMediator)Any validatorAutomatic mediator payout
Early exit before approvalunlockFundsFunder onlyExplicit transaction
Missed completion deadlineunlockAfterCompletionTimeoutFunder onlyExplicit transaction
Creator cancels pending agreementcancelAgreementCreator onlyExplicit transaction (refund if funded)
/ Contact /

Talk to our team.

Tell us about your deal. We typically reply within one business day.

Message sent.

Thanks — we've received your message and will reply within one business day. You can also reach us directly at contact@paycifi.com.

We'll reply within one business day. Your details are only used to respond to your enquiry.