Introduction

SafePulse is a trustless, non-custodial smart contract platform designed to power the next generation of digital agreements. It provides the infrastructure for automated, self-executing, on-chain collaborations—enabling users to manage payments, coordinate work, and verify data without ever surrendering control of their assets or private information.

In the modern digital economy, the systems that promise security and reliability often introduce the very risks they aim to solve. Banks, escrow providers, marketplaces, and centralized platforms sit between users and their agreements, imposing rigid rules, high fees, opaque decision-making, and custodial vulnerabilities. These intermediaries have become chokepoints—gatekeepers of value, data, and trust.

SafePulse presents a new paradigm: a world where agreements are borderless, collaboration is automated, and fraud becomes mathematically impossible. Here, sovereignty is restored to individuals and organizations. Here, the contract is not a PDF—the contract is the code.

SafePulse exists to replace fragile intermediaries with verifiable execution, enabling anyone, anywhere, to transact directly with confidence.

Vision

Our vision is to build a world of sovereign agreements—a global environment where interactions between individuals and enterprises are trustless, efficient, and fully programmable. Today, peer-to-peer work—whether freelance tasks, intellectual property transfers, or complex B2B collaborations—is constrained by manual processes, ambiguous terms, and reliance on traditional institutions.

SafePulse aims to make future universal. The logic of cooperation—once enforced by bureaucracy—will now be enforced by transparent, unstoppable code.

Why Now

The digital economy has grown beyond the capabilities of its analog legal frameworks. Remote work, AI, global talent markets, and borderless digital businesses are creating unprecedented demand for secure, programmable agreements.

But traditional systems cannot keep pace:

• centralized platforms hold funds and data hostage,
• intermediaries charge fees that outstrip transaction value,
• cross-border payments remain slow and fragmented,
• users depend on institutions that can censor or fail.

At the same time, decentralized technologies—cryptographic signatures, verifiable credentials, decentralized identity, and smart-contract infrastructure—have matured. What was once theoretical is now practical, accessible, and ready for mass adoption.

SafePulse bridges this gap, making advanced cryptographic security and automated agreements usable by anyone with a smartphone.

The Problem

Modern digital interactions—payments, cross-border deals, document verification, and identity—are plagued by structural weaknesses:

1. Fraud & irreversible loss

Crypto markets and digital transactions have seen billions in losses (2023–2025) from investment scams, phishing attacks, and wallet compromises. Users have little recourse once funds are gone.

2. Custody vulnerabilities

Exchange breaches and wallet exploits continue to produce large-scale losses. Models where platforms or apps control user assets create concentrated risk.

3. Slow, costly cross-border settlement

International transactions rely on chains of correspondent banks, compliance checks, and fragmented regulations—adding delays and unpredictable fees.

4. Expensive disputes & fragmented arbitration

Even small international business disputes can balloon into six- or seven-figure legal battles, draining resources and delaying outcomes.

5. Sanctions & AML exposure

Global regulatory frameworks require safe, compliant value transfer. Platforms that fail to prevent illicit use face serious enforcement or shutdown risk.

6. High operational and platform costs

Escrow, arbitration, financial platforms, and marketplaces introduce fees and administrative overhead that make small or cross-border deals impractical.

These problems persist because trust is centralized, execution is manual, and verification is weak.

The Solution

SafePulse is a decentralized, non-custodial smart contract platform designed for automated, programmable agreements. It transforms the way individuals and businesses collaborate by providing the tools to create and execute contracts without intermediaries.

1. Agreements Beyond Payments

Users can create conditional, progressive, revocable, or time-bound contracts—no coding required. Each agreement is fully automated and self-enforcing.

2. Your Keys. Your Assets. Always.

Funds never leave the user’s wallet unless conditions are cryptographically verified. Smart contracts act as neutral escrow agents that unlock assets only when the rules of the agreement are met.

3. Proofs, Not Promises

Users can attach verifiable documents and proofs of verifications and authenticity. The result is tamper-proof evidence tied directly into the agreement’s execution logic.

4. Global, Borderless, and Unrestricted

Anyone can transact using stablecoins or native cryptocurrencies, regardless of geography. There are no mandatory KYC barriers for core functionality and no minimum deal size.

SafePulse turns trust into math—automated, transparent, and unbreakable.

Mission

In an era shaped by digital uncertainty, SafePulse’s mission is to give individuals and organizations the ability to collaborate securely and autonomously. We offer the infrastructure and software application for a new social contract, where:

• fairness is enforced by code,
• transparency is inherent,
• privacy is preserved, and
• interactions require no permission from intermediaries.

Our goal is simple: enable people to transact with anyone, anywhere, under rules they choose and technology they trust.

Why SafePulse

SafePulse is built on principles that make it uniquely capable of supporting sovereign digital agreements:

1. Non-Custodial Funds

Users control their assets directly at all times. Payments use native tokens or stablecoins, and funds never pass through platform custody.

2. Non-Custodial Data Architecture

Users store their own files—on decentralized networks or their preferred centralized storage. SafePulse verifies proofs, guaranteeing privacy and autonomy.

3. On-Chain Verification

Every action is cryptographically signed and recorded, creating:

• fraud-proof authenticity,
• immutable history,
• identity flexibility (with DID or full anonymity).

4. Blockchain-Backed Verifiable Credentials

Credentials originate from the user’s wallet and are validated against on-chain data, ensuring trust while preserving privacy.

5. Payments Bound to Agreements

Funds move only when verification proofs and conditions match the contract logic. Your wallet signature is your approval.

6. Progressive Execution

Agreements can be funds progressively in flexible way.

7. Time-Bound Logic

Contracts enforce deadlines, freezing assets or documents during disputes until parties meet their agreed terms.

8. Cost Efficiency

Automated execution removes intermediaries and reduces financial overhead, making global agreements accessible and predictable.

9. No KYC — Privacy by Default

Users may remain anonymous or pseudonymous. Trust is derived from cryptographic proofs, not identity documents.

10. Automated Deployment

With a few taps, anyone can deploy secure smart contracts without writing code—ideal for freelancers, creators, SMBs, and enterprises.

11. Jurisdiction & Responsibility

SafePulse is not a legal or financial intermediary. It provides tools, not adjudication:

• users select their own jurisdictions,
• disputes freeze assets automatically,
• only the involved parties can resolve or complete contracts,
• the platform operator has zero access to user funds or private data.

SafePulse stands as a foundational layer for the next generation of digital collaboration: autonomous, verifiable, and truly sovereign.

Test Environment

Most core protocol contracts are deployed on Ethereum Sepolia as a public test environment. Test environment is available on SafePulse Lite dapp: https://app.safepulse.xyz

Available Contracts on Sepolia

The following smart contracts are available for testing:

• Escrow
• Document Registry
• Credential Registry
• Pledge Contract
• Test PULSE Token

These contracts replicate the mainnet logic and allow users to test full protocol workflows before interacting with production deployments.

Getting Sepolia Test ETH

To interact with the protocol, users need Sepolia ETH for gas fees.

You can request free test ETH from the following faucet providers:

• Google Cloud Web3 Faucet: https://cloud.google.com/application/web3/faucet/ethereum/sepolia

• QuickNode Sepolia Faucet: https://faucet.quicknode.com/ethereum/sepolia

• Alchemy Sepolia Faucet: https://www.alchemy.com/faucets/ethereum-sepolia

• Infura Sepolia Faucet: https://www.infura.io/faucet/sepolia

Submit your wallet address to receive test ETH.

How to Test

Claim Sepolia test ETH from one of the faucet providers, then switch your wallet network to Ethereum Sepolia from the network options. Once connected to Sepolia, you can access the protocol frontend and interact with the deployed Escrow, Document Registry, Credential Registry, and Pledge contracts using the Test PULSE token.

Important Notes

• Sepolia tokens have no real value
• Test PULSE token is only for testing purposes
• For buying Test PULSE, users do not need an ELYPS access token
• Always verify you are connected to Ethereum Sepolia before interacting
• Mainnet deployments require real assets

Concepts

• DID
• Elysium Protocol
• Pulse Token
• ElysianPulse Token
• Decentralized Storage

DID

Overview

DID stands for Decentralized Identifier. A DID is a globally unique identifier that allows its controller to prove cryptographic control over it. The entity controlling a DID is called the controller. DIDs are not limited to humans—they can represent organizations, devices, data models, or any abstract entity.

A DID identifies any subject (e.g., person, organization, device, or data model) that the controller decides it identifies.

DIDs are persistent identifiers: even if the associated cryptographic material changes, the DID itself does not need to change. A single DID can have multiple keys, and these keys can be rotated independently. DIDs are typically shorter than the raw public keys they use, making them convenient as stable identifiers.

Each DID is associated with a DID Document, which describes:

• The subject of the DID
• Public keys (verification methods)
• Authentication mechanisms
• Authorized controllers
• Service endpoints for interaction

DID Methods

A DID method defines how DIDs are created, resolved, and updated. It specifies:

• The DID format
• Supported operations (key rotation, adding controllers, etc.)
• Cryptography and encoding

Here we focus on two DID methods: did:key and did:ethr (ERC‑1056).

did:key

did:key is a purely generative DID method. The DID is deterministically derived from a public key, so there is no registry or blockchain involved.

Syntax

did:key:<multibase-encoded-public-key>

Example:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

• The DID itself encodes the key using multicodec and multibase.
• There is no need for transactions or on-chain storage.

DID Document

A did:key DID Document includes:

• verificationMethod: public key(s) derived from the DID
• authentication and assertionMethod: keys authorized for signing and verification
• keyAgreement (optional): derived keys for encryption

Example:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "verificationMethod": [
    {
      "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
      "publicKeyMultibase": "z<multibase-encoded-key>"
    }
  ],
  "authentication": [
    "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  ],
  "assertionMethod": [
    "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  ]
}

Key points:

• The DID is self-controlled (the key is its own controller).
• There is no need for registration, and the DID Document can always be derived from the public key.

did:ethr (ERC‑1056)

did:ethr is a DID method anchored on Ethereum using the ERC‑1056 Lightweight Identity standard.

Overview

ERC‑1056 defines an on-chain identity registry that enables:

• Adding/removing delegates for signing or key management
• Adding attributes such as service endpoints or verification keys
• Rotating keys or updating controllers
• Tracking actions via Ethereum transactions

The DID method allows DIDs to be self-sovereign while anchored on Ethereum for verification and persistence.

Syntax

did:ethr:<ethereum-address>

Example:

did:ethr:0xAbC123456789abcdef123456789abcdef1234567

For testnets:

did:ethr:goerli:0xAbC123456789abcdef123456789abcdef1234567

DID Document

When resolved, the DID Document includes:

• verificationMethod: keys/delegates registered on-chain
• authentication: keys authorized for authentication
• service: optional endpoints registered as attributes
• controller: the Ethereum address or delegates controlling the DID

Example:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:ethr:0xAbC123456789abcdef123456789abcdef1234567",
  "controller": "did:ethr:0xAbC123456789abcdef123456789abcdef1234567",
  "verificationMethod": [
    {
      "id": "did:ethr:0xAbC123456789abcdef123456789abcdef1234567#delegate-1",
      "type": "EcdsaSecp256k1RecoveryMethod2020",
      "controller": "did:ethr:0xAbC123456789abcdef123456789abcdef1234567",
      "publicKeyHex": "02ab..."
    }
  ],
  "authentication": [
    "did:ethr:0xAbC123456789abcdef123456789abcdef1234567#delegate-1"
  ],
  "service": [
    {
      "id": "did:ethr:0xAbC123456789abcdef123456789abcdef1234567#linked-domain",
      "type": "LinkedDomains",
      "serviceEndpoint": ["https://example.com"]
    }
  ]
}

Key points:

• The DID is anchored on-chain, allowing verifiable and auditable changes.
• Only delegates or the Ethereum address itself can update keys, controllers, or service endpoints.
• Updates require Ethereum transactions, which may incur gas costs.

Comparison: did:key vs did:ethr

Summary

• did:key is simple and deterministic, ideal for ephemeral or off-chain DIDs.
• did:ethr is Ethereum-backed, supporting verifiable, auditable, and self-sovereign identities on-chain.
• Both methods resolve to DID Documents that specify keys, controllers, authentication, and services.

Contract DID

Decentralized Identifiers (DIDs) are a cornerstone of identity in decentralized systems, enabling users, organizations, and digital assets to have self-sovereign, verifiable identities. In the context of smart contracts, SafePulse introduces Contract DIDs — a method of assigning globally unique identifiers to deployed contracts, registries, and other on-chain entities, while maintaining privacy and controlled access.

Contract DIDs serve as cryptographic handles that represent deployed contracts or registries on a blockchain. They allow users to reference, interact with, or verify these entities without exposing sensitive internal data.

Structure of Contract DID

A Contract DID is constructed in the following format:

did:ethr:<chain-id>:<contract-id-hex>[;key=<cipher-key-hex>]

• did:ethr – Indicates that this is an Ethereum-compatible DID.
• – The chain ID where the contract is deployed.
• – The unique identifier of the deployed contract in hexadecimal format.
• key= (optional) – A private cipher key used for securing contract data. This key must never be shared with unrelated parties, as possession allows decryption of sensitive contract information.

Example:

did:ethr:1:0x4b3c7a9e5f2d3a6b8c9d0e1f2a3b4c5d6e7f8a9b;key=0a1b2c3d4e5f67890123456789abcdef

In this example:

• The contract is deployed on Ethereum mainnet (chain-id 1).
• The contract’s address is 0x4b3c7a9e5f2d3a6b8c9d0e1f2a3b4c5d6e7f8a9b.
• A private cipher key is associated to encrypt sensitive contract state.

Registry DID

Contracts often interact with registries — on-chain data structures that map, verify, or index other contracts, users, or assets. Registry DIDs are assigned in a simpler format to reference these registries:

did:ethr:<chain-id>:<32byte-hash-hex>

• – Blockchain network where the registry resides.
• <32bit-hash-hex> – A unique hash representing the registry or dataset.

Example:

did:ethr:5:0x9f8a7b6c5d4e3f2a1b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2

Registries can store mappings of users to their Contract DIDs, smart contract metadata, or verifiable records, enabling tamper-proof lookup, automated verification, and secure referencing.

Usage and Privacy Considerations

• Contract DIDs allow users to interact with contracts securely by referring to a permanent on-chain identifier without needing the raw contract address.
• Sensitive data inside contracts or registries can be encrypted with the private key parameter (key=<cipher-key-hex>).
• Only authorized parties should be given access to the cipher key; sharing it externally may compromise the security of encrypted contract data.
• Users can query registries using Registry DIDs to discover or verify associated Contract DIDs, enabling decentralized discovery while maintaining privacy.

Key Benefits

1. Decentralized Reference: Provides a global, verifiable identifier for smart contracts and registries.
2. Secure Access Control: Optional cipher keys allow encrypted contract states to remain confidential.
3. Tamper-Proof Registry Mapping: Registry DIDs provide a verifiable method to index contracts and users.
4. Interoperability: Compatible with Ethereum and EVM-based chains, making Contract DIDs usable across multiple networks.

This structure ensures that SafePulse users can maintain self-sovereign identity for contracts and registries, interact securely with encrypted smart contracts, and trust the authenticity of registry data without relying on centralized services.

Elysium Protocol

The Elysium Protocol represents the premium Meta protocol within the SafePulse ecosystem. While SafePulse itself is designed as a fully non-custodial infrastructure, Elysium provides an exclusive high-tier environment for users who require maximum security, operational sovereignty, and access to advanced features.

Unlike standard SafePulse services, Elysium is reserved exclusively for Elysian Accounts, which are verified through the possession of ElysianPulse Tokens. This architecture ensures that access, permissions, and operations are fully tied to token ownership, granting users unparalleled control over their interactions.

Elysian Accounts: The ElysianPulse Token Access Standard

An Elysian Account is the designation for authenticated holders of ElysianPulse Tokens (ELYPS). ElysianPulse Tokens are:

• Limited-supply ERC-20 tokens
• Non-tradable and not listed on exchanges
• Functionally exclusive, granting access to premium features

Key Features:

1. Transferable Access

   • Ownership of a ElysianPulse Token directly grants access to Elysium services.
   • Transferring the token instantly transfers account privileges, making access fully token-based.

2. Access Standard

   • To maintain an Elysian Account, a minimum threshold of tokens must be held.
   • This ensures commitment to the ecosystem and manages access to the most advanced platform services.

3. Explicit Payment Control

   • ElysianPulse Tokens do not automatically pay for services.
   • Users must explicitly approve any token usage for transactions, maintaining full control over assets.

Key Components of Elysium Protocol

Elysium extends the capabilities of SafePulse through a set of premium tools and infrastructure, designed to support high-security, high-value, non-custodial operations.

1. The Pledge Contract

• A high-sovereignty smart contract system that ensures accountability through verifiable security stakes.
• Directly integrates with the Verifiable Document Service to automate contract execution based on verified data.
• Conditional execution ensures that asset or payment release is only triggered upon verified approval, reducing risk and enforcing trustless automation.

2. Verifiable Document Service

• Provides advanced document integration and verification for Elysian Accounts.
• Supports binding external legal documents and institutional credentials to smart contracts.
• Ensures documents act as mandatory triggers for contract execution, enhancing control and cryptographic auditability.

3. Pulse

• Pulse is a premium execution asset exclusive to Elysian Accounts.
• Powers advanced services including: pledge contracts, document processing, and high-value interactions.
• Enhances security, integrity, and tamper-proof execution for all premium operations.
• Provides maximum user sovereignty, ensuring that users maintain full control over complex contracts.

ElysianPulse Token (ELYPS)

• Non-financial ERC-20 token
• Serves as the access credential to Elysium services.
• Intentionally non-tradable, ensuring that access is utility-focused, not speculative.
• Grants access only; public users without ELYPS can still use open services but cannot access Elysium services.

Pulse (PULSE)

• Internal transactional and execution token for performing high-value on-chain actions.
• Non-tradable, operates exclusively within the SafePulse ecosystem.
• Only ElysianPulse holders can use Pulse to execute premium services, ensuring authenticated, secure, and auditable operations.

Pulse Token

Pulse (PULSE) is the execution token within the SafePulse Elysium ecosystem, used exclusively for performing premium on-chain operations. It powers high-security actions such as executing Pledge Contracts, processing Verifiable Documents, and other Elysium services. Unlike traditional tokens, Pulse is non-tradable and confined to internal platform use, ensuring that its value is functional rather than financial.

PULSE acts as a transactional asset, providing a secure mechanism to perform critical operations while maintaining data integrity, cryptographic assurance, and tamper-proof execution. Access to Pulse-powered services is limited to ElysianPulse Token holders, ensuring that only verified users can engage in high-value interactions.

By separating access credentials (ELYPS) from execution capabilities (PULSE), SafePulse achieves a robust dual-token model. This design provides maximum user sovereignty, enabling individuals to control both who can access services and how their operations are executed, all without sacrificing security or trustless automation. PULSE ensures that premium transactions are authenticated, secure, and auditable, providing a foundation for high-stakes, non-custodial operations.

ElysianPulse Token

The ElysianPulse Token (ELYPS) is a non-financial, ERC-20 utility token that functions as the key to access Elysium Protocol’s services. Unlike typical blockchain tokens, ELYPS is not designed for trading or speculation. Instead, it serves purely as a access credential, ensuring that only authenticated users can access high-tier features within the SafePulse ecosystem.

ELYPS is issued in limited supply. Holding a ElysianPulse Token designates the user as an Elysian Account, granting privileges such as access to Elysian section of ecosystem, the Pledge Contract system, the Verifiable Document Service, and the Pulse execution suite.

The token provides transferable access: ownership of ELYPS directly correlates with Elysian Account privileges. When a token is transferred to another wallet, the new owner immediately receives full access rights, ensuring a flexible and user-sovereign access model. Importantly, ELYPS is not automatically consumed for payments. Users must explicitly approve its use for any transaction or service access within Elysium, giving them absolute control over their assets.

Through ELYPS, the SafePulse ecosystem ensures a secure, controlled, and high-value user experience, where access to the most sophisticated services is token-gated and permissioned, rather than open to public or speculative trading.

Decentralized Storage

Decentralized storage refers to a method of storing digital data across a distributed network rather than on centralized servers. By leveraging blockchain and peer-to-peer technologies, decentralized storage ensures data immutability, censorship resistance, and long-term availability, empowering users with full control over their data without relying on any single authority.

In the SafePulse ecosystem, decentralized storage plays a critical role in storing verifiable documents, smart contract references, and other high-value data assets, enabling secure and verifiable interactions between users, smart contracts, and third parties. Two of the most widely used decentralized storage protocols are Arweave and IPFS (InterPlanetary File System).

Arweave

Arweave is a permanent, blockchain-backed storage protocol designed for long-term, immutable data storage. Data uploaded to Arweave is stored in a distributed network and guaranteed to persist forever through a one-time upfront fee. Each piece of data stored is assigned a unique transaction ID (TxID).

The TxID serves as a permanent reference to the stored data, allowing it to be retrieved, verified, and referenced by smart contracts, applications, or users at any time. Arweave’s storage model ensures that once data is uploaded, it cannot be altered or deleted, providing tamper-proof auditability critical for legal, institutional, and contractual documents.

Arweave employs a blockweave structure, an evolution of traditional blockchain, which links data together using a combination of cryptographic proofs and consensus mechanisms. This ensures both data permanence and efficient network scalability.

IPFS (InterPlanetary File System)

IPFS is a peer-to-peer distributed file system that addresses data by its content hash rather than its location. Unlike centralized servers where files are located at a fixed URL, IPFS retrieves data from any node storing that content, making the system resilient and decentralized.

Every file or folder uploaded to IPFS is assigned a Content Identifier (CID), a cryptographic hash of the file’s contents. The CID ensures integrity, meaning any modification to the file results in a different CID. This makes IPFS ideal for verifiable, tamper-resistant references in decentralized applications.

IPFS operates with a distributed hash table (DHT) to locate nodes storing the requested content. When a user requests a file via its CID, the network identifies peers hosting the file and retrieves it efficiently from multiple sources, ensuring redundancy and fault tolerance. Unlike Arweave, IPFS data persistence depends on pinning services or active hosting, as files may not remain available unless intentionally preserved.

Identifiers: Arweave TxID vs IPFS CID

• Arweave TxID: A unique transaction identifier that permanently links to stored data on the Arweave network. Once uploaded, data associated with a TxID is immutable and guaranteed to persist indefinitely.
• IPFS CID: A content-based cryptographic hash that identifies a file by its content. Changing the file changes its CID. Data availability depends on nodes hosting or pinning the content.

By combining Arweave and IPFS, SafePulse ensures both permanent and distributed storage options, allowing users to store critical documents securely, reference them in smart contracts, and verify them without relying on any centralized system. These protocols are essential for tamper-proof operations, verifiable credentials, and long-term digital record integrity.

Services

• Payment & Agreement
• Document & Verification
• Idenitity

Payment & Agreement Layer

Introduction

The Payment & Agreement Layer is the foundation of SafePulse’s trustless financial ecosystem. It provides secure, automated, and transparent mechanisms for managing funds, contracts, and conditional agreements between parties — all without relying on intermediaries or custodians.

This layer is designed for a wide spectrum of users:

• Individuals: Freelancers, gig workers, and peer-to-peer (P2P) payments
• Businesses & Enterprises: Small B2B contracts, milestone-driven projects, and enterprise workflows

Every service in this layer leverages on-chain smart contracts to provide trust, security, and automation, ensuring that agreements execute exactly as defined and that funds are handled safely.

Layer Overview

Key Objectives of the Layer:

• Enable trustless, high-value transactions
• Protect participants with automatic enforcement
• Facilitate milestone-based and phased payments
• Reduce reliance on intermediaries or centralized authorities

Services in the Payment & Agreement Layer

1. Escrow

Purpose: Escrow provides a trustless, non-custodial payment mechanism that securely holds funds until agreed-upon conditions are fulfilled. It is ideal for high-value transactions, protecting both buyers and sellers while remaining cost-effective compared to Pledge Contracts.

Key Features:

• Flat deposit fee + 1% withdrawal fee
• Supports revocable, time-bound, and rollback agreements
• On-chain enforcement ensures transparency and trust
• High-value capable, yet simpler and cheaper than Pledge Contracts
• Managed fully via the SafePulse Wallet

How It Works:

1. Sender deposits funds into the Escrow smart contract
2. Funds remain locked until the recipient fulfills the agreement
3. Upon completion, buyer release funds and let seller to withdraw funds
4. Conditional rollback or cancellation is supported if obligations are unmet

Use Cases:

• Freelance / Gig Work: Client deposits → Freelancer delivers → Funds released
• P2P Item Purchases: Buyer deposits → Seller delivers → Buyer verifies → Funds released
• High-Value B2B Transactions: Secure large payments for prototypes, consulting sessions, or licensing deals
• Deposits, Reservations, and Rentals: Automatically refundable if conditions fail

Benefits:

• Trustless transactions without intermediaries
• Cost-effective for high-value and regular payments
• Automated enforcement via smart contracts
• Secure, transparent lifecycle

2. Pledge Contracts

Purpose: Pledge Contracts extend escrow functionality to larger, progressive, or complex agreements, making them ideal for enterprise-grade projects and high-value contracts requiring multiple payments on agreement, verification, or document linkage.

Key Features:

• Milestones & partial payouts — flexible progressive payments, multiple payment linkage
• Revocable & rollback options for flexible risk management
• Document binding — sync with document, automated on-chain verification and authentication, ensures enforceability and auditability
• One-time creation fee with 0% ongoing fees
• Example: 33 Pulse per contract deployment
• Fully integrates with Verifiable Documents, syncing payout conditions with document status

How It Works:

1. Contractor deploy verifiable document contract and enter document contract DID for pledge contarct creation
2. Funds are deposited into the Pledge Contract smart contract
3. As each parties verify document, funds are released automatically
4. All contract terms, payments, and document interactions are on-chain and cryptographically secured and auditable

Note: Pledge contract is an sovereign contract and can operate without linking to verifiable document contract

Use Cases:

• Enterprise Software Development: Payment released as each development milestone is completed
• Licensing or Procurement: Funds unlocked when contractee verify document and approve delivery of service
• Complex Freelance Projects: Large creative or consulting projects with multi-phase deliverables
• Document-Linked Agreements: Synchronize payments with signed verifiable documents to ensure accountability
• Cross-Border B2B Deals: Ensures high-value payments execute reliably across jurisdictions

Benefits:

• Flexible agreements: Milestone-based, partial payouts, rollback support
• Revocable & secure: Parties retain control, fully enforced on-chain
• Document binding: Legal and audit-ready, linked to verifiable documents
• Cost-efficient: One-time creation fee for long-term security
• Ideal for heavy payments and complex workflows

Layer Benefits Summary

Overall Layer Benefits:

1. Trustless Payments: Reduces risk across all transaction sizes
2. Automation: Smart contracts manage enforcement automatically
3. Flexibility: Supports simple to complex agreements, individual to enterprise
4. Security & Transparency: Immutable, auditable on-chain contracts
5. Cost Efficiency: Cheaper and faster than traditional intermediaries

The Payment & Agreement Layer is the backbone of SafePulse’s ecosystem. Escrow for high-value payments and Pledge Contracts for flexible, milestone-driven agreements provides a secure, automated, and transparent financial infrastructure that empowers individuals, businesses, and enterprises to transact confidently across borders and industries.

Document & Verification Layer

Introduction

The Document & Verification Layer enables secure, tamper-proof, and verifiable document management within the SafePulse ecosystem. It empowers individuals, businesses, and enterprises to create, verify, and timestamp digital documents on-chain, ensuring authenticity, integrity, and enforceability.

This layer is ideal for:

• Legal and compliance documentation
• Intellectual property proof and timestamping
• Smart-contract-linked document verification
• Auditable, verifiable documents for enterprise workflows

All services in this layer leverage on-chain proof mechanisms and decentralized storage to guarantee security, transparency, and user control.

Layer Overview

Key Objectives of the Layer:

• Ensure document authenticity and integrity
• Provide revocable document options
• Offer cost-effective proof of document existence
• Integrate documents seamlessly with smart contract agreements

Services in Document & Verification Layer

1. Verifiable Documents

Purpose: Create secure, tamper-proof, revocable, and blockchain-backed document verification contract, with optional linking to smart contracts for automated enforcement.

Key Features:

• Revocable and contract-linkable documents
• Stored locally or in decentralized storage (IPFS, Arweave, or centralized hosts)
• On-chain proof of authenticity
• Automated On-chain cryptographic verification
• Example deployment: 9 Pulse per document

How It Works:

1. User strore thir document, enter identifier od document and creates a Verifiable Document contract.
2. Document metadata and proof are stored on-chain; content remain off-chain but verifiable.
3. Document can be linked to Pledge Contracts for automated verification and payment syncing.

Use Case Example:

• A company issues a compliance document to a vendor. The document is manageable and verifiable on-chain, and can be used to trigger contract milestones or payment releases.

Benefits:

• Tamper-proof and secure – Blockchain ensures integrity
• Contract integration – Links directly to Pledge Contracts for automated verification and payment syncing
• Revocability – Documents can be revoked by issuers and controllers of contract if needed

Drawbacks:

• Requires management of decentralized storage
• Deployment may incur Pulse token costs

Related Services / Cross-links:

• Pledge Contract: For milestone-based contracts linked to documents and secure payments tied to verified documents

2. Document Registry

Purpose: Provide low-cost, on-chain proof of document existence for timestamping, authorship claims, and IP verification.

Key Features:

• Lightweight and public registry
• Cost-effective solution compared to Verifiable Document contract
• Immutable on-chain cryptographic proof and automated on-chain document verification

How It Works:

1. User store docuemnt and enter document identifier and registers the document.
2. Data will be registered in SafePulse document registry smart contract and will be verifiable and managable.
3. Anyone can verify the document’s existence and authenticity.

Use Case Example:

• An author timestamps a manuscript’s hash to prove authorship. Later, if needed, they can show the timestamped hash to assert intellectual property rights.

Benefits:

• Cost-effective – Minimal on-chain storage fees
• Public verification – Anyone can verify existence and timestamp
• Lightweight – Ideal for frequent document verification
• Immutable proof – On-chain records cannot be tampered with

Drawbacks:

• Does not store full document content
• Limited functionality compared to Verifiable Documents

Layer Benefits Summary

Overall Layer Benefits:

1. Trustworthy Documents – On-chain verification ensures authenticity
2. Contract Integration – Documents can trigger or validate on-chain
3. Cost Efficiency – Public registry reduces overhead for proofs
4. Auditability – Immutable on-chain records support compliance and legal needs
5. Revocability – Documents can be suspended or revoked if necessary

The Document & Verification Layer provides SafePulse users with secure, verifiable, and blockchain-backed document services. By combining Verifiable Documents and a lightweight registry, this layer ensures trust, proof of authenticity, and enforceability, forming a reliable foundation for compliance, legal, and IP workflows.

Identity Layer

Introduction

The Identity Layer in SafePulse provides self-sovereign, blockchain-backed digital identity and credentials. It enables users, businesses, and organizations to verify identity and credentials securely, privately, and without reliance on centralized authorities.

This layer is designed for:

• Individuals: managing personal identity and credentials
• Organizations: verifying employee, partner, or vendor credentials
• Developers: integrating decentralized identity and verifiable credentials into smart contract workflows

All services in this layer are built on open standards to ensure interoperability, privacy, and security.

Layer Overview

Key Objectives of the Layer:

• Provide user-controlled, portable digital identities
• Enable secure verification without centralized intermediaries
• Support verifiable presentations for privacy-preserving data sharing
• Integrate seamlessly with SafePulse’s contracts and document services

Services in Identity Layer

1. Decentralized Identity (DID)

Purpose: Enable lightweight, self-sovereign digital identity that is fully user-controlled, portable, and privacy-preserving.

Key Features:

• Based on ERC-1056 Ethereum standard
• Fully user-controlled – no centralized authority required
• Portable
• Compatible with W3C verifiable credentials v2.0
• Secure and cryptographically verifiable

How It Works:

1. User creates a DID linked to their blockchain wallet.
2. The DID stores essential metadata and public keys/delegates on-chain.
3. Users control access to their identity data through wallet authorization.
4. Can be used for verifying agreements, documents, and interacting with services.

Use Case Example:

• A freelancer registers a DID to authenticate themselves on multiple platforms, providing a verifiable, tamper-proof identity without relying on centralized providers.

Benefits:

• Self-sovereignty – full user control of identity
• Interoperability – compatible with decentralized apps and smart contracts
• compliance – uport integration
• Security – cryptographic proof of identity, self identifying with EOA's

2. Verifiable Credentials (VCs)

Purpose: Provide wallet-first, blockchain-backed digital credentials that are tamper-proof, privacy-preserving, and verifiable.

Key Features:

• Compliant with W3C Verifiable Credentials v2.0
• Blockchain-backed and tamper-proof
• Supports verifiable presentations
• Can represent education certificates, licenses, compliance documents, or professional credentials

How It Works:

1. Credential issuer creates a verifiable credential for a user.
2. Credential metadata and proof are recorded on-chain.
3. User stores credentials in their wallet and selectively shares informations and proofs with third parties.
4. Recipients can verify authenticity without needing direct access to the issuer.

Use Case Example:

• A university issues a blockchain-backed diploma to a graduate. The graduate can present proof to employers without exposing sensitive information, and employers can independently verify its authenticity.

Benefits:

• Trustless Verification – verifiable without a central authority
• Privacy-Preserving Sharing – selective disclosure for sensitive data
• Tamper-Proof – blockchain ensures integrity and immutability

Layer Benefits Summary

Overall Layer Benefits:

1. User-Controlled Identity – Full autonomy over personal or organizational identity.
2. Secure Verification – Blockchain ensures authenticity and prevents tampering.
3. Privacy & Selective Sharing – Share only what is necessary.
4. Integration with SafePulse Services – Identity and credentials can seamlessly interact with payment, document, and content layers.
5. Standardized & Interoperable – Built on ERC-1056 and W3C standards for broad compatibility.

The Identity Layer empowers users with trustworthy, self-sovereign digital identity and credentials, enabling secure, verifiable interactions across SafePulse’s ecosystem. By combining DIDs with verifiable credentials, SafePulse supports privacy-preserving, interoperable, and blockchain-backed identity solutions suitable for individuals, businesses, and developers alike.

Tutorials

• Verifiable Document
• Pledge Contract
• Escrow
• Document Registry
• DID
• Verifiable Credentials
• Asset Paywall

Verifiable Document

Overview

Verifiable Documents allow users to create tamper-proof, document verification contract that let documents be stored locally or on decentralized storage networks, such as IPFS or Arweave. Each document can be anchored on-chain, providing an immutable proof of authenticity. Documents can also be linked to Pledge Contracts, enabling automated enforcement.

All operations are executed via the SafePulse Wallet, ensuring self-sovereign, local execution.

Purpose / Context

Problem: Organizations and individuals often require tamper-proof documents for legal, compliance, or intellectual property purposes. Centralized solutions carry the risk of modification, loss, or lack of verifiability.

Solution: SafePulse’s Verifiable Document service allows users to:

• Anchor documents on-chain for immutability
• Link to Pledge contracts for enforceable workflows
• Maintain full self-sovereign control over document storage and access

This ensures documents are trustworthy, verifiable, and usable in automated payment or contract workflows.

Features

• Decentralized storage options: IPFS, Arweave, or centralized host with direct download
• Revocable documents: Documents can be suspended or revoked if needed
• Linked to Pledge Contracts: Automatically enforceable within
• On-chain anchoring: Ensures tamper-proof on-chain verification of authenticity

Step-by-Step Tutorial

Prerequisites

• SafePulse Wallet installed
• Active EOA (Externally Owned Account) with subscription plan or usage credit
• Issuer/Creator DID: an key DID (did:key) or an ERC-1056 DID with issuer key as its Delegate
• Network tokens (e.g., Pulse) to pay deployment fees

Steps

1. Upload your file to one of:

   • IPFS
   • Arweave
   • Centralized host (direct download link)

2. Tap Verifiable Document

3. Copy the file link/IPFS-CID/Arweave Transaction Id

4. Fill in the creation form:

   • Paste the refrence identifier (file link/IPFS-CID/Arweave Transaction Id)
   • Choose blockchain network

5. Tap Create (top of screen)

6. Confirm the on-chain transaction

7. After minting, go to History

8. Locate the document history record

9. From More, select Initialize and Setup and confirm initialization transaction

10. Share the Verifiable Document DID with relevant parties

Use Cases / Examples

• Education Certificates: Universities issue tamper-proof diplomas verifiable by employers
• Contract Enforcement: Attach documents to a Pledge Contract to enforce milestone payments
• Intellectual Property: Timestamp creative works or research papers to prove authorship
• Legal Agreements: Ensure critical agreements are immutable and verifiable by all parties

Benefits & Drawbacks

Benefits:

• Tamper-proof and auditable
• Integrates with SafePulse contracts for automated enforcement
• Full control over document storage and access

Drawbacks:

• Requires management of decentralized storage
• Deployment may incur Pulse token costs (can be created only by elysium members/elysian accounts)

Related Services / Cross-links

• Pledge Contract: For milestone-based contracts linked to documents/secure payments tied to verified documents

Notes & Tips

• Confirm your document is uploaded correctly before creating a Verifiable Document
• Keep a local backup in addition to decentralized storage
• Always link documents to contracts where verification is required for automated enforcement

Pledge Contract

A hybrid physical–digital contract framework with flexible milestone enforcement, verifiable documents, and on-chain guarantees.

Overview

A Pledge Contract is a decentralized agreement between two parties where all obligations, milestones, and deliverables are digitally anchored. It serves as a self-executed contract where every participant signs with their private key, ensuring integrity, accountability, and traceability without relying on centralized intermediaries.

A Pledge Contract may optionally include:

• Milestones multiple Pledge Contracts can be linked to one document *can use diffrent coins for payments, *using different parties for each payments from parties and controllers at Verifiable Document
• Verifiable Documents for document verifiacation and authentication and document binding
• Auto-updating statuses triggered by contract actions

Context & Problem

The Problem

Traditional contracts lack:

• Automatic enforcement
• Transparency across parties
• Immutable records of milestone progress
• Easy verification of terms or deliverables
• Integrated payment guarantees

They often require third-party mediators, which increases cost, reduces trust, and slows execution.

The Solution

SafePulse’s Pledge Contract provides:

• Immutable, on-chain agreements verified by participants' cryptographic signatures
• Linked deliverables, such as Verifiable Documents
• Flexible Milestone-based workflows for structured work delivery and progressive payments
• Automated status updates to reduce manual coordination

This creates a trustless contracting system suitable for digital commerce, services, creative work, licensing, and more.

Key Features

1. Multi-party Signing

Each participant signs the contract with their private key, ensuring authenticity and non-repudiation.

2. Document Integration

Attach Verifiable Documents as deliverables, guidelines, licenses, terms, or specifications.

3. Milestone Enforcement

Be used as Flexible milestones for progressive payments.

4. Multiple Payments on One Document

One Verifiable Document can be used for multiple Pledge Contracts, with diffrent parties and multiple payment process.

5. Full Status Lifecycle

Automatically transitions through states such as:

• Pending
• Active
• Executed
• Disputed
• Completed
• Canceled

6. Wallet-First Operation

Everything is controlled in the SafePulse Wallet — no external software required.

Step-by-Step Tutorial

Prerequisites

• SafePulse Wallet installed
• Active subscription or usage credits
• Issuer/Creator DID: an key DID (did:key) or an ERC-1056 DID with issuer key as its Delegate
• Network tokens for contract deployment
• A Verifiable Document for document-bound payments

A. Creating a Pledge Contract

1. Tap Pledge Contract

2. Fill in contract details:

   • Seller/Contarctor/Issuer DID
   • Contractee/buyer address
   • Network and Token
   • Enter Verifiable Document Contract DID (optional)

3. Tap Create and Approve transaction

4. After minting, go to History

5. Locate the document history record

6. From More, select Initialize and Setup and confirm initialization transaction

Notes:

• oposite the Escrow, Pledge Contract should be created by seller and its DID should be shared with parties, whole process will be done on pledge contracts.
• Important Note: before initialization contract controller stays empty so INITIALIZE CONTRACT QUICKLY AFTER DEPLOYMENT

B. Share Contarct DID with parties

1. Go to History
2. Find Issue record related to your contract
3. On More tap on "Show Transaction Info"
4. Copy DID

Pledge Contract Status Guide

Pledge Contract Status Guide

1. pending

Meaning: Service is initialized but not started yet.

• Entered by: Default state.

• Who can act: Seller (issuer).

• Transitions to:

  • active → seller starts service
  • canceled → seller cancels before starting

• Permissions:

  • ✅ Rollback → buyer
  • ✅ Cancel → seller
  • 🚫 Withdraw

2. active

Meaning: Service has started and is ongoing.

• Entered by: Seller starts service.

• Who can act: Seller (execute), Buyer (dispute).

• Transitions to:

  • executed → seller executes service
  • disputed → buyer disputes service

• Permissions:

  • 🚫 Rollback (unless expired)
  • 🚫 Cancel
  • 🚫 Withdraw

3. executed

Meaning: Seller marked service as delivered.

• Entered by: Seller executes service.

• Who can act:

  • Buyer → confirm (completed)
  • Buyer → dispute (disputed)
  • Seller → withdraw after 5 days post-expiration (if no dispute)

• Transitions to:

  • completed → buyer confirms delivery
  • disputed → buyer disputes service

• Permissions:

  • 🚫 Rollback
  • ✅ Withdraw (after 5 days if no dispute)
  • 🚫 Cancel

4. disputed

Meaning: Buyer raised a dispute.

• Entered by: Buyer disputes service.

• Who can act:

  • Buyer → complete it
  • Seller → cancel it

• Transitions to:

  • completed → by buyer
  • canceled → by seller

• Permissions:

  • 🚫 Rollback
  • 🚫 Withdraw
  • 🚫 Cancel

5. completed

Meaning: Buyer confirmed delivery and acceptance.

• Entered by: Buyer completes service.

• Who can act: Seller → withdraw.

• Permissions:

  • ✅ Withdraw (seller)
  • 🚫 Rollback
  • 🚫 Dispute
  • 🚫 Cancel

6. canceled

Meaning: Seller canceled service before completion.

• Entered by: Seller cancels.

• Who can act: Buyer → rollback.

• Permissions:

  • ✅ Rollback (buyer)
  • 🚫 Withdraw
  • 🚫 Execute/Complete

📌 Notes

• Dispute only possible from active or executed.

• Rollback allowed only when:

  • State is not active, or expired
  • State is not executed, completed, or disputed

• Withdraw allowed only when:

  • State is completed, or
  • State is executed and 5 days passed with no dispute

• No transitions allowed from completed, disputed, or canceled unless manual.

• 🔐 Funds are locked until customer approves completion.

📎 Linked Document Rules

If linked to a Verifiable Document:

• For executed → seller must sign on-chain in the Document Contract.
• For completed → buyer must sign on-chain in the Document Contract.
• For canceled → Document Contract must be in suspended or revoked status.

Real-World Use Cases

1. Freelance or Service Agreements

• Designer and client define milestones
• Verifiable Document details requirements
• Client deposits funds in escrow
• Each milestone is approved before payment is released

2. Licensing & Intellectual Property

• A creator issues rights via a Verifiable Document
• Licensee accepts terms through contract signing
• Usage rights become provable on-chain

3. B2B Supplier Agreements

• Milestones tied to shipment or delivery phases
• Locks funds and payments till conditions met
• Each step verified for transparency

Benefits & Drawbacks

Benefits

• Proven authenticity through cryptographic signatures
• Protects both parties via escrow-secured terms
• Transparent progress tracking
• Immutable record of obligations and deliverables
• Zero reliance on centralized intermediaries

Drawbacks

• Requires users to understand decentralized storage
• On-chain actions incur gas fees
• All parties must use SafePulse Wallet for consistency

Related Services

• Verifiable Documents — attach deliverables, terms, proofs, secure payment workflows linked to contract milestones,timestamp documents referenced by contract

Tips & Best Practices

• Always attach a Verifiable Document describing scope and expectations
• Break work into seperated milestones contracts with required tokens to reduce disputes
• Use escrow for high-value or high-risk agreements
• Keep communication in-app to maintain transparency

Escrow

A trustless, non-custodial payment safeguard for peer-to-peer and high-value transactions.

Overview

SafePulse Escrow is a trustless, non-custodial onchain escrow service that securely locks funds until both parties meet agreed-upon conditions. Designed for buyers, sellers, freelancers, enterprises, and service providers where trust and protection are critical.

With transparent fees and guaranteed neutrality, SafePulse Escrow eliminates fraud risks and intermediaries — delivering a secure, automated environment for global payments of any size.

Context & Problem

The Problem

Digital agreements — whether between individuals or businesses — frequently face:

• Payment fraud
• Delivery disputes
• Chargebacks
• Unenforceable promises
• Lack of trusted middlemen
• High cost of middlemen
• No protection for large-value deals
• Opaque transaction processes

Centralized escrow alternatives exist, but they introduce:

• High fees (often 2–10%+)
• Custodial risk (fund freezing, loss, shutdowns)
• Slow and costy dispute resolution
• Geographic restrictions
• Risk of platform censorship

For large-value or cross-border transactions, these risks become even more severe.

The Solution

SafePulse Escrow replaces intermediaries with automation, transparency, and cryptography:

• Smart contracts hold funds securely
• Neither SafePulse nor any third party can access funds
• Status is always transparent to both parties
• Options for rollback, cancellation, and freeze under safe conditions and only by parties

This makes it suitable for everything from small digital engagements to high-value deals.

Use Cases

1. High-Value Transactions

Manufacturing orders, consulting retainers, licensing fees

• Securely holds large sums
• Prevents fraud or late delivery

2. Freelance / Gig Work

Design, development, marketing, writing, auditing

• Client deposits funds in escrow
• Freelancer completes work
• Payment released on approval

3. P2P Item Purchases

High-value goods, collectibles, hardware, digital assets

• Buyer locks payment
• Seller delivers
• Buyer verifies and releases

4. Deposits, Rentals, Prepayments

Real estate, equipment rentals, agency pre-bookings

• Supports refundable deposits
• Automatically rolls back if conditions fail

5. Content & Digital Sales

• Protects both sellers and buyers

Key Features

1. Trustless, Non-Custodial Fund Holding

Funds are locked in smart contracts — not controlled by SafePulse or any third party.

2. Safe for High-Value Transactions

Smart contracts guarantee:

• No third-party access
• No interference
• No misappropriation

3. Revocable, Time-Bound, and Rollback Support

Automated safety mechanisms for any agreement size.

4. Simple Fee Structure

• Flat deposit fee (pays in network native token)
• 1% withdrawal fee
• No subscriptions or access token required

Cheaper and safer than centralized escrow — even for high-value deals.

5. Complete Status Transparency

Escrow lifecycle:

• Open
• Freeze
• Release
• Cancel

Every party always knows the exact state.

6. Wallet-First, On-Device Execution

All actions happen through the SafePulse Wallet — intuitive, secure, and verifiable.

Escrow Lifecycle (Status Guide)

Step-by-Step Tutorial

Prerequisites

• SafePulse Wallet installed
• Gas tokens available
• Payment token approved for use

A. Approving Tokens for Escrow

1. Open the escrow record
2. Tap Approve Token
3. Confirm the transaction

Once approved, the deposit can be made.

B. Creating an Escrow Deposit

1. At organize section onder title of escrow Tap Approve

2. Enter:

   • Recipient address
   • Amount
   • expiration date

3. Select network and token

4. Tap Deposit

5. Escrow appears in History

6. Share Deposit DID with your party

C. Releasing or Canceling

Release

Used when obligations are met:

• Work delivered
• Product received
• Agreement fulfilled

User taps Release → Confirm.

Cancel

Used when:

• Conditions fail
• Deadlines pass
• Mutual cancellation occurs

Funds are returned to the sender.

Escrow Contract Status Guide

1. open

Meaning: Funds deposited, escrow active.

• 🚫 Withdraw
• ✅ Rollback → allowed 5 days after expiration

2. freeze

Meaning: Escrow blocked.

• 🚫 Withdraw
• 🚫 Rollback

3. release

Meaning: Escrow released to seller.

• ✅ Withdraw (seller)
• 🚫 Rollback

4. cancel

Meaning: Escrow canceled.

• 🚫 Withdraw
• ✅ Rollback (buyer)

Real-World Examples

1. High-Value Contract Payment

$50,000 locked → Developer delivers → Company verifies → Funds released.

2. Hardware Purchase

Buyer deposits → Seller ships → Buyer confirms → Funds released.

3. Security Deposit

Tenant deposits → No issues → Deposit returned upon cancellation.

Benefits

• Safe for high-value and cross-border payments
• Non-custodial and censorship-resistant
• Transparent and automated lifecycle
• Eliminates fraud and trust issues
• Simple and predictable costs
• Integrates with Pledge Contracts and Paywalls

Drawbacks

• Requires blockchain familiarity
• Both parties must manage wallets
• No centralized party can force a resolution

Document Registry

A lightweight, low-cost, onchain proof-of-existence system for timestamping documents, research, IP, and digital work.

Overview

The Document Registry provides a fast, cost-efficient and immutable method to prove that a document existed at a specific point in time. Instead of storing the full file onchain, SafePulse only records the hash, making the process cost-efficient while maintaining strong cryptographic guarantees.

This service is ideal for protecting intellectual property, research, legal documents, design drafts, code, and any other material where authorship and existence must be provably timestamped.

A trustless, permanent anchor for any file that need to be verified.

Context & Problem

The Problem

Traditional document notarization methods suffer from:

• High costs for official notary services
• Slow processing
• Geographic limitations
• Risk of altered or missing records
• Dependence on centralized institutions

Organizations and creators need a way to prove authorship, establish priority, and timestamp content without revealing the full document or relying on third parties.

The Solution

SafePulse Document Registry creates an immutable onchain proof that a specific document, identified by its hash, existed at a given moment. This proof is:

• Cryptographically verifiable
• Public or private document identifier
• Permanent and censorship-resistant
• Quick and inexpensive

This allows creators, researchers, and businesses to validate authorship or existence whenever needed.

Use Cases

1. Intellectual Property Protection

• Artists timestamp digital artwork
• Writers record novel drafts
• Developers anchor new code or smart contracts
• Designers secure product sketches

2. Research & Innovation

• Recording first publication dates
• Protecting proprietary formulas
• Proving original authorship of research papers
• Documenting experiments or iterations

3. Legal and Compliance

• Timestamping agreements before signature
• Anchoring evidence documents
• Recording immutable audit logs

4. Enterprise Workflows

• Documenting internal policies
• Securing confidential revisions off-chain
• Establishing chain-of-custody events

Key Features

1. Fast and Low-Cost

Designed as a lightweight alternative to Verifiable Documents.

2. Non-custodial Data management

File stays off-chain by user/issuer, we verify.

3. Immutable and Permanent

Records cannot be deleted or modified, ensuring trustworthiness.

4. Flexible Storage Options

Users can store files:

• Locally
• IPFS
• Arweave
• Any private or centralized host

5. No Initialization Required

Unlike Verifiable Documents, the record exists immediately after registration.

Step-by-Step Tutorial

Prerequisites

• SafePulse Wallet installed
• Native token balance for registration fees
• Issuer/Creator DID: an key DID (did:key) or an ERC-1056 DID with issuer key as its Delegate
• File prepared and hashed automatically by the app

A. Registering a Document

1. Upload your file to one of:

   • IPFS
   • Arweave
   • Centralized host (direct download link)

2. Tap Document Registry

3. Copy the file link/IPFS-CID/Arweave Transaction Id

4. Fill in the creation form:

   • Paste the refrence identifier (file link/IPFS-CID/Arweave Transaction Id)
   • Choose blockchain network

5. Tap Register (top of screen)

6. Confirm the on-chain transaction

7. After minting, go to History

8. Locate the document history record

9. Share the Verifiable Document DID with relevant parties

Real-World Examples

Example 1: Protecting Creative Work

A designer registers a new product sketch. Months later, if questioned about authorship, the onchain timestamp validates they created it first.

Example 2: Academic Research Timestamp

A scientist anchors early drafts of a paper before journal submission, proving that research was conducted earlier than similar publications.

Example 3: Internal Company Evidence

A compliance officer anchors a log of policy updates to prove the timeline of organizational changes.

Benefits

• Extremely low-cost proof registration
• Works instantly with minimal user steps
• Does not expose or upload the actual file
• Immutable and verifiable forever
• Provides strong authorship protection
• No dependency on centralized notaries

Drawbacks

• Does not support revocation
• Does not support multiple controller
• Cannot attach signatures
• Cannot filter/limit verifiers

For these advanced features, Verifiable Documents are recommended.

Best Practices

• Save the original file securely — the hash depends on exact content
• Use decentralized storage (IPFS/Arweave) for long-term preservation
• Register drafts and versions frequently if working iteratively
• Combine registry entries with Pledge Contracts for deliverable verification
• For legal agreements, convert to Verifiable Documents if signatures are needed

DID

A self-sovereign, portable, Ethereum-based identity standard for secure, user-controlled interaction across SafePulse services.

Overview

SafePulse’s Decentralized Identity (DID) system is built on the ERC-1056 identity standard, allowing users to create a self-sovereign digital identity that is:

• User-controlled (no central authority)
• Portable across services and networks
• Privacy-preserving, with no forced disclosure
• Compatible with Verifiable Credentials and onchain contracts

A DID is the foundational element powering all advanced workflows in SafePulse, including:

• Verifiable Credentials
• Document verification
• Pledge Contract authorization
• Escrow interactions
• Asset Paywall access

Your DID enables you to prove who you are cryptographically, without giving up personal data, documents, or reliance on centralized identity providers.

Context & Problem

The Problem

Most modern digital identity systems suffer from:

• Centralized control (Google, Apple, government IDs)
• Limited portability across platforms
• High privacy exposure
• Risk of surveillance or data misuse
• Fragmented identity silos

Users need a secure identity they can use across agreements, documents, services, and contracts without depending on third parties.

The Solution

SafePulse implements ERC-1056 Decentralized Identity, giving users:

• A cryptographic identity bound to their wallet
• A globally resolvable DID Document
• Self-sovereign control of keys
• Maximum privacy with minimum data sharing
• Full integration with the onchain ecosystem

Your DID becomes your trust anchor across all services.

Key Features

1. Self-Sovereign Control

You create your identity locally on your device. No admin, no provider, no central manager.

2. Portable & Cross-Platform

Your DID can be used across multiple networks, dapps, and verification systems.

3. Privacy-First

DIDs do not require linking to names, emails, or personal data.

4. Verifiable & Tamper-Proof

Each DID has an onchain DID Document describing:

• Public keys
• Verification methods
• Authentication methods
• Delegates (optional)

5. Works With Verifiable Credentials

Your DID can issue, verify, and receive:

• Certificates
• Licenses
• Compliance proofs
• Identity attestations

6. Required for Self Identification

Issuers need to identify themselves by DID (Public Key DID or ERC-1056)

Use Cases

1. Freelance Work & Payments

A freelancer uses a DID to identify themselves in a Pledge Contract — no email or passport needed.

2. Enterprise Compliance

Companies issue DID-backed credentials to employees, proving compliance or training certifications.

3. Education & Certification

Schools issue DID-bound certificates that can be verified anywhere.

4. Secure Document Management

Documents are signed using the DID’s verification keys.

5. Content Distribution

Asset Paywall access can be tied to a user’s DID, proving rights and preventing unauthorized sharing.

Step-by-Step Tutorial

A. Creating Your DID

1. Open the SafePulse Wallet
2. Navigate to Identifiers
3. Tap Create DID and choose DID type (Public Key DID or ERC-1056)
4. The wallet generates DID string as decentralized identifier of EOA as user identifier
5. Confirm transaction
6. Your DID is now active and visible under Identifiers

B. Managing Your DID

Inside the DID details page, you can:

• View DID Document
• View delegates
• Add/Remove delegates (optional)
• Rotate keys for security
• Export DID metadata

All sensitive operations stay local on your device unless explicitly broadcast onchain.

SafePulse applies the ERC-1056 standard, ensuring maximum interoperability.

Real-World Examples

Example 1 — Talent Marketplace

A freelancer uses their DID to authenticate in a contract without revealing personal identity. The buyer verifies the DID and contract execution onchain.

Example 2 — Employee ID System

A company issues VCs tied to employee DIDs. Employees prove qualifications without exposing private data.

Example 3 — Anonymous Research Publication

A researcher anchors findings under a pseudonymous DID, later proving authorship without revealing identity at submission time.

Benefits

• Fully decentralized identity
• No personal data exposure
• Secure and key-controlled
• Interoperable with global standards
• Works seamlessly across SafePulse services
• Ideal for anonymous or pseudonymous workflows

Drawbacks

• User is responsible for securing private keys
• Identity recovery requires proper key backups
• Cross-network DID document updates require gas fees

Verifiable Credentials

Wallet-first, privacy-preserving credentials compliant with W3C VC v2.0 and anchored to SafePulse DIDs.

Overview

SafePulse’s Verifiable Credentials (VCs) provide a secure, decentralized way to issue, verify, and present proofs of:

• Skills & achievements
• Education & training
• Compliance & licenses
• Membership & identity attributes
• Business records or attestations

VCs are:

• Tamper-proof (cryptographically verifiable)
• Self-sovereign (stored in the user’s wallet)
• Portable across networks and platforms
• Privacy-preserving via selective disclosure & verifiable presentations
• Built on W3C Verifiable Credential v2.0

A VC is signed by the issuer’s DID, held by the subject’s wallet, and verifiable by any third party.

Context & Problem

The Problem

Traditional credentials (certificates, licenses, IDs) have challenges:

• Easy to forge or manipulate
• Hard to verify internationally
• Require centralized authorities
• Reveal too much personal data
• Slow manual verification processes
• Not portable across platforms

Users and organizations need trusted, private, standardized digital credentials that work anywhere.

The Solution

SafePulse VCs:

• Are verified via blockchain + DID signatures
• Require no central authority
• Support selective disclosure (only reveal what’s necessary)
• Allow flexible proof presentations
• Can represent any type of claim — academic, corporate, legal, or personal

VCs integrate deeply with SafePulse’s identity and document ecosystem, powering secure B2B and P2P verification workflows.

Use Cases

1. Education & Certification

• Schools issue degrees or certificates as VCs
• Training centers issue completion badges
• Students share credentials without revealing full identity

2. Enterprise Compliance

• Employees receive compliance certifications (e.g., AML/KYC training)
• Contractors prove qualifications before engagement
• Auditors verify digital proof instantly

3. Talent & Freelancing

• Freelancers present verified work history or skill credentials
• Clients validate identity attributes without exposing personal details

4. Legal & Regulatory

• Businesses issue licenses or compliance documents
• Individuals prove age or residency using selective disclosure
• Lawyers validate document issuance via VCs

5. Web3 & Onchain Reputation

• Proof-of-contribution credentials
• DAO participation records
• Reputation scoring anchored to DID

Key Features

1. W3C VC v2.0 Compliant

Ensures global compatibility with web3 wallets, institutions, and verifiers.

2. Self-Sovereign Storage

Credentials stay in the payer’s device — no platform custody.

3. Selective Disclosure

Users reveal only the needed fields to a verifier.

4. DID-Based Signing

Both issuer and holder use their Decentralized Identity (DID).

5. Blockchain Anchoring

Credential hashes or metadata can be anchored onchain for immutability.

6. Revocation Support

Issuers can revoke credentials using their DID keys (if issued with revocation registry).

Credential Structure (Simplified Example)

{
  "@context": ["https://www.w3.org/2018/credentials/v2"],
  "type": ["VerifiableCredential", "EducationCertificate"],
  "issuer": "did:ethr:0xABC...",
  "credentialSubject": {
    "id": "did:ethr:0x123...",
    "name": "John Doe",
    "course": "Blockchain Development"
  },
  "proof": {
    "type": "EcdsaSecp256k1Signature",
    "created": "2025-01-01T00:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:ethr:0xABC#owner",
    "signatureValue": "0x..."
  }
}

Step-by-Step Tutorial

A. Receiving a Credential

1. Open the SafePulse Wallet

2. Navigate to Identity → Credentials

3. Tap Receive VC

4. Scan QR code / paste credential payload

5. Wallet verifies:

   • Issuer DID
   • Signature
   • Expiration & revocation (if applicable)

6. Accept and store the VC locally

Your VC is now available for presentations or sharing.

B. Issuing a Credential

Prerequisites

• Your DID must be initialized
• You must have issuer permissions in your workflow
• (Optional) Verifiable Document to attach additional files

Steps

1. Navigate to Issue Credential

2. Fill in the credential fields:

   • Type (certificate, membership, license…)
   • Subject DID
   • Data fields

3. (Optional) Attach Verifiable Document

4. Tap Issue

5. Wallet signs VC using issuer’s DID

6. Share VC with subject via:

   • QR Code
   • Direct import
   • Encrypted message

C. Presenting a Credential (“Verifiable Presentation”)

A presentation allows the holder to share only the required parts of the credential.

1. Open the credential

2. Tap Present

3. Select fields to reveal

4. Wallet generates:

   • A zero-knowledge / selective disclosure proof
   • Holder’s DID authentication

5. Share the presentation with verifier

This preserves maximum privacy.

D. Revoking a Credential (Optional)

1. Open Issued Credentials
2. Select credential
3. Tap Revoke
4. Confirm DID-signed revocation

Verifiers will see the credential as revoked in future checks.

Real-World Examples

Example 1 — Digital Degree

A university issues VCs instead of PDFs. Employers verify authenticity instantly without contacting the school.

Example 2 — Driver License Check

User presents only “Over 18” instead of full identity details. Selective disclosure protects privacy.

Example 3 — Corporate Compliance

An employee presents a “Certified AML Officer” credential to a financial institution. The institution verifies:

• DID of employee
• DID of the issuing company
• Integrity of the credential

Example 4 — DAO Reputation

A DAO issues contribution-based VCs to members. Tools read VC reputation to grant roles or voting rights.

Benefits

• Trustless, verifiable credentials
• Self-sovereign, not platform-controlled
• Portable across apps, companies, and chains
• Supports privacy and selective disclosure
• Compatible with global W3C standards
• Works seamlessly with DID and Document Contracts

Drawbacks

• Users must safeguard wallet and credentials
• Revocation requires issuer DID control
• Some platforms still rely on centralized credential formats

Best Practices

For Issuers

• Use stable, persistent DIDs
• Anchor revocation lists onchain
• Avoid including unnecessary personal data
• Use credential types aligned with global schemas (e.g., W3C)

For Holders

• Make secure encrypted backups of credentials
• Use selective disclosure whenever possible
• Keep DID keys rotated and secure

For Verifiers

• Always check DID signature and timestamp
• Verify revocation status
• Use VC-compliant parsers for best interoperability

Asset Paywall

Decentralized content monetization with onchain access control, multi-payment support, and DID-authenticated delivery.

Overview

The Asset Paywall service allows creators, businesses, and developers to register an digital content delivery contract. It is designed to support:

• Digital content sales (media, PDFs, files, videos, audio, images)
• Knowledge & research monetization
• Premium memberships
• One-time or tiered access models
• Onchain payment validation
• DID-authenticated access

The Asset Paywall integrates deeply with the SafePulse ecosystem, using:

• DIDs for identity/authorship

It works fully wallet-first, ensuring users retain local control while publishers remain sovereign owners of their content. Issuers wont share ownership, they register an content delivery contract, customers approve the contract by payment and receive content identifier.

Context & Problem

The Problem

Most content monetization platforms:

• Require central hosting
• Control creator accounts
• Can censor, block, or shadowban
• Offer weak content protection
• Depend on fragile credential-based logins

Creators need trustless payment and ownership without relying on intermediaries.

The Solution

SafePulse’s Asset Paywall:

• Uses smart-contract payments
• Deliver content identifier after payment
• Stores protected assets via decentralized links or secure URLs
• Uses DID, not centralized accounts
• Runs entirely from the user's wallet (no platform custody)

Key Features

💸 1. Multi-Asset Payments

Publishers can charge:

• Stablecoins
• Other chain-native assets (where supported)

🎫 2. Flexible Access Models

• One-time purchase means approve contract

📍 3. Onchain Proof of Purchase

Proofs are stored as lightweight logs and anchored to the buyer’s DID.

Use Cases

1. Content Creators & Educators

• Paid course videos
• Premium guides and PDFs
• Photography, digital art, designs
• Locked newsletters or research papers

3. Media & Journalism

• Pay-per-article
• Premium investigations
• Subscriber-only content

4. Businesses & Enterprises

• Shared documents
• Monetized research reports

Step-by-Step Tutorial

A. Creating a Paywalled Asset

• Upload or host file on an centralized or decentralized storage

1. Open the wallet

2. Tap Asset Paywall

3. Choose the asset type

4. Choose your payment configuration

   • Issuer DID
   • Network and token
   • Price
   • Asset Name

5. Confirm onchain deployment

6. Asset Paywall contract is deployed

7. Share the asset DID

B. User Purchasing Access

1. Open wallet
2. Scan Paywall QR or paste DID
3. View content preview + price
4. Tap Purchase
5. Wallet executes payment contract
6. On success, wallet receives access token bound to DID
7. Content unlocks automatically

C. Managing Asset

At Contract organization there is options for freeze/unfreeze asset, collect payments or delete asset.

Real-World Examples

Example 1 — Paid PDF Guide

A researcher sells a 200-page PDF on IPFS via paywall. After paying, users get a DID-bound decryption key.

Example 2 — Video Course

Teacher uploads course videos behind a paywall with 30-day access.

Example 3 — Premium Article

A journalist publishes a pay-per-article story with a one-time purchase.

Example 4 — Photography Pack

A designer distributes a set of high-resolution files, protected by the paywall.

Benefits

For Creators

• 1% platform fees
• No censorship
• Automated payments
• Privacy first, no KYC

For Users

• No centralized accounts
• Portable access
• Verifiable proof of purchase
• Zero-knowledge access control

For Businesses

• Internal distribution
• Contract-based licensing
• Easy integration

Drawbacks / Considerations

• Requires gas fees on deployment
• Content hosting costs depend on storage provider
• Price changes may require redeployment (contract-defined)
• Users must protect local wallet keys for access retention

Best Practices

• Always encrypt sensitive files before uploading
• Offer low-cost preview content to improve user trust

Troubleshooting

• Asset Paywall
• Escrow
• Document Registry

Asset Registry Troubleshooting Guide

This section covers common errors and issues specific to the Asset Registry functionality.

Common Asset Registry Errors

Insufficient Pulse Balance

Description: Account lacks the required ELYPS token balance for asset registration.
Error Message: actor account is not an ELYPS holder (at least 1ELYPS required to register an asset)
Reason: The actor's account does not hold the minimum required 1 ELYPS token in their Pulse balance.

Solution:

1. Check your current ELYPS token balance
2. Acquire at least 1 ELYPS token before attempting asset registration
3. Ensure the tokens are in the correct wallet/account

Prevention:

• Verify your ELYPS balance before initiating asset registration
• Maintain a minimum balance to cover multiple registrations

Invalid Reference Link

Description: The provided asset reference link is inaccessible or invalid.
Error Message: Entered IPFS/arweave/web link reference is not available
Reasons:

• The reference link does not exist
• The link is not reachable (connection issues)
• Web links: Storage provider does not support CORS
• IPFS links: The CID does not exist for IPFS-deployed assets
• Arweave links: The TX-ID does not exist or the asset is not minted yet

Solution:

1. Verify link accessibility: Test the link in a browser
2. IPFS assets: Confirm the CID exists and is pinned
3. Arweave assets: Verify the TX-ID exists and the asset is minted
4. Web links: Ensure CORS is enabled on the storage provider
5. Check network connectivity: Ensure your connection can reach the storage network

Prevention:

• Test all links before submission
• Use reliable storage providers with CORS support
• Confirm deployment before registration

Asset Not Found

Description: Attempting to access a non-existent or unregistered asset.
Error Message: no registered asset or wrong asset did
Reasons:

• Asset does not exist
• Asset is not registered in the system
• Asset was reported and removed from the database
• Incorrect asset DID (Decentralized Identifier) provided

Solution:

1. Verify the asset DID is correct
2. Check if the asset was previously registered
3. Contact support if the asset was reported and needs review
4. Attempt to search for the asset using alternative identifiers

Prevention:

• Copy asset DIDs accurately
• Keep records of registered asset DIDs
• Monitor asset status regularly

Asset Frozen - General

Description: Asset operations are blocked due to frozen status.
Error Message: 'Asset frozen already'
Reason: The asset has been frozen by its owner and cannot undergo certain operations.

Solution:

1. For asset owners: Unfreeze the asset through the owner control panel
2. For other users: Contact the asset owner to request unfreezing
3. Wait for the asset owner to change the asset status

Prevention:

• Asset owners: Document freezing/unfreezing procedures
• Users: Check asset status before attempting operations

Asset Frozen - Withdrawal Restriction

Description: Cannot withdraw funds from a frozen asset.
Error Message: 'Asset frozen already' on withdraw
Reason: Frozen assets have restricted financial operations, including fund withdrawals.

Solution:

1. Asset owner must: Unfreeze the asset through owner controls
2. After unfreezing: Proceed with withdrawal as normal
3. Do not attempt withdrawal until asset status changes to unfrozen

Prevention:

• Complete all withdrawals before freezing assets
• Maintain clear asset status documentation
• Plan financial operations around asset status changes

Insufficient Allowance for Purchase

Description: Stablecoin purchase approval is insufficient for asset purchase.
Error Message: 'Not enough allowance, increase allowance for purchase'
Reason: Asset purchases using stablecoins require pre-approval (allowance) from the buyer. The current allowance is insufficient for the purchase amount.

Solution:

1. Check current allowance: View your approved stablecoin amount
2. Increase allowance: Approve a higher amount through your wallet
   • Connect your wallet
   • Navigate to token approvals
   • Increase allowance for the stablecoin used in purchases
3. Retry purchase: After allowance update, attempt purchase again

Prevention:

• Set higher allowances for frequent purchases
• Check allowance before initiating purchases
• Use wallet features to manage token approvals efficiently

Quick Reference Table

Support Contact

If issues persist after following these steps, contact support with:

• Error message
• Asset DID (if applicable)
• Transaction hash
• Steps already attempted

Escrow Troubleshooting Guide

This section covers common errors and issues specific to the Escrow functionality.

Common Escrow Errors

Insufficient Balance

Description: Account lacks sufficient funds for escrow operations.
Error Message: 'insufficient balance'
Reasons:

• Actor/depositor/user account does not have enough network native token to cover deposit fees
• Account does not have enough balance to cover the escrow deposit amount

Solution:

1. Check native token balance: Verify you have enough network native token for gas/deposit fees
2. Check deposit amount: Ensure your account has sufficient funds for the full escrow amount
3. Top up if needed: Add more native tokens for fees and/or deposit funds to your account
4. Adjust deposit amount: Consider reducing the escrow amount if balance is insufficient

Prevention:

• Monitor account balances regularly
• Keep reserve funds for transaction fees
• Calculate total required amount (deposit + fees) before initiating

Insufficient Token Allowance

Description: Stablecoin transfer permission is insufficient for escrow deposit.
Error Message: 'insufficient token allowance'
Reason: User is attempting to deposit stablecoin into escrow but hasn't granted the escrow contract permission to transfer the specified amount. The allowance must be set before deposit.

Solution:

1. Connect wallet: Ensure your wallet is connected to the platform
2. Approve token transfer: Navigate to token approvals in your wallet
3. Set allowance: Grant the escrow contract permission to transfer the desired stablecoin amount
4. Retry deposit: After approval is confirmed, attempt the escrow deposit again
5. Note: Some wallets require separate approval and deposit transactions

Prevention:

• Set generous allowances for frequent escrow users
• Complete token approvals before initiating deposits
• Use wallet features to manage and track token approvals

Deposit Duration Exceeded

Description: Attempting to set an escrow duration beyond allowed limits.
Error Message: 'Deposit duration can not be more than 93 days'
Reason: The system enforces a maximum escrow duration limit of 93 days for all deposits.

Solution:

1. Review duration: Check your specified deposit duration
2. Reduce duration: Adjust the duration to 93 days or less
3. Consider alternatives: For longer-term arrangements, use multiple shorter escrows or explore other options
4. Retry with corrected duration: Submit the deposit with the adjusted timeframe

Prevention:

• Always verify duration limits before setting escrow terms
• Plan escrow periods within the 93-day limit
• Document longer-term agreements separately

Deposit Transaction Failed

Description: Escrow deposit transaction did not process successfully.
Error Message: 'Deposit failed: transaction didnt sent'
Reason: The transaction was not successfully sent to the network or failed during processing.

Solution:

1. Check network connection: Ensure stable internet and blockchain network access
2. Verify wallet status: Confirm wallet is properly connected and unlocked
3. Review gas fees: Ensure sufficient funds for gas/transaction fees
4. Check for pending transactions: Clear or cancel any stuck transactions
5. Retry transaction: Attempt the deposit again
6. Contact support if persistent: If failures continue, provide transaction hash to support

Prevention:

• Use reliable internet connections
• Monitor network congestion and gas prices
• Keep wallet software updated

Deposit Not Yet Released

Description: Attempting to access funds before release conditions are met.
Error Message: 'Not released yet'
Reasons:

• Deposit escrow status is not yet released by the payer
• 5-day post-expiration period has not yet passed

Solution:

1. Check deposit status: Verify current escrow status and conditions
2. For payees: Wait for payer to release funds or for expiration + 5 days
3. For payers: Release funds if conditions are met
4. Monitor timeline: Track expiration date and post-expiration period
5. After 5 days post-expiration: Funds become accessible to payee

Prevention:

• Set clear release terms upfront
• Monitor escrow timelines
• Communicate with counterparty about release timing

Deposit Frozen Due to Dispute

Description: Escrow funds are locked due to a raised dispute.
Error Message: 'Frozen already'
Reason: Payer has raised a dispute, freezing the deposit. In this state:

• Payer cannot rollback the deposit
• Payee cannot withdraw funds
• Only specific actions are allowed to resolve the dispute

Resolution Paths:

1. Payee can cancel: Allows payer to rollback funds
2. Payer can complete: Allows payee to withdraw funds
3. Wait for resolution: If neither action is taken, funds remain frozen

Solution:

1. Identify dispute reason: Check why dispute was raised
2. Communicate: Discuss resolution with counterparty
3. Choose resolution path:
   • If payee agrees to cancel: Payee cancels → Payer rolls back
   • If payer agrees to release: Payer completes → Payee withdraws
4. Document agreement: Keep records of dispute resolution

Prevention:

• Establish clear terms before escrow
• Maintain open communication
• Document deliverables and expectations

Deposit Already Released

Description: Attempting to perform actions on an already-released escrow.
Error Message: 'Released already'
Reason: The escrow deposit status is already marked as released. No further actions can be performed on released escrows.

Solution:

1. Verify status: Confirm the escrow is indeed released
2. Check transaction history: Look for release transactions
3. For payees: Funds should be available for withdrawal if not already withdrawn
4. For payers: No further action needed; release is complete
5. If erroneous: Contact support with transaction details

Prevention:

• Track escrow status changes
• Set up notifications for status updates
• Document all escrow milestones

Escrow Status Flow Reference

Deposit Created → Active → [Dispute Raised → Frozen] → Released → Completed
                        ↘ [No Dispute] → Released → Completed

Quick Action Guide

Dispute Resolution Matrix

Support Information

When contacting support about escrow issues, provide:

• Escrow contract address
• Deposit transaction hash
• Wallet addresses (payer/payee)
• Error screenshots
• Steps already attempted

Document Registry Troubleshooting Guide

This section covers common errors and issues specific to the Document Registry functionality.

Common Document Registry Errors

Invalid Reference Link

Description: The provided document reference link is inaccessible or invalid.
Error Message: Entered IPFS/arweave/web link reference is not available
Reasons:

• The reference link does not exist
• The link is not reachable (connection issues)
• Web links: Storage provider does not support CORS
• IPFS links: The CID does not exist for IPFS-deployed documents
• Arweave links: The TX-ID does not exist or the document is not minted yet

Solution:

1. Verify link accessibility: Test the link in a browser or network tool
2. IPFS documents: Confirm the CID exists and is pinned to the network
3. Arweave documents: Verify the TX-ID exists and the document is fully minted
4. Web links: Ensure the storage provider supports CORS
5. Check network access: Confirm your connection can reach the storage network
6. Re-upload if necessary: Upload the document to a reliable storage provider

Prevention:

• Test all storage links before registration
• Use decentralized storage with high availability (IPFS/Arweave)
• For web links, verify CORS support with the provider
• Confirm deployment completion before registration

Document Loading Failed

Description: Unable to load or verify a registered document.
Error Message: Document loading failed: no registered document or wrong document did
Causes:

1. Resource errors: Link decryption, proof claims, or data resolution failures
2. Broken user data: Users editing or removing information from their registered document DID
3. Changed files: Users modifying the original file after registration (common with web links)
4. Missing key information: Critical data removed from the document DID

Solution:

1. Verify DID completeness: Check that the document DID contains all required fields
2. Check file integrity: Ensure the original file hasn't been modified
3. Re-register if needed: If the file was changed, register a new document
4. Contact issuer: For third-party documents, request a re-issue
5. For web links: Verify the linked file matches the originally registered version

Prevention:

• Never modify files after registration
• Store immutable copies on IPFS or Arweave
• Keep backup of original document DIDs
• Use version control for document updates

Document Status Change Permissions

Description: Unauthorized attempt to change document status.
Error Messages: Only issuer can revoke/validate/suspend document
Reason: Only the original issuer of a document has permission to change its status (revoke, validate, or suspend). These are three separate but related permission errors.

Solution:

1. Identify the issuer: Determine who originally issued the document
2. Contact issuer: Request the status change from the authorized party
3. Provide justification: Explain why the status change is needed
4. Wait for action: Allow the issuer to perform the status change
5. For self-issued documents: Ensure you're using the correct issuer account/wallet

Prevention:

• Document issuer relationships clearly
• Establish status change protocols with issuers
• Maintain contact information for document issuers
• Consider multi-signature setups for important documents

Unsupported Reference DID Method

Description: Document reference deciphering process fails.
Error Message: unsupported reference DID method
Reason: The cipher key in the document DID has been altered by users, breaking the deciphering process and preventing correct plain data resolution.

Solution:

1. Do not modify DIDs: Document DIDs should never be manually edited
2. Use original DID: Retrieve the original, unmodified document DID
3. Re-register: If the DID was altered, register a new document
4. Check generation tools: Ensure DID generation tools are functioning correctly
5. Contact support: If the error appears without user modification

Prevention:

• Never manually edit or alter document DIDs
• Use official DID generation tools
• Store DIDs in secure, unmodifiable formats
• Implement checksums for DID validation

Invalid DID Delegate

Description: Actor lacks proper delegation permissions.
Error Message: Invalid DID delegate
Reasons:

1. Actor key is not an active delegate of the entered Ethereum DID (ERC1056)
2. Actor is an active delegate but not an assertionMethod delegate for that DID

Solution:

1. Verify delegation status: Check if your key is properly delegated
2. Check delegate type: Ensure you're an assertionMethod delegate
3. Request proper delegation: Contact the DID controller for correct delegation
4. Use correct key: Switch to a properly delegated key if available
5. Update delegation: If permissions changed, request updated delegation

Prevention:

• Maintain proper delegation records
• Regularly verify delegate status
• Document delegation hierarchies
• Use delegation management tools

Unmatched Reference Hash

Description: Document file verification fails due to content changes.
Error Message: Unmatched reference hash
Reason: The user has changed the original file after registration, causing hash verification to fail. This is particularly common with web link resources where users can modify the linked file.

Solution:

1. Restore original file: Revert to the exact file used during registration
2. Check file integrity: Compare current file hash with registered hash
3. For web links: Ensure the linked file hasn't been updated or replaced
4. Re-register: If the file must be changed, register a new document
5. Use immutable storage: Switch to IPFS or Arweave to prevent modifications

Prevention:

• Use immutable storage (IPFS/Arweave) for important documents
• Implement version control instead of file replacement
• Document file hashes at registration time
• Use checksums for file integrity verification

Document Lifecycle Statuses

Created → Registered → [Validated/Suspended/Revoked] → Archived

Valid Status Changes:

• Issuer only: Revoke, Validate, Suspend
• Owner/Delegate: Update metadata (with proper permissions)
• Anyone: Verify (read-only)

Quick Resolution Guide

Best Practices for Document Management

Storage Recommendations

1. For critical documents: Use IPFS or Arweave (immutable)
2. For frequently updated documents: Implement versioning systems
3. Avoid: Modifiable web links for important documents
4. Always: Store original file hashes and DIDs securely

DID Management

1. Never manually edit DIDs
2. Always use official generation tools
3. Store DIDs in multiple secure locations
4. Verify DIDs before sharing or using

Permission Management

1. Document all issuer-delegate relationships
2. Regularly audit delegation status
3. Use proper DID methods for your use case
4. Implement multi-signature for important documents

Support Information

When contacting support about document registry issues, provide:

1. Complete document DID
2. Original registration transaction hash
3. Error message screenshot
4. Storage link used
5. Steps to reproduce the issue
6. Any modifications made since registration

Services

• Tokenomics
• Pay-As-You-Go
• Subscriptions
• Target Market

Execution Asset

Overview

SafePulse’s tokenomics are intentionally designed to avoid speculation and instead strengthen the integrity, security, and usability of the platform. The ecosystem revolves around PULSE, a non-tradable internal utility token used exclusively to deploy certain types of smart contracts.

PULSE is not a currency, not a tradable asset, and not a revenue instrument. It is a functional fuel that powers creatable agreements across the SafePulse network.

Purpose of PULSE

PULSE exists to guarantee:

• Fair access to contract creation
• Spam resistance
• Decentralized execution integrity
• Resource accountability in contract deployment
• A stable, predictable unit of work inside SafePulse

By tying contract creation to an internal, fixed-supply token, SafePulse avoids volatility and ensures that the cost of deploying agreements stays stable across time and market cycles.

Where PULSE Is Used

PULSE is required for deploying all creatable contracts, including:

• Pledge Contracts
• Verifiable Document Contracts

These contracts form the backbone of enterprise workflows, compliance systems, and automated agreements inside SafePulse.

Access to PULSE

PULSE is exclusive to ElysianPulse holders. This creates a premium access layer for users who need:

• High-volume contract creation
• Enterprise-grade workflows
• Long-term, predictable operational scaling

It also ensures responsible use, preventing contract spamming and maintaining network health.

Design Principles

1. Non-Tradeable, Utility-Only

PULSE cannot be traded or sold on public markets. This eliminates speculation and ensures token utility remains stable and predictable.

2. Anti-Spam and Cost Control

Contract creation consumes PULSE, ensuring users deploy only meaningful agreements.

3. Predictable Economics

PULSE is supplied to ElysianPulse holders and via subscription rewards, giving users a structured, clear cost model for repeated deployments.

SafePulse’s ecosystem tokens built for functionality and real value as an execution asset, not hype. PULSE powers the system with predictable, transparent, and fair access to smart contract creation—ensuring SafePulse remains sustainable, scalable, and trustless.

Pay-As-You-Go Model

Overview

The Pay-As-You-Go (PAYG) model is designed for individual users and small teams who need flexible access to SafePulse without subscriptions.

Users pay only for what they use, using native chain tokens (ETH, POL, etc.).

It is the simplest and most accessible model for casual usage.

Who It Is For

• Freelancers
• Crypto-native individuals
• Small businesses
• Occasional document certifiers
• One-time escrow users
• Creators paywalling individual digital assets

Users with low or inconsistent contract volume benefit most from the PAYG model.

Where PAYG Applies

PAYG covers all non-creatable contracts, including:

1. Escrow

• Flat deposit fee
• 1% withdrawal fee
• Ideal for one-time agreements

2. Document Registry

• Low-cost registration
• Instant on-chain timestamps

3. Asset Paywall

• Pay-per-access publication
• Monetize digital assets instantly

All fees are paid using native network tokens, keeping the user experience simple and familiar.

Key Benefits

1. No upfront commitment

Perfect for infrequent use.

2. Transparent micro-fees

Costs remain predictable and easy to understand.

3. Accessible to all users

No ElysianPulse token or subscription required.

4. Non-custodial and trustless

Users stay in control of all assets and data.

Fee Examples

• Escrow: 0.00067 ETH deposit fee (prevent abuse) + 1% withdraw
• Document Registry: 0.0019 ETH per entry
• Asset Paywall: 0.029 ETH deployment

(Chain-specific numbers may vary.)

PAYG provides affordable access to SafePulse’s core services with no commitments, enabling casual users to leverage trustless agreements whenever needed.

Subscriptions

Overview

SafePulse offers subscription plans designed for teams, enterprises, and organizations that require consistent, high-frequency contract creation.

Subscriptions unlock predictable monthly or yearly operational capacity, reduced costs, and bonus PULSE rewards.

Who Subscriptions Are For

• Legal and compliance teams
• HR onboarding pipelines
• Procurement departments
• Large-scale certifiers and credential issuers
• Agencies and organizations running recurring workflows
• Any user needing predictable cost structures

Subscriptions convert SafePulse into an integral operational tool rather than pay-per-use tooling.

What Subscriptions Provide

✔ Creatable Contract Deployments

Subscriptions cover:

• Pledge Contracts
• Verifiable Document Contracts

Each tier includes a specific number of deployments.

✔ Lower Per-Contract Cost

Discount rates range from 25% to 40% depending on the plan.

✔ PULSE Rewards

Every plan provides bonus PULSE to support future workflow expansion.

✔ Multi-Period Options

Plans are available at:

• 1 month
• 3 months
• 6 months
• 12 months

Longer commitments unlock deeper discounts.

Subscription Tiers

Prices differ per chain (Arbitrum / Polygon), but the structure and value remain identical.

Benefits of Subscription

1. Predictable Costs

No surprises — budgeting becomes easy.

2. Workflow Scalability

High-volume teams can automate agreements without worrying about per-use limits.

3. Increased Efficiency

Subscriptions remove friction and enable enterprise-wide adoption.

4. Access Control

Only ElysianPulse holders can subscribe, ensuring ecosystem integrity.

SafePulse’s subscription system empowers medium-to-large users with predictable, scalable, and cost-efficient contract deployment capacity. It is the backbone for enterprise automation within the SafePulse ecosystem.

Target Market

Overview

SafePulse serves a diverse global user base across individuals, creators, professionals, and institutions. The platform is designed for anyone who needs secure, trustless, automated agreements or verifiable data flows.

Our target market spans consumer-level use cases all the way to enterprise-grade automation.

1. Crypto-Native Individuals & Freelancers

These users value:

• Privacy
• Financial sovereignty
• Non-custodial tooling
• Peer-to-peer agreements
• Censorship resistance

Use Cases

• Freelance gig payments
• Peer-to-peer escrow
• Simple service agreements
• Automation without intermediaries

SafePulse provides tooling perfectly aligned with their ethos.

2. Enterprises & Institutions

Large organizations need scalable trust infrastructure across departments.

Teams That Benefit

• Legal
• Procurement
• HR
• Compliance
• Operations

Use Cases

• Pledge-based procurement logic
• Employee verification
• Credential issuance
• Contractual automation
• Cross-border settlement

SafePulse serves as a programmable infrastructure layer for digital trust.

3. Content Creators, Researchers & Educators

These groups require tamper-proof verification and monetization tools.

Use Cases

• Intellectual property proofs
• Research authenticity verification
• Certificate issuance
• Selling gated assets or digital files
• Timestamped document publications

The Document Registry and Asset Paywall are especially valuable to them.

4. Borderless & Privacy-Focused Users

A rapidly growing segment driven by:

• Exclusion from banking systems
• High global mobility
• Desire for anonymity
• Need for stablecoin payments

Use Cases

• Anonymous agreements
• Pseudonymous contracting
• Global access to stable settlement
• Cross-border operations without banks

SafePulse empowers these users with secure, privacy-respecting financial tools.

SafePulse’s target market includes anyone needing trustless agreements, verifiable documents, and non-custodial settlement. From individual freelancers to large enterprises, SafePulse delivers infrastructure that replaces intermediaries with automated, decentralized logic.

Privacy Policy

Last updated: 20 Dec 2025

By using SafePulse (“SafePulse”, “the Platform”, “we”, “us”, “our”), you agree to the practices described in this Privacy Policy. If you do not agree, you must not use the Platform.

1. Introduction

SafePulse is committed to protecting your privacy and ensuring that you maintain full control over your data.

The Platform is designed with:

• Data minimalism
• Local-first identity
• Non-custodial architecture
• User-controlled smart contract interactions

This Privacy Policy explains how SafePulse handles information, what is (and is not) collected, and your responsibilities as a user.

2. Zero Personal Data Collection

SafePulse collects no personal information whatsoever.

We do not collect, store, or process:

• Names, email addresses, phone numbers
• Government IDs, documents, or biometric data
• Wallet private keys, seed phrases, or sensitive financial details
• Location-linked identity or IP-linked profiles
• Personal behavioral tracking
• KYC information or verification data

SafePulse performs no KYC, no identity verification, and no account creation with personal data.

3. Local Device Control of Identity and Keys

All cryptographic materials—including identity keys, DID keys, private keys, credential keys, and signing keys—are generated and stored exclusively on your device.

SafePulse:

• Does not access, store, back up, or transmit your keys
• Does not retain credential-related information

You are solely responsible for securing your keys, recovery phrases, and devices. If keys are lost, SafePulse cannot recover them, reset them, or restore access.

4. No Cloud Backups & No Cloud Recovery

SafePulse does not provide:

• Cloud backup or cloud key storage
• SRP-based backups
• Server-side identity storage
• Remote account restoration

All recovery is performed locally by the user using their own passphrase or recovery materials.

5. No Traditional Authentication Services

SafePulse does not use or rely on:

• OAuth, email/password, phone verification
• Firebase Authentication or centralized login systems
• Third-party identity providers

Authentication and identity generation occur entirely on-device and are self-sovereign.

6. Optional Diagnostic Analytics

SafePulse may collect non-personal diagnostic data solely to improve:

• Stability
• Performance
• Security
• Crash detection

This data:

• Is anonymous and cannot identify users
• Contains no personal or behavioral information
• Can be disabled at any time in settings

Analytics may include device type, error logs, and crash traces—only for performance improvement.

7. No Tracking Technologies

SafePulse does not use:

• Cookies, web beacons, or fingerprinting
• Targeted advertising identifiers
• Cross-site tracking or behavioral analytics

No data is sold, shared, or monetized.

8. Third-Party Integrations

Interactions with third-party services (e.g., blockchain RPCs, event loggers, error trackers) are:

• Optional and user-initiated
• Separate from SafePulse systems
• Governed by the third-party’s privacy policies

SafePulse does not control or store data from third-party services.

9. Smart Contract Interactions

Smart contract interactions may appear on public blockchains.

• Transactions are irreversible
• Blockchain records are public by default
• SafePulse cannot delete or alter blockchain data
• Users must understand the immutable nature of blockchain systems

Smart Contract Upgrades:

• SafePulse may release updates or improvements
• Users may choose whether or not to adopt updates, at their own discretion
• The Platform provides no guarantees regarding performance, compatibility, or outcomes of upgraded contracts

10. Intellectual Property & Platform Ownership

• All components of SafePulse™, including smart contracts, dApps, ABIs, APIs, algorithms, documentation, and UI/UX, are proprietary and are the exclusive intellectual property of the Platform Owner. Certain components developed under the Contract Foundry Project may also be subject to patent-pending protection.

Nothing herein shall be construed as a transfer, license, or waiver of any intellectual property rights.

Supporting intellectual property and technical certification documentation may be provided to qualified business partners upon request, subject to confidentiality obligations.

• Users must not reverse engineer, decompile, copy, modify, or create derivative works of any platform components
• Users must not connect unauthorized third-party proxies or clients to SafePulse smart contracts

11. Content Restrictions & User Responsibility

Users must ensure that their usage:

• Complies with local laws and regulations
• Does not involve illegal, abusive, harmful, or exploitative content
• Respects platform restrictions against prohibited misuse

Users are responsible for their cryptographic materials and account security.

Users are solely responsible for ensuring that their use of the Platform complies with applicable laws, regulations, and restrictions in their respective jurisdictions.

12. Age Restriction

SafePulse is intended for users 22 years of age or older. No personal or non-personal data is knowingly collected from minors.

13. Data Sharing

SafePulse:

• Does not share, sell, or monetize data
• Does not profile users
• Does not integrate ad networks
• Analytics remain local and anonymous

All user activity remains private on your device.

14. Security Measures

SafePulse uses:

• Local encryption and self-sovereign identity mechanisms
• Decentralized architectures and secure cryptographic standards

However, no system is perfectly secure. Users must:

• Protect devices and backups
• Use strong passphrases
• Understand the risk of key loss

SafePulse cannot recover lost keys or compromised devices.

15. Updates to This Privacy Policy

SafePulse may update this Privacy Policy to reflect:

• Changes in technology
• Security improvements
• New platform features
• Updates in decentralized identity or smart contract standards

Continued use constitutes acceptance of the updated policy.

16. Contact Information

For privacy questions or administrative matters: support@safepulse.xyz

Terms & Conditions

Last updated: 20 Dec 2025

By using SafePulse (“SafePulse”, “the Platform”, “we”, “us”, “our”), you agree to comply with these Terms & Conditions. If you do not agree, you must not use the Platform.

1. Introduction

SafePulse is an independently operated decentralized software platform providing non-custodial services for blockchain-based agreements ecosystem.

SafePulse:

• Operates as a decentralized software service.
• Does not recognize or submit to foreign or external jurisdictions by default.
• Includes proprietary smart contracts, cryptographic systems, protocols, and software components that are patent pending and protected by the Contract Foundry Project.

By using SafePulse, you acknowledge and accept these Terms & Conditions.

2. “As-Is” and “As-Available” Disclaimer

SafePulse and all related components—including smart contracts, APIs, ABIs, and UI—are provided strictly:

• “AS IS”
• “AS AVAILABLE”
• “WITH ALL FAULTS”

We make no guarantees regarding:

• correctness or completeness
• uninterrupted or bug-free operation
• security or immunity from exploits
• suitability for any purpose
• compatibility with any system or jurisdiction

You use the Platform entirely at your own risk.

3. No Legal Advice or Dispute Resolution

SafePulse does not provide:

• legal advice
• financial advice
• tax advice
• compliance guidance
• regulatory guidance
• arbitration or dispute resolution

Users are solely responsible for consulting independent legal counsel and resolving any disputes. SafePulse does not intervene, mediate, or enforce any agreements or external jurisdictional decisions.

Users are solely responsible for ensuring that their use of the Platform complies with applicable laws, regulations, and restrictions in their respective jurisdictions.

4. No Guarantee of Court Recognition

SafePulse does not guarantee that any court, arbitration body, or authority will accept or recognize:

• blockchain data
• smart contract states
• cryptographic proofs
• timestamps
• digital agreements
• decentralized identifiers

Acceptance of such materials is outside SafePulse’s control.

5. Non-Custodial Design & No Cloud Recovery

SafePulse is a fully non-custodial platform.

SafePulse does not:

• store private keys
• store passphrases
• store account seeds
• store encrypted backups
• provide cloud key recovery
• provide cloud SRP recovery
• store wallet secrets in any form

The only way to recover your keys is through your locally stored passphrase or recovery phrase.

If you lose your keys or SRP:

• SafePulse cannot restore access
• SafePulse cannot reset accounts
• access may be permanently lost

Users are fully responsible for secure storage and backup.

6. Privacy & Data Protection (No KYC, No Personal Data)

SafePulse collects no personal information:

• names, email addresses, phone numbers, IDs, biometric data, wallet keys, IP-linked identity, or location
• no KYC or tracking of user behavior

Authentication

• Identity keys are generated and stored locally
• SafePulse does not use third-party authentication, OAuth, Firebase, email/password, or phone verification

Analytics

• Only non-personal diagnostic data may be collected for crash reports or performance monitoring
• Analytics do not contain personal data and can be disabled

7. User Responsibilities

By using SafePulse, you agree to:

1. Secure your private keys, passphrases, and devices
2. Maintain your own backups
3. Comply with local laws in your jurisdiction
4. Understand that blockchain transactions are irreversible
5. Accept that smart contract data cannot be modified by SafePulse

You assume full responsibility for your digital assets.

8. Smart Contracts & Upgrades

SafePulse provides smart-contract ecosystem.

However:

• SafePulse does not mediate disputes
• SafePulse cannot modify smart contract states
• P2P Agreement Payments and Escrows may lock until all parties reach agreement
• Locked funds cannot be released without action of parties

Smart Contract Upgrades:

• SafePulse may release updates or improvements to smart contracts
• Users may choose whether or not to adopt updates at their own discretion
• The Platform provides no guarantee regarding outcomes, performance, or compatibility of upgraded contracts

9. Limitations of Use & Intellectual Property

Ownership & Protection:

All components of SafePulse™, including smart contracts, dApps, ABIs, APIs, algorithms, documentation, and UI/UX, are proprietary and are the exclusive intellectual property of the Platform Owner. Certain components developed under the Contract Foundry Project may also be subject to patent-pending protection.

Nothing herein shall be construed as a transfer, license, or waiver of any intellectual property rights.

Supporting intellectual property and technical certification documentation may be provided to qualified business partners upon request, subject to confidentiality obligations.

User Obligations: By using SafePulse, you agree that you will not:

1. Modify, copy, prepare derivative works of, decompile, or reverse engineer any materials or software
2. Remove, alter, or obscure copyright, patent, trademark, or other proprietary notices
3. Transfer, distribute, or mirror materials to any other server, platform, or person
4. Abuse, disrupt, or interfere with SafePulse services
5. Connect unauthorized third-party proxies, clients, or external systems to SafePulse smart contracts or dApps

10. Prohibited Uses

Users may not use SafePulse for:

• Illegal, harmful, or abusive activity
• Fraud, deception, or money laundering
• Exploitation or hacking attempts
• Bypassing technical restrictions

Violations may lead to restrictions within the technical limits of the Platform.

11. Age Restriction

SafePulse is intended for users 22 years of age or older. Access by individuals under this age is prohibited.

12. Jurisdiction

SafePulse is governed exclusively by the laws applicable to its operational jurisdiction. The Platform does not recognize external jurisdiction except where legally required. SafePulse does not provide legal, regulatory, or dispute resolution services; users are solely responsible for resolving disputes.

13. Limitation of Liability

SafePulse is not liable for:

• Lost private keys, access, or assets
• Smart contract exploits
• Downtime or system failures
• Transaction errors
• Indirect, direct, incidental, or consequential damages

Use of the Platform is entirely at your own risk.

14. Amendments

SafePulse may update these Terms at any time due to:

• Technical changes
• Legal changes
• New features
• Security improvements

Continued use of the Platform constitutes acceptance of updated Terms.

15. Contact Information

For legal or administrative inquiries: support@safepulse.xyz

Transparency

This page describes how SafePulse operates, what it can and cannot do, and how user funds, data, and contracts are handled. It is intended to provide clear, verifiable information for users, developers, auditors, and regulators.

1. Platform Status

SafePulse is live and operational.

• Mainnet: Active
• Testnet: Active
• Environment: Production

SafePulse provides smart-contract infrastructure for agreements, payments, and document verification.

2. Custody & Control Model

Non-Custodial by Design

SafePulse is a non-custodial platform.

• SafePulse does not hold user funds
• SafePulse does not control private keys
• SafePulse cannot move funds without user authorization
• SafePulse cannot access or recover user assets

All asset movement requires cryptographic signatures from the relevant user wallets.

Contracts Involving Deposits

In the following contracts, users deposit funds into SafePulse smart contracts:

• Escrow contracts
• Document Registry contracts
• Asset Paywall contracts

These contracts are non-custodial:

• Funds are controlled exclusively by contract logic and user signatures
• Only depositors and contract parties can access or release funds
• SafePulse has no unilateral control over deposited assets

Contracts Without Deposits

In the following contracts, SafePulse has no access or control at all:

• Pledge Contracts
• Verifiable Document contracts

Each instance is deployed per user and operates independently.

3. Private Keys & Signatures

• SafePulse never generates, stores, transmits, or recovers private keys
• All interactions require direct wallet signatures
• SafePulse servers cannot trigger on-chain actions independently

4. Smart Contract Architecture

Upgradeability

• Smart contracts are upgradeable

• Upgrade mechanisms exist to:

  • Fix security vulnerabilities
  • Patch bugs
  • Add new features

Upgrades are not used to:

• Take custody of user funds
• Change ownership or withdrawal rights
• Introduce asset seizure or hidden controls

User-deployed contracts can be upgraded only by the contract owner, at their discretion.

Pausable Functions

Some contracts include limited pause mechanisms, strictly for protocol protection.

• Only specific functions (e.g., new deposits or new registrations) may be paused
• Existing user funds remain accessible to their owners
• Withdrawals and user-controlled actions remain available
• No pause function allows SafePulse to move or seize assets

Asset Paywall: Content-Based Restrictions

Only for Asset Paywall contracts, SafePulse includes a limited content-based restriction mechanism designed to mitigate the distribution of clearly illegal material.

In response to credible reports of illegal content — for example, sexual exploitation, harassment, or any kind of illegal NSFW material— SafePulse may temporarily freeze access to funds held within the affected Asset Paywall contract and remove the associated media payment gate access.

This mechanism:

• Applies exclusively to Asset Paywall contract
• Does not allow SafePulse to withdraw, transfer, or seize user funds
• Does not grant ownership or custodial control to SafePulse
• Restricts access only at the contract level and only temporarily
• Includes removal of references to the offending asset from SafePulse’s off-chain database
• Exists solely for compliance with legal obligations related to unlawful material

Frozen funds remain locked within the smart contract and cannot be accessed, moved, or repurposed by SafePulse.

No other SafePulse contract types include content-based restrictions, freeze mechanisms, or discretionary intervention by SafePulse.

This mechanism exists because SafePulse, as the operator of paid content gating, may have legal obligations concerning the distribution of unlawful material.

5. Escrow & Dispute Handling

• Escrow contracts are fully peer-to-peer
• No arbitration layer
• No human intervention
• No dispute resolution by SafePulse

SafePulse does not:

• Act as an arbiter
• Provide legal advice
• Make judgments or rulings

All outcomes are determined by smart-contract logic and cryptographic proofs.

On-chain records and signatures may serve as cryptographic evidence that can be used externally (e.g., legal proceedings), but SafePulse does not participate in such processes.

Dispute Prevention by Design:

SafePulse contracts are built with automated, rule-based logic that enforces agreement conditions. By encoding obligations, milestones, and verification requirements directly into the contracts, most potential conflicts are resolved automatically. This design minimizes the need for human intervention or arbitration, while ensuring that outcomes are predictable and verifiable by all parties.

6. Source Code & Intellectual Property

• SafePulse software is closed-source
• All components are protected under copyright
• The platform and its contracts are proprietary intellectual property of the platform owner

No developed components are currently open-source.

7. User Accounts & Data Collection

Account Creation

• No off-chain accounts are created
• No emails or usernames are collected
• Wallet connection is the only authentication method

Data Collection

SafePulse does not collect:

• Emails
• Names
• Phone numbers
• IP addresses
• Device fingerprints
• Any Sensetive data

SafePulse does not use:

• Cookies
• Tracking scripts

Off-Chain Data

The only off-chain references stored are user-provided asset identifiers, such as:

• IPFS CIDs
• Arweave transaction IDs
• Web URLs

These references may be encrypted in a decentralized way. SafePulse does not have access to encrypted content.

8. Identity, KYC & Compliance

• No KYC
• No AML onboarding
• No identity verification

Authentication is performed using self-sovereign cryptographic identity, including:

• W3C Decentralized Identifiers (DIDs)
• ERC-1056 / uPort-compatible identities
• Public or pseudonymous wallet identities

9. Jurisdiction & Legal Requests

SafePulse operates as a software platform, not as a financial or legal intermediary.

• The platform itself is not bound to a specific jurisdiction
• The platform owner is registered as a sole legal business owner

SafePulse policy:

• Publish transparency reports
• Notify users of legal requests when legally permitted
• Do not voluntarily share user data

SafePulse cannot provide private keys, recover funds, or reverse transactions.

10. Security & Audits

• Smart contracts have undergone security audits
• Audit reports are not publicly published
• Security disclosures are accepted via:

Email: security@safepulse.xyz GitHub: Issues may be submitted to relevant repositories

11. Platform Limitations

SafePulse explicitly does not:

• Hold custody of assets
• Reverse transactions
• Resolve disputes
• Enforce legal agreements
• Recover lost keys
• Freeze or confiscate funds
• Act on behalf of users

Users retain full responsibility for:

• Key management
• Contract configuration
• Jurisdictional compliance
• Legal enforceability

12. Changes to This Page

This Transparency page may be updated to reflect:

• New features
• Security updates
• Regulatory clarity

Material changes will be documented publicly.

FAQ

General Questions

1. What is SafePulse?

SafePulse is a trustless, non-custodial smart contract ecosystem that enables automated, verifiable agreements on blockchain networks. It allows individuals and businesses to manage payments, coordinate work, and verify data without surrendering control of their assets or private information.

2. How is SafePulse different from traditional escrow platforms?

Unlike traditional escrow services, SafePulse removes intermediaries entirely.

Funds are locked inside smart contracts, not held by a company or kept in a user’s wallet. Execution is automatic and condition-based. No human approval, no centralized custody, and no discretionary control over funds.

3. How is SafePulse different from marketplaces like Upwork or Fiverr?

SafePulse is not a marketplace. It’s a protocol-first ecosystem of smart contracts and tools that enable secure, peer-to-peer agreements, payments, and verification. Users interact directly on-chain, without relying on centralized platforms.

4. Is SafePulse a marketplace?

No. SafePulse is a multi-purpose ecosystem of smart contracts, protocols, and tools for secure interactions on EVM-compatible blockchains. It enables agreements, payments, and verifications, but does not match buyers and sellers like a marketplace.

5. Who is SafePulse built for?

SafePulse serves anyone who needs secure, automated, and verifiable digital agreements, including freelancers, creators, small and medium businesses, and enterprises.

6. Is SafePulse open source?

No. All SafePulse components—including the dApp, wallet, smart contracts, algorithms, and protocols—are closed-source, patent-pending, and protected by copyright.

7. What blockchain(s) does SafePulse operate on?

Currently, SafePulse runs on Polygon and Arbitrum. In the future, we plan to support Ethereum mainnet and additional Layer-2 networks to expand access and liquidity.

8. What tokens or stablecoins are supported?

SafePulse supports major stablecoins and tokens commonly used in business: USDT, USDC, DAI, FRAX, WETH, WBTC, MAI, TUSD, LUSD, SUSD, PYUSD, USDE, FDUSD, as well as the native tokens of each supported network.

9. Does SafePulse issue its own token?

Yes, SafePulse currently has two non-financial tokens:

• ELYPS – an access credential token
• PULSE – an execution asset No financial token is planned for launch.

10. Is SafePulse decentralized or partially centralized?

Yes. SafePulse is decentralized and non-custodial.

Smart contracts execute fully on-chain.

SafePulse includes a metadata server, but it:

• Does not store user funds
• Does not store private keys
• Does not store personal data
• Is used only for non-user operational permission handling and storing encrypted references

All agreement logic and value transfers remain on-chain.

Custody & Security

11. Does SafePulse ever hold my funds?

No. SafePulse is non-custodial. Funds never leave the user’s wallet unless conditions of the agreement are cryptographically verified.

12. Who controls the smart contracts?

Contracts are executed automatically by code on the blockchain. Users retain control over assets, and SafePulse does not have the ability to override or alter contracts.

13. Can SafePulse freeze or access my funds?

No. SafePulse cannot access, freeze, or manipulate user funds. Contract logic enforces conditions without intermediary control.

14. What happens if SafePulse shuts down?

SafePulse is decentralized, so the platform shutting down does not affect deployed contracts. Users remain responsible for their own wallets and private keys.

15. Are contracts upgradeable?

Yes. Smart contract code may be upgraded to introduce improvements or fixes.

However:

• Users are not forced to upgrade their deployed contracts
• Upgrades are for deployable contarcts
• Deployed agreement states remain unaffected

Users decide whether to adopt new versions of the contracts.

16. Has the code been audited?

Yes. SafePulse has undergone private audits by humans and AI. Reports are not publicly available but ensure the integrity and security of the platform.

17. What happens if there is a smart contract bug?

SafePulse is not liable for exploits.

If a bug is detected or a new feature is requested:

• Users may report issues directly
• Improvements or fixes may be implemented in upgraded contract versions

Contracts are copyright-protected and not publicly verified, updates and security fixes will be handled internally.

18. What if I lose access to my wallet?

SafePulse cannot recover lost private keys, passphrases, or seed phrases. Users are fully responsible for securely storing and backing up keys.

19. How are disputes handled if there is no intermediary?

SafePulse is arbiterless by design. Agreements enforce themselves. If disputes occur, users can present on-chain proofs or documents in court.

20. Can someone hack or override a contract?

Contracts are executed autonomously on-chain, making them tamper-proof. Users remain responsible for wallet security.

Legal & Compliance

21. Is SafePulse legally binding?

Yes. Actions are recorded on-chain with cryptographic proofs, which can serve as admissible evidence in legal proceedings if required.

22. Can SafePulse contracts replace traditional legal contracts?

SafePulse agreements automatically enforce predefined conditions between parties.

If no external legal enforcement is required, agreements function independently through on-chain execution.

However, if users require traditional legal recognition, regulatory approval, or enforcement outside blockchain execution, additional legal agreements may still be necessary.

SafePulse enforces execution — it does not replace every possible legal framework.

24 & 25. Is SafePulse KYC/AML compliant?

SafePulse is protocol-first, non-custodial, and on-chain, so KYC and AML are not required. There is no central control, similar to platforms like Uniswap, making it enterprise-friendly while remaining compliant with decentralized protocol standards.

26. Can businesses use SafePulse while remaining compliant?

Yes. Businesses can participate in agreements as parties, without acting as flow controllers. All transactions are transparent, verifiable, and non-custodial.

Payments & Transactions

29. How do payments work inside a contract?

Funds are deposited into and locked inside smart contracts. They are released only when contract conditions are met.

30. What does “progressive execution” mean?

Progressive execution allows:

• A single payment contract to be funded through multiple deposits
• Agreement documents to include multiple payment contracts
• Different tokens per payment
• Different expiration times per payment

Each payment contract remains separate, allowing flexibility in structuring complex agreements.

31. Can funds be released in milestones?

Yes.

Each payment contract can be released independently from other payment contracts.

However:

• A single payment contract cannot be released partially
• It must be executed as a whole
• Multiple payment contracts can exist within one agreement

32. Can contracts be revoked?

Yes, if the contract logic allows revocation. Revocable contracts can undo or cancel conditions before execution.

33. What happens if one party disappears?

Funds may lock until all parties act, protecting remaining participants from loss.

34. Can contracts include deadlines?

Yes. SafePulse supports time-bound logic to enforce deadlines automatically.

35. What happens when a deadline is missed?

Agreements can freeze assets or trigger contract-specific logic until conditions are resolved.

36. Are transactions reversible?

Yes, escrow and pledge contracts allow conditional refunds or rollbacks, as defined in the contract logic.

37. What are the platform fees?

SafePulse reduces overhead by removing intermediaries, offering a cost-efficient, transparent transaction environment.

38 & 39. Who pays transaction/gas fees?

Users pay fees directly via their wallet based on network conditions and service pricing.

40. Can payments be made cross-border without restrictions?

Yes. SafePulse operates globally, without mandatory KYC or jurisdictional restrictions, allowing borderless transactions.

Identity & Privacy

41. Do I need to reveal my identity?

No. SafePulse is privacy-first, and personal identity approval is not required.

42. Can I stay anonymous?

Yes. Users may interact pseudonymously, using cryptographic proofs rather than personal data.

43. What is a verifiable credential?

A verifiable credential is a proof of authenticity tied to documents, identity, or agreement actions, stored on-chain without exposing personal data.

44. What is DID (Decentralized Identifier)?

A DID is a unique, URL-like identifier for sovereign entities in decentralized systems. In SafePulse, DIDs identify contracts, deposits, registries, and accounts, ensuring secure, auditable, and abuse-resistant interactions.

45. How does SafePulse verify documents without storing them?

SafePulse uses cryptographic methods to verify the authenticity of documents without storing the actual files.

Users choose where to store their files — whether decentralized storage or their own infrastructure — while SafePulse verifies integrity and authenticity without holding the data.

46. Where are files stored?

Users can store files on decentralized networks or preferred storage, remaining fully in control.

47. Can I use centralized storage?

Yes. SafePulse supports user choice for storage while still verifying proofs on-chain.

48. Does SafePulse track user data?

No. Analytics are anonymous and optional, containing no personal data.

Disputes & Risk Management

49. How are disputes triggered?

Disputes are minimized by self-enforcing agreements, but if they occur, users can present on-chain proofs in court.

50. What does “asset freeze” mean?

Funds are temporarily locked in the contract until all parties fulfill agreement conditions.

51 & 53. Who resolves disputes and can third-party arbitration be used?

SafePulse is arbiterless. No external or third-party arbitration is supported. Users rely on contract enforcement or legal presentation of on-chain proof.

54 & 55. What prevents bad actors and fraud?

Contracts are self-enforcing, tamper-proof, and protocol-first, reducing opportunity for fraud or abuse.

56 & 57. What if both parties disagree permanently / Can funds be locked forever? Funds may remain locked until all parties act. The protocol cannot release funds unilaterally.

Business & Enterprise Use

58. Can enterprises integrate SafePulse via API?

No public API exists; all interactions are directly on-chain via dApp or smart contracts.

60. Is SafePulse suitable for large transaction volumes?

Yes. The platform is designed for high-volume transactions and secure agreement enforcement.

61. Can SafePulse integrate with accounting systems?

No. SafePulse does not integrate with automation or accounting software.

62. Can contracts include multi-signature logic?

Native multisig is not supported, but multiparty agreements with multiple tokens and payments are fully supported.

64. Is SafePulse suitable for recurring agreements?

Recurring or milestone-based agreements can be implemented, but contracts themselves are immutable once deployed.

65. Can SafePulse be white-labeled?

No. All services are patent-pending and copyright-protected.

66. Is there SLA or enterprise support?

SLA is unnecessary due to on-chain decentralized execution, but enterprise support is available through guidance, deployment assistance, and consulting.

Practical Usage Questions

67. Do I need coding knowledge?

No. SafePulse allows anyone to deploy contracts via dApp with minimal clicks.

68. How long does it take to create a contract?

A few minutes. Contracts are automated and easy to configure via the dApp.

69. Can I edit a contract after deployment?

No. Agreements are immutable, though contract code may be upgraded for features or bug fixes.

70. Can I template agreements?

No.

SafePulse is not a legal document signing platform like DocuSign.

To repeat an agreement, users must deploy a new contract with the same data manually. No pre-made legal templates are provided.

71. Can I duplicate an existing contract?

No. Each contract is a separate deployment. To replicate, you must deploy a new contract with the same content.

72. Is there a minimum contract value?

No minimum; any value can be used.

73. Is there a maximum contract value?

No. Contracts are unlimited in value.

74. Can SafePulse be used on mobile?

Yes. Anyone with a compatible smartphone and wallet can use the dApp.

75. What wallets are supported?

Most injected wallets, including MetaMask, TrustWallet, and others, are supported.

Strategic / Philosophical Questions

76. Why is “trustless” better than trusted platforms?

By removing intermediaries, SafePulse reduces risks of fraud, censorship, and centralized failure. Trust is derived from math, cryptography, and verifiable execution, not humans or institutions.

77. How does SafePulse eliminate fraud mathematically?

All agreements and payments are executed by smart contracts with cryptographic proofs, making tampering, double-spending, or fraud nearly impossible.

78. What happens if blockchain regulations change?

SafePulse is protocol-first, on-chain, non-custodial, and decentralized. Changes in external regulations do not affect on-chain execution.

79. How does SafePulse compare to traditional escrow?

SafePulse provides automatic enforcement, non-custodial funds, and verifiable agreements, unlike traditional escrow, which is manual, centralized, and costly.

80. Why now? What makes this viable today?

Decentralized technology, cryptography, and Layer-2 scaling solutions are now mature, reliable, and accessible, enabling trustless, borderless, and automated agreements.

81. What risks still exist?

Users are responsible for key management, wallet security, and proper agreement setup. On-chain execution is secure, but human error or lost keys remain risks.

82. What problems does SafePulse NOT solve?

SafePulse does not handle complex legal disputes, centralized liquidity management, or regulatory enforcement. It only provides secure, verifiable on-chain interactions.

83. How does SafePulse generate revenue?

Through service registry fees, execution fees, access tokens, and on-chain deployment subscriptions.

84. Why should I trust the protocol?

SafePulse is non-custodial, cryptographically secure, and verifiable on-chain. Protocol logic enforces agreements independently of the platform.

85. What is SafePulse’s long-term vision?

To build a world of sovereign digital agreements, enabling secure, automated, and borderless collaboration for individuals and businesses globally.

📬 Contact Us

We’d love to hear from you! If you have questions, feedback, or need support, you can reach us through the following channels:

• Email → support@safepulse.xyz
• Telegram → @safepulseapp

✨ Tip: Join our Telegram channel to stay updated on announcements, new features, and community discussions.