Introduction

SafePulse is a decentralized escrow and settlement protocol that enables secure payments, conditional escrow, document notarization, and verification on-chain. By synchronizing agreements, verifiable documents, and fund transfers through smart contracts, SafePulse ensures that payments and settlements are executed only when predefined conditions are met. The protocol eliminates intermediaries, reduces counterparty risk, and provides a transparent infrastructure for trustless digital transactions and agreement-driven settlements.

Why SafePulse?

Digital transactions often require trust between parties who may have no prior relationship. Traditional escrow and settlement processes rely on intermediaries, manual verification, and fragmented systems to manage agreements, documents, and payments. These approaches can introduce delays, increase costs, and create points of failure that expose participants to counterparty risk.

SafePulse was built to provide a trustless alternative. By combining conditional escrow, on-chain verification, document notarization, and automated settlement into a single decentralized protocol, SafePulse ensures that transactions are executed according to predefined rules rather than human discretion.

With SafePulse, agreements, supporting documents, and payment flows remain cryptographically verifiable and transparently recorded on-chain. Funds are only released when specified conditions are satisfied, reducing the need for intermediaries while increasing security and accountability for all participants.

Whether facilitating business agreements, milestone-based payments, marketplace transactions, or digital settlements, SafePulse provides a reliable infrastructure where trust is enforced by smart contracts and verifiable data rather than third parties.

Benefits

• Trustless Execution — Smart contracts automatically enforce agreement terms.
• Reduced Counterparty Risk — Funds remain secured until conditions are fulfilled.
• Document Integrity — Important documents can be notarized and verified on-chain.
• Transparent Settlements — Every action is auditable and publicly verifiable.
• Lower Operational Overhead — Eliminate reliance on intermediaries and manual processes.
• Programmable Agreements — Support customizable settlement logic for diverse use cases.

Core Services

SafePulse provides five fully on-chain services that enable trustless agreements, verifiable documentation, and secure value transfer. Each service is designed to operate without custodians, centralized authorities, or off-chain trust assumptions.

1. Document Registry

The Document Registry is the foundation for document notarization and verification within SafePulse.

It allows users to create immutable proofs of document existence and integrity while maintaining complete control over their data. Files are never stored by the protocol. Users can host documents wherever they choose while SafePulse provides cryptographic verification directly on-chain.

Features

• On-chain document notarization
• On-chain verification
• Multi-verifier support
• Non-custodial architecture
• User-controlled document storage
• Permanent proof of document integrity

2. Escrow Contract

The Escrow Contract enables secure, trustless fund holding and conditional settlement between parties.

Funds remain locked on-chain until predefined conditions are satisfied or a time-based release mechanism is triggered. The system is designed to operate without custodians or arbitrators, reducing settlement risk while maintaining transparency.

Features

• Instant escrow creation
• TimeGuard release mechanisms
• Non-custodial fund management
• Arbitrator-free settlement
• Support for stablecoins
• Support for native blockchain assets
• Fully on-chain execution

3. Verifiable Documents

Verifiable Documents extend standard notarization by introducing controlled, verifiable digital records that can participate directly in financial and contractual workflows.

These documents can be linked to payments, managed by multiple controllers, and verified entirely on-chain.

Features

• On-chain document notarization
• On-chain verification
• Multi-controller management
• Multi-party participation
• Payment-linked documents
• Expirable or permanent validity
• Immutable audit trail

4. Pledge Contract

The Pledge Contract is a programmable settlement framework that enables sellers, service providers, and organizations to define custom payment conditions.

Unlike traditional escrow, pledge contracts support progressive settlements, milestone-based payments, and multiple settlement events within a single agreement.

Features

• Seller-defined payment logic
• Multiple settlement stages
• Progressive payments
• Verifiable document integration
• TimeGuard protection
• Expirable or permanent agreements
• Stablecoin support
• Native asset support
• Fully on-chain settlement execution

5. Verifiable Credentials

Verifiable Credentials provide portable, cryptographically verifiable records that can be shared across platforms while preserving authenticity.

Credentials remain verifiable even when transferred independently from the SafePulse platform, making them suitable for certifications, attestations, approvals, and identity-linked records.

Features

• Portable verification
• Tamper-proof credential validation
• Fraud-resistant authenticity checks
• Independent verification capabilities
• Cryptographic proof of integrity
• On-chain trust anchor
• Cross-platform compatibility

Together, these services form a unified trust infrastructure where agreements, documents, credentials, and payments can be created, verified, and settled entirely on-chain without relying on intermediaries.

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
• PULSE
• ELYPS
• Decentralized Storage

Decentralized Identifiers

Self-sovereign, verifiable identities for Wallet accounts and smart contracts within the SafePulse ecosystem.

Overview

A Decentralized Identifier (DID) is a globally unique, persistent identifier that allows its controller to prove cryptographic ownership over it. Unlike traditional identifiers (email addresses, usernames, account numbers), DIDs are not issued or managed by any central authority. The entity that controls a DID is called the controller.

The DID Document

Every DID resolves to a DID Document—a structured JSON file that describes the subject and provides the technical information needed for cryptographic interactions. A DID Document typically contains:

DID Methods in SafePulse

A DID method defines the specific rules for how a DID is created, resolved, updated, and deactivated. SafePulse supports two primary DID methods, each suited for different use cases.

1. did:key — Off-Chain, Generative Identity

did:key is a purely off-chain, deterministic DID method. The identifier is generated directly from a public key, requiring no blockchain transaction, no registration, and no gas fees. The DID Document can always be re-derived from the public key alone.

Syntax:

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

Example:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Key Characteristics:

• Cost: Free to create. No on-chain transaction is required.
• Key Rotation: Not supported. A new key means a new DID.
• Delegation: Not supported. The controller is implicitly the key holder.
• Use Case: Ideal for ephemeral interactions, quick prototyping, or scenarios where on-chain anchoring is unnecessary.

2. did:ethr — On-Chain, Ethereum-Anchored Identity (ERC-1056)

did:ethr is an Ethereum-based DID method built on the ERC-1056 Lightweight Identity standard. It uses an on-chain registry to manage DIDs, their keys, delegates, and service endpoints, providing a verifiable and auditable identity layer.

Syntax:

did:ethr:<chain-id>:<ethereum-address>

Example:

did:ethr:1:0xAbC123456789abcdef123456789abcdef1234567

Key Characteristics:

• Cost: Requires gas for updates (adding delegates, rotating keys, setting attributes).
• Key Rotation: Fully supported via delegate management and registry updates.
• Delegation: Supported. The controller can authorize multiple delegates to act on its behalf.
• Service Endpoints: Stored as on-chain attributes, enabling verifiable service discovery.
• Use Case: Ideal for persistent, enterprise-grade identities requiring auditability and advanced key management.

Comparison: did:key vs did:ethr

Contract DID & Registry DID

Beyond user and organizational identities, SafePulse extends the DID standard to smart contracts and registries. These Contract DIDs serve as cryptographic handles for on-chain entities, enabling secure reference and interaction.

Contract DID Structure

A Contract DID identifies a specific deployed smart contract and can optionally include a cipher key for encrypting sensitive contract state.

Format:

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

Example:

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

Components:

• did:ethr: Ethereum-compatible DID method.
• <chain-id>: The EVM chain ID where the contract is deployed (e.g., 1 for Ethereum mainnet).
• <contract-address-hex>: The contract's on-chain address in hexadecimal format.
• key=<cipher-key-hex> (Optional): A private cipher key for encrypting sensitive contract data. This key must never be shared with unauthorized parties, as it grants the ability to decrypt confidential contract information.

Registry DID Structure

Registries are on-chain data structures that map, verify, or index other contracts, users, or assets. A simpler DID format is used to reference them.

Format:

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

Example:

did:ethr:5:0x9f8a7b6c5d4e3f2a1b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2

Registry DIDs enable tamper-proof lookups, automated verification, and secure referencing of on-chain data without relying on centralized indexers.

Security & Privacy Considerations

• Private Key Protection: Control over a DID is ultimately determined by control of its associated private keys. Safeguarding these keys is the user's sole responsibility.
• Cipher Key Confidentiality: For Contract DIDs that include a key= parameter, the cipher key should be treated as a secret. Sharing it with unauthorized parties compromises any encrypted contract state.
• On-Chain vs. Off-Chain: did:key offers greater privacy (nothing is on-chain), while did:ethr offers greater auditability and management flexibility. Choose the method that aligns with your use case.
• Key Rotation: For long-lived identities, did:ethr is recommended due to its support for key rotation, reducing the risk associated with key compromise.

Summary

Decentralized Identifiers are the identity backbone of the SafePulse ecosystem. They enable users, organizations, and smart contracts to interact with cryptographic certainty, without relying on centralized authorities. SafePulse supports two DID methods—did:key for lightweight, off-chain use and did:ethr for persistent, on-chain identity management—as well as Contract DIDs for secure, verifiable smart contract interaction.

Elysium Protocol

Overview

The Elysium Protocol is the premier, feature-rich environment within the SafePulse ecosystem. While SafePulse provides a fully non-custodial infrastructure open to all users, Elysium is an exclusive, gated layer designed for individuals, enterprises, and institutions that require maximum security, operational sovereignty, and access to the most advanced features.

Elysium is not a separate platform, but a MetaProtocol that enhances existing SafePulse services with stricter execution guarantees, deeper document integration, and a Sybil-resistant access model. Access to this environment is cryptographically enforced through tokenized credentials, not centralized permissions.

Core Architecture

Elysium's design is built on two functionally distinct assets that separate the concepts of access and execution.

1. Elysian Accounts & The ELYPS Access Token

An Elysian Account is any EOA that holds the required threshold of ElysianPulse Tokens (ELYPS) . ELYPS is not a payment currency; it is a pure utility token whose sole function is to serve as a cryptographic key for the Elysium environment.

This architecture ensures that access to Elysium is merit-based, user-controlled, and perfectly portable, while remaining resistant to Sybil attacks and speculation.

2. Pulse: The Execution Asset

Pulse (PULSE) is the internal, non-tradable execution token that powers all advanced operations within the Elysium Protocol. It functions as the "fuel" for Elysium's enhanced services.

Key Distinction: Unlike a generic "network token" (which pays gas to a blockchain validator), Pulse is an application-level execution asset that fuels specific service deployment within the Elysium protocol.

Access Summary

Use Cases: Who is Elysium For?

• Enterprises & Institutions: Managing complex, high-value B2B agreements that demand a gated, Sybil-resistant environment and legally-aware document verification.
• High-Value IP Holders & Creators: Licensing premium intellectual property and requiring maximum control, verifiable security, and conditional payment enforcement.
• Heavy Crypto Users: Doing High-Volume transactions.
• Power Users: Individuals seeking the absolute highest tier of non-custodial operational sovereignty for complex, multi-party smart contract orchestration.

The Elysium protocol is a gate to another tier of core services for higher stakes and stricter guarantees.

Pulse Token

The dedicated, non-tradable execution asset powering high-security operations within the Elysium ecosystem.

Overview

Pulse (PULSE) is the dedicated execution token of the SafePulse Elysium ecosystem. It functions strictly as a transactional asset for performing advanced, high-security on-chain service deployments. It is not a speculative or tradable asset—its value is purely functional, ensuring cryptographic integrity and tamper-proof execution of critical operations.

PULSE acts as the engine of the Elysium Protocol, while the ElysianPulse Token (ELYPS) acts as the key. Together, they form a secure, closed-loop operational environment.

Key Characteristics

Role in the Dual-Token Architecture

SafePulse's Elysium Protocol operates on a dual-token model that cleanly separates who can access the environment from how operations are executed within it. PULSE is the execution half of this architecture.

Why This Separation Matters

This design maximizes user sovereignty and ecosystem security:

• Decoupled Control: Holding ELYPS grants access but never automatically consumes PULSE. Users explicitly control both their access rights and their operational spending.
• No External Market Interference: Because PULSE is non-tradable and confined to the ecosystem, its utility cannot be manipulated by external market dynamics, speculation, or front-running.
• Authenticated Execution: Every operation is cryptographically tied to both a verified ELYPS holder and a PULSE expenditure, creating a fully auditable and non-repudiable execution trail.

Security & Assurance

The non-tradable, utility-locked nature of PULSE creates a highly secure operational environment:

• Minimized Attack Surface: PULSE cannot be transferred, sold, or manipulated outside of its intended execution context, eliminating common attack vectors like front-running or market-based manipulation.
• Closed-Loop Integrity: Combined with ELYPS-based access control, PULSE ensures that only verified, token-holding accounts can initiate sensitive operations, and every operation is backed by deterministic, tamper-proof execution logic.
• No Speculative Pressure: PULSE has no financial market value, ensuring its cost and availability remain tied to its functional utility, not external speculation.

How to Obtain Pulse

PULSE distribution is handled through platform-specific allocations to verified ELYPS holders. Eligibility, allocation mechanisms, and distribution schedules are tied directly to the ElysianPulse Token ecosystem.

For complete details on eligibility requirements, token allocation mechanisms, and distribution processes, refer to the ElysianPulse Token (ELYPS) documentation and the Elysian Accounts guide.

Summary

Pulse is the engine of the Elysium Protocol. It ensures that every high-value operation—from deploying a Pledge Contract to verifying a legal document—is executed with cryptographic integrity, full auditability, and zero reliance on external market forces. By separating execution fuel from access credentials, PULSE empowers users with complete sovereignty over their operational environment.

ElysianPulse Token

The ERC-20 access license for the Elysium Protocol. A non-speculative, user-sovereign credential for high-tier SafePulse services.

Overview

The ElysianPulse Token (ELYPS) is a limited-supply, ERC-20 utility token that serves as the sole access credential for the Elysium Protocol within the SafePulse ecosystem. It is purpose-built for access control, not financial speculation.

ELYPS does not function as a currency, a gas token, or a payment method. Its the gate pass license of elysium protocol, cryptographically granting the holder access to the most advanced, high-sovereignty services SafePulse offers.

Key Characteristics

How ELYPS Works: The Access License Model

1. Holding ELYPS = Elysian Account Status

A wallet that holds the required minimum (5 ELYPS) threshold of ELYPS is automatically recognized as an Elysian Account. This status is verified on-chain and requires no application, no KYC, and no centralized approval. The token itself is the credential.

2. Transferring ELYPS = Transferring Access

The Elysian Account designation is fully portable and user-controlled.

• Sending ELYPS to another wallet instantly revokes your Elysian Account privileges.
• The receiving wallet immediately gains full Elysian Account status.
• There is no onboarding delay, no re-verification process, and no cooldown period.

This creates a flexible, liquid access model where the right to use advanced services can be transferred as easily as any token.

3. Explicit Approval is Always Required

Holding ELYPS grants access, but it never acts on your behalf. Unlike gas tokens or fee-bearing assets that are automatically deducted for transactions:

• No operation can consume or lock your ELYPS without your direct, explicit approval.
• You retain absolute control over when and how your access credential is utilized.

How to Acquire ELYPS

ELYPS tokens are distributed through a reserved allocation model. Eligible users can acquire their reserved tokens through the official acquisition portal.

Note: ELYPS is not available on public exchanges. The official portal is the sole distribution channel, ensuring that tokens are acquired for their intended utility, not speculative trading.

What ELYPS Unlocks

An Elysian Account gains access to the most sophisticated, high-sovereignty components of the SafePulse ecosystem:

• Elysium Service Suite: The full set of advanced, non-custodial platform features designed for high-value operations.
• Pledge Contract System: Deployment and management of secure, commitment-based smart contracts with conditional execution guarantees.
• Verifiable Document Service: Cryptographic notarization, anchoring, and institutional-grade verification of digital documents, integrated directly with contract execution logic.

Public users without ELYPS retain full access to all open SafePulse services. ELYPS exclusively gates the enhanced Elysium environment.

Role in the Dual-Token Architecture

SafePulse's Elysium Protocol operates on a dual-token model that cleanly separates who can enter from how operations are executed. ELYPS is the access half of this architecture.

This separation ensures:

• Access Control: ELYPS governs entry to the permissioned environment, ensuring a Sybil-resistant, committed user base.
• Operational Sovereignty: PULSE governs execution, allowing users to manage the cost of operations independently from their access rights.
• User Control: Both tokens require explicit user action, ensuring no automated consumption or loss of control.

Security & Sovereignty Guarantees

By anchoring access to a limited-supply, user-held token, ELYPS provides foundational security for the Elysium ecosystem:

• Sybil Resistance: The limited supply and token-gated model prevents mass creation of fake or low-quality accounts attempting to access high-value services.
• Speculation Resistance: ELYPS is intentionally not listed on exchanges and has no financial utility. Its value is purely functional, disincentivizing speculative hoarding.
• Unilateral User Control: Users retain complete sovereignty over their access rights. They can transfer, hold, or manage their ELYPS without platform interference.
• Credential Portability: Access is not locked to an account, email, or identity. It is a token in a wallet, fully portable and controlled by the holder's private keys.

Summary

The ElysianPulse Token is the permission layer of the Elysium Protocol. It transforms a simple token holding into a powerful, portable, and sovereign access credential. By holding ELYPS, a user cryptographically proves their right to operate within the most advanced, secure, and high-value environment SafePulse has to offer.

Decentralized Storage

Permanent, tamper-proof, and censorship-resistant data storage for the SafePulse ecosystem.

Overview

Decentralized storage refers to a method of storing digital data across a distributed network of nodes rather than on centralized servers controlled by a single entity. By leveraging blockchain and peer-to-peer technologies, decentralized storage ensures data immutability, censorship resistance, and long-term availability. Users retain full control over their data without relying on any single authority or hosting provider.

In the SafePulse ecosystem, decentralized storage plays a critical role in storing verifiable documents, smart contract references, and other high-value data assets. It enables secure, verifiable interactions between users, smart contracts, and third parties without exposing sensitive content on-chain.

SafePulse supports two of the most widely used decentralized storage protocols: Arweave and IPFS (InterPlanetary File System) , each optimized for different permanence and availability requirements.

Why Decentralized Storage Matters

Traditional centralized storage solutions present several risks for high-value digital operations:

For legal documents, intellectual property, smart contract deliverables, and verifiable credentials, these guarantees are essential.

Arweave: Permanent, Immutable Storage

Overview

Arweave is a blockchain-backed storage protocol designed for permanent, immutable data storage. Data uploaded to Arweave is stored across a distributed network and is guaranteed to persist indefinitely through a one-time upfront payment. Once uploaded, data cannot be altered or deleted.

The Transaction ID (TxID)

Each piece of data stored on Arweave is assigned a unique Transaction ID (TxID) . This TxID serves as a permanent, verifiable reference to the stored data. Anyone with the TxID can retrieve and verify the file at any time, forever.

Example TxID:

bL8d8hXk5m9Q2wR7tY3nA6pJ4cF1vG0sE9xZ7yU5iK3m

Key Characteristics

How It Works

Arweave employs a blockweave structure, an evolution of traditional blockchain. Data is linked together using a combination of cryptographic proofs and a consensus mechanism called Proof of Access, which incentivizes miners to store and serve data over time. This design ensures both data permanence and efficient network scalability.

IPFS: Content-Addressed, Distributed Storage

Overview

IPFS (InterPlanetary File System) is a peer-to-peer distributed file system that addresses data by its content rather than its location. Instead of retrieving a file from a specific server at a fixed URL, IPFS fetches content from any node in the network that is hosting it.

The Content Identifier (CID)

Every file or folder uploaded to IPFS is assigned a Content Identifier (CID) —a cryptographic hash of the file's exact contents. The CID ensures content integrity: if the file is modified in any way, the resulting CID will be completely different.

Example CID:

QmWvW2EZJrMgBqWniDLXgUHjE1XTzUFVhXfGpHQTZVq1oP

Key Characteristics

How It Works

IPFS operates using a Distributed Hash Table (DHT) to locate which nodes in the network are storing a specific piece of content. When a user requests a file by its CID, the network identifies peers hosting the file and retrieves it efficiently from multiple sources. This ensures redundancy and fault tolerance. To maintain availability, files must be "pinned" by at least one node on the network. Without pinning, files may eventually be garbage-collected and become unavailable.

Comparison: Arweave vs IPFS

Identifiers: TxID vs CID

Both Arweave and IPFS use unique identifiers that are critical for referencing content within SafePulse services like Verifiable Documents, the Document Registry, and the Asset Paywall.

Decentralized Storage in SafePulse

SafePulse integrates both Arweave and IPFS across its service suite, allowing users to choose the storage protocol that best fits their needs. The choice between them depends on the specific requirements of the use case:

• Verifiable Documents (Elysium): Arweave is recommended for legal and institutional documents requiring permanent, guaranteed availability.
• Document Registry: IPFS is well-suited for timestamping creative works, research drafts, and iterative versions.
• Asset Paywall: Both protocols are supported; creators can choose based on whether permanence or flexibility is prioritized.

By combining both protocols, SafePulse ensures users have access to the right storage guarantees—permanence when it is needed, and flexibility when it is preferred.

Best Practices

• For Permanent Records: Use Arweave for documents that must remain available and verifiable indefinitely, such as legal agreements, compliance records, and diplomas.
• For Versioned or Iterative Content: Use IPFS for content that may be updated, versioned, or where permanence is not a strict requirement.
• Always Keep a Local Backup: Even with decentralized storage, maintaining your own backup of critical files is a security best practice.
• Verify Content After Upload: Always retrieve and verify your file using its TxID or CID after uploading to ensure it is correctly stored and accessible.
• Treat Identifiers as Permanent References: The TxID or CID is the only way to retrieve your content. Store it securely alongside your document metadata.

Services

• Payment & Agreement
• Notarization & Verification
• Verifiable Credentials

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 Notarization & Verification

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.

Verifiable Credentials

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, safety 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. Verifiable Credentials (VCs)

Purpose: Provide decentralized, 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 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 and businesses alike.

Tutorials

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

Verifiable Document

Notarize documents on Blockchan: a tamper-proof, on-chain document verification contract with self-sovereign control.

Overview

Verifiable Documents allow users to create tamper-proof, document verification contracts. The actual file can be stored locally or on decentralized storage networks such as IPFS or Arweave, while its unique fingerprint is anchored on-chain. This provides an immutable proof of authenticity without exposing the document's contents.

Each document can be linked to a Pledge Contract, enabling automated enforcement of workflows and milestone payments based on document verification. All operations are executed via the SafePulse Wallet, ensuring self-sovereign, local execution.

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 a lack of independent verifiability.

The Verifiable Document service solves this by allowing users to anchor documents on-chain for immutability, link them to Pledge Contracts for enforceable workflows, and maintain full self-sovereign control over document storage and access. This ensures documents are trustworthy, verifiable, and usable in automated payment or contract scenarios.

Step-by-Step Tutorial

Prerequisites

Before you begin, ensure you have:

• A non-custodial wallet installed (e.g., MetaMask, Trust Wallet).
• An balanced Externally Owned Account (EOA) with an active subscription plan or sufficient usage credits.
• An Issuer/Creator DID: either a did:key or an ERC-1056 DID with the issuer key as its delegate.
• Network tokens (e.g., Pulse) in your wallet to pay for the deployment and initialization transactions.

A. Creating a Verifiable Document

This process creates the on-chain contract and initializes its state, making it ready for use and linking.

1. Upload your file to your chosen storage solution first. Copy the direct reference to the file:
   • IPFS: Upload the file and copy the Content Identifier (CID).
   • Arweave: Upload the file and copy the Transaction ID.
   • Centralized Host: Upload the file to your server or cloud storage and copy the direct download link.
2. Navigate to the Verifiable Document section in the application.
3. In the creation form, fill in the details:
   • Reference Identifier: Paste the file link, IPFS CID, or Arweave Transaction ID you copied.
   • Blockchain Network: Choose the network on which to anchor the document.
4. Tap the Create button, typically located at the top of the screen.
5. Confirm the deployment transaction in your wallet and wait for it to be minted.
6. After the transaction is successful, go to your History section.
7. Locate the document history record for the newly created contract.
8. Tap the More options menu and select Initialize and Setup.
9. Confirm the initialization transaction in your wallet. This step is crucial to finalize the contract's setup.
10. Once initialized, share the Verifiable Document DID from the transaction details with any relevant parties who need to verify or interact with it.

Document States & Lifecycle

Unlike the simple Document Registry, a Verifiable Document has a lifecycle that allows for management and linking to contracts.

Linked Contract Rules

When a Verifiable Document is linked to a Pledge Contract, its state directly affects the contract's workflow:

• For a Pledge Contract to move to Executed, the seller must sign on-chain in this Document Contract.
• For a Pledge Contract to move to Completed, the buyer must sign on-chain in this Document Contract.
• For a Pledge Contract to move to Canceled, this Document Contract must be in a suspended or revoked status.

Use Cases

• Education Certificates: A university issues a tamper-proof diploma as a Verifiable Document. Employers can instantly verify its authenticity on-chain without contacting the university.
• Contract Enforcement: A service agreement is defined in a Verifiable Document and linked to a Pledge Contract. Milestone payments are automatically enforced based on the document's completion and signing statuses.
• Intellectual Property: A creator timestamps a creative work or research paper to prove authorship and establish a verifiable priority date that is legally defensible.
• Legal Agreements: Critical legal agreements are made immutable and independently verifiable by all signing parties, eliminating disputes over document versions.

Benefits & Drawbacks

Benefits

• Tamper-proof and auditable: The on-chain hash provides an immutable proof of authenticity and existence.
• Integrates with Pledge Contracts: Enables automated enforcement of milestone-based payments and workflows directly tied to the document's state.
• Revocable and manageable: Unlike a simple registry, these documents have a full lifecycle (Active, Suspended, Revoked) that can be managed.
• Full self-sovereign control: The user maintains complete control over where the file is stored and who has access.

Drawbacks

• Requires management of decentralized storage: Users must ensure their chosen storage solution (IPFS, Arweave) remains accessible for long-term verification.
• Deployment has a cost: Network tokens are required for the Create and Initialize transactions. Creation may be limited to accounts with an active subscription plan or specific credits.

Best Practices & Tips

• Confirm your upload before creating: Double-check that the file is accessible and the link/CID is correct, as this identifier will be permanently anchored.
• Keep a local backup: In addition to your decentralized storage, always maintain your own secure backup of the original file. You are solely responsible for its availability.
• Link for enforcement: For any agreement involving payments or milestones, always link the Verifiable Document to a Pledge Contract to unlock automated enforcement.
• Use decentralized storage for long-term verification: IPFS and Arweave are preferred over centralized links that may break, ensuring the document can be verified forever.

Pledge Contract

Progressive settlements contracts with flexible milestone enforcement, conditional escrow, and on-chain guarantees.

Overview

A Pledge Contract is a non-custodial progressive escrow and settlement contract, 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, using different coins for payments and different parties for each payment.
• Verifiable Documents: For document verification, authentication, and binding.
• Agreement Encforcement settlements: Triggered by contract actions.

Context & Problem

Traditional contracts rely on manual signing, legal enforcement, banks, escrow providers, and administrative processes throughout their lifecycle, making them expensive and inefficient. Electronic signature services typically charge subscription fees, escrow services charge around 0.5–3% of the transaction value, bank transfers incur additional fees and delays, and legal disputes can cost thousands to tens of thousands of dollars while taking months or even years to resolve. Progress tracking, document version control, and payment verification are often handled manually, increasing operational costs, reducing transparency, and creating opportunities for disputes.

The Pledge Contract eliminates these inefficiencies by cryptographically binding documents to an immutable smart contract, automating contract enforcement and milestone verification, integrating on-chain escrow with automatic settlement, and maintaining a transparent, tamper-proof record of all deliverables and payments, resulting in lower costs, faster execution, and a trustless contracting system.

Step-by-Step Tutorial

Prerequisites

Before you begin, ensure you have:

• A non-custodial wallet installed (e.g., MetaMask, Trust Wallet).
• An active subscription or sufficient usage credits.
• An Issuer/Creator DID: either a did:key or an ERC-1056 DID with the issuer key as its delegate.
• Network tokens for contract deployment gas fees.
• (Optional) A Verifiable Document if the settlement will be linked to a document.

A. Creating a Pledge Contract

1. Navigate to the Pledge Contract section in your application.
2. Fill in the contract details:
   • Seller/Contractor/Issuer DID: Your decentralized identifier.
   • Contractee/Buyer Address: The recipient's wallet address.
   • Network and Token: Select the blockchain network and the token for payment.
   • Verifiable Document Contract DID: (Optional) Enter the DID of the document to bind to this contract.
3. Tap Create and approve the transaction in your wallet.
4. After the transaction is minted, go to the History section.
5. Locate the document history record for the newly created contract.
6. Tap the More options menu and select Initialize and Setup. Confirm the initialization transaction.

Important Notes:

• Unlike an Escrow, the Pledge Contract should be created by the seller. The contract's DID should then be shared with all other parties.
• Critical: Immediately after deployment, You must initialize the contract quickly to secure it and set up its rules.

B. Sharing the Contract DID with Parties

1. Go to the History section.
2. Find the "Issue" record related to your contract.
3. Tap the More button options menu and select Show Transaction Info.
4. Copy the DID from the transaction details and share it with the other party.

Pledge Contract Status Guide

This guide explains every state in the contract lifecycle, who can act, and what actions are permitted.

Linked Document Rules

If your contract is linked to a Verifiable Document, these additional rules apply:

• To move to Executed, the seller must sign on-chain in the Document Contract.
• To move to Completed, the buyer must sign on-chain in the Document Contract.
• To move to Canceled, the Document Contract must be in a suspended or revoked status.

Real-World Use Cases

Use Cases

• Employment & Contractor Agreements: Employment offers, onboarding documents, probation milestones, bonuses, or contract completion payments can all be managed through verifiable agreements with automated settlement.

• Freelance & Service Agreements: Clients lock cryptocurrency in escrow before work begins. Payments are automatically released as milestone deliverables are verified through Verifiable Documents.

• B2B Supplier Agreements: Businesses secure high-value crypto payments in escrow for manufacturing, shipping, and delivery milestones, ensuring suppliers are paid only after contractual obligations are fulfilled.

• OTC & Large Crypto Transactions: Buyers and sellers securely exchange large digital asset positions using on-chain escrow, eliminating counterparty risk and removing the need for trusted intermediaries.

• Cross-Border Business Payments: International companies settle contracts using stablecoins without relying on banks, enabling faster, lower-cost payments with transparent on-chain records.

• Crypto Mergers, Acquisitions & Asset Purchases: Large acquisitions of digital assets, protocols, domains, or businesses use escrow-backed contracts to ensure funds are transferred only after all contractual requirements are completed.

• Real Estate and Goods Transactions: Purchase agreements, rental deposits, or property transfers can use on-chain escrow, releasing funds only after all contractual documents and conditions are satisfied.

Tips & Best Practices

• Always attach a Verifiable Document detailing the scope of work, deliverables, and acceptance criteria to prevent misunderstandings.
• Break work into separate milestone contracts with required tokens. This reduces risk by allowing progressive payments and isolating disputes to a single milestone.
• Keep communication in-app where possible to maintain a transparent and traceable record linked to the contract.

Escrow

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

Overview

SafePulse Escrow is a trustless, non-custodial on-chain escrow service that securely locks funds until both parties meet agreed-upon conditions. Designed for buyers, sellers, freelancers, enterprises, and service providers, it eliminates fraud risks and intermediaries by delivering a secure, automated environment for global payments of any size.

With transparent fees and guaranteed neutrality, smart contracts hold the funds—neither SafePulse nor any third party can access them.

Context & Problem

Digital agreements frequently face payment fraud, delivery disputes, chargebacks, and a lack of trusted middlemen. Centralized escrow alternatives exist but introduce high fees (often 2–10%+), custodial risk, slow dispute resolution, and geographic restrictions.

SafePulse Escrow replaces intermediaries with automation, transparency, and cryptography. Funds are locked in smart contracts, and their status is always visible to both parties. Options for rollback, cancellation, and fund release are controlled entirely by the contract participants under safe, predefined conditions.

Step-by-Step Tutorial

Prerequisites

Before you begin, ensure you have:

• A non-custodial wallet installed (e.g., MetaMask, Trust Wallet).
• Network tokens available in your wallet to pay for gas fees.
• The payment token you intend to deposit must be approved for use with the escrow contract.

A. Approving Tokens for Escrow

Before making a deposit, you must grant the escrow smart contract permission to handle your chosen token.

1. Navigate to the Escrow in the Organize section in application.
2. Tap Approve Token.
3. Confirm the transaction in your wallet.
4. Wait for the approval transaction to be confirmed on the network.

Once approved, you are ready to make a deposit.

B. Creating an Escrow Deposit

1. In the Organize section, under the Escrow title, tap Approve (if you haven't already) or proceed to the deposit creation screen.
2. Enter the deposit details:
   • Recipient Address: The wallet address of the seller or payee.
   • Amount: The number of tokens to lock in escrow.
   • Expiration Date: The deadline after which the deposit can be rolled back by the sender if not released or frozen.
3. Select the correct Network and Token for the transaction.
4. Tap Deposit and confirm the transaction in your wallet.
5. After the transaction is successful, the new escrow record will appear in your History.
6. Copy the DID from the transaction details and share it with the other party so they can track the escrow.

C. Managing the Escrow: Release, Cancel, or Freeze

Once a deposit is made, authorized actions can be taken based on the agreement's progress.

Releasing Funds

Use this when all obligations have been met (e.g., work delivered, product received).

• Load the escrow DID.
• Tap Release and confirm the transaction.
• The escrow status will change to release, allowing the recipient to withdraw the funds.

Canceling a Deposit

Use this when conditions fail, a deadline passes, or both parties agree to cancel.

• Load the escrow DID.
• Tap Cancel and confirm the transaction.
• The escrow status will change to cancel, allowing the sender to rollback (withdraw) their funds.

Escrow Lifecycle & Status Guide

This guide details every state, its meaning, and the permissions granted to each party.

Fee Structure

SafePulse Escrow operates with a simple, transparent fee model:

• Deposit Fee: A flat fee paid in the network's native token to initiate the escrow.
• Withdrawal Fee: A flat 1% fee is deducted from the amount when the recipient withdraws released funds.
• No Subscriptions: No access tokens or recurring subscriptions are required.

This makes it cheaper and safer than centralized escrow, even for high-value deals.

Real-World Use Cases

• High-Value Contract Payment: A company locks a $50,000 payment. A developer delivers the project. The company verifies the work and releases the funds.
• P2P Purchase: A buyer deposits payment for a collectible. The seller ships the item. The buyer confirms receipt and releases the funds.
• Freelance/Gig Work: A client deposits funds for a design project. The freelancer completes the work and delivers the files. The client approves and releases the payment.
• Security Deposits & Rentals: A tenant deposits a rental security. At the end of the lease with no issues, the sender cancels the escrow and rolls back the deposit.

Benefits & Drawbacks

Benefits

• Safe for high-value and cross-border payments: Funds are cryptographically secured, not held by a company.
• Non-custodial and censorship-resistant: No third party can freeze, seize, or block your transaction.
• Transparent and automated lifecycle: Both parties can always see the exact on-chain status.
• Eliminates fraud and trust issues: Payment is verifiably locked before delivery.
• Simple, predictable costs: A flat deposit fee and a 1% withdrawal fee, with no hidden costs.

Drawbacks

• Requires blockchain familiarity: Users must understand how to use a non-custodial wallet and manage gas fees.
• Both parties must manage wallets: There is no account recovery service for lost private keys.
• No centralized resolution: A trusted third party cannot arbitrarily reverse a transaction; all outcomes are defined by the contract's rules and the parties' actions.

Document Registry

A lightweight, low-cost, on-chain proof-of-existence system for notarizing documents, research, IP, and digital work.

Overview

The Document Registry provides a fast, cost-efficient, and immutable method to notaize a document on blockchain in a non-custodial way. Upload your document from anywhere and make it permanently verifiable across hundreds of decentralized blockchain nodes. This keeps the process affordable while maintaining strong, verifiable guarantees.

It serves as a trustless, permanent anchor for any file that needs to be verified, making it ideal for protecting intellectual property, research, legal documents, design drafts, code, and more.

Context & Problem

Traditional document notarization is often expensive, slow, geographically limited, and dependent on centralized institutions. Records can be altered or lost. Creators and organizations need a way to prove authorship, establish priority, and timestamp content without revealing the full document or relying on a third party.

The Document Registry solves this by creating an immutable on-chain proof that a specific document—identified by its hash—existed at a given moment. This proof is cryptographically verifiable, permanent, and censorship-resistant.

Step-by-Step Tutorial

Prerequisites

Before you begin, ensure you have:

• A non-custodial wallet installed (e.g., MetaMask, Trust Wallet).
• A balance of the native network token to pay the registration fee.
• Issuer/Creator wallet account DID: either a did:key or an ERC-1056 DID with the issuer key as its delegate.
• The document file.

A. Registering a Document

1. Upload your file to an external storage location. You can use a decentralized option for long-term preservation or a direct link:
   • IPFS: Upload the file and copy the Content Identifier (CID).
   • Arweave: Upload the file and copy the Transaction ID.
   • Centralized Host: Upload the file to your own server or cloud storage and copy the direct download link.
2. tap on Document Registry.
3. In the creation form, paste the reference identifier you copied:
   • File Link / IPFS CID / Arweave Transaction ID: This points to the file's storage location.
4. Choose the target Blockchain Network for your registration.
5. Tap the Register button, usually located at the top of the screen.
6. Confirm the on-chain transaction in your wallet. This transaction pays the network fee and stores the file's hash and metadata.
7. Once the transaction is minted, go to your History section.
8. Locate the document history record for the new registration.
9. To share the proof of existence, copy the DID from the transaction details and provide it to any relevant parties.

There is no initialization step required—the record exists immediately after the registration transaction is confirmed.

How Verification Works

The Document Registry does not store your file. To verify a document against an on-chain record later, the original, unmodified file is required.

1. A verifier obtains the original file and the Document Registry DID.
2. The application hashes the file using the same cryptographic algorithm.
3. This hash is compared against the immutable hash stored in the registry record.
4. If the hashes match perfectly, it proves the file existed at the timestamp recorded on-chain and has not been altered since.

Warning: The proof relies on an exact content match. If even a single character or pixel in the file is changed, the hash will be different, and verification will fail.

Use Cases

• Intellectual Property Protection: An artist timestamps a new digital artwork, a writer records a novel draft, or a developer anchors a new smart contract to establish unalterable proof of creation priority.
• Research & Innovation: A scientist anchors early drafts of a paper before journal submission, proving their research was conducted before similar publications. Proprietary formulas and experiment logs can also be timestamped.
• Legal and Compliance: Timestamp an agreement before it is signed, anchor evidence documents, or record an immutable audit log of policy updates to prove a timeline of organizational changes.
• Enterprise Workflows: Securely document internal policy revisions and establish a verifiable chain-of-custody for off-chain events.

Benefits & Drawbacks

Benefits

• Extremely low-cost proof registration compared to any centralized notary service.
• Works instantly with minimal steps. No waiting, no intermediaries.
• Non-custodial data access: User full controled over file , preserving privacy.
• Immutable and verifiable forever: The record cannot be deleted or modified.
• No dependency on centralized notaries, governments, or platforms that could fail or censor.

Drawbacks

• Does not support multi controller: Only one controller handle the state.
• Limited signing only to verifier: Only seted addresses as verifier can sign and verify the document.
• Cannot attach: The record is a unary statement, not a dynamic document.

Best Practices

• Save the original file securely: The on-chain timestamp is worthless without the exact original file to verify against it. A hash cannot be reversed to recreate the file.
• Use decentralized storage for long-term preservation: IPFS and Arweave ensure the file remains accessible and unaltered indefinitely. Avoid relying solely on a centralized link that could break.
• Register early and often: If working iteratively, register key drafts and versions to create a timeline of your creative or research process.
• Upgrade for legal agreements: If your document requires formal multi-party signatures and a status lifecycle, use a Verifiable Document instead.

Verifiable Credentials

Privacy-preserving credentials compliant with W3C VC v2.0 and anchored to SafePulse.

Overview

SafePulse Verifiable Credentials (VCs) provide a secure, decentralized way to issue, verify, and present proofs of skills, achievements, education, compliance, licenses, membership, identity attributes, business records, or attestations.

VCs are tamper-proof and cryptographically verifiable. They are stored in the user's device (self-sovereign), portable across networks and platforms, and privacy-preserving through selective disclosure and verifiable presentations. Built on the W3C Verifiable Credential v2.0 standard, a VC is signed by the issuer's Wallet, held by the user device, and verifiable by any third party.

Context & Problem

Traditional credentials like certificates, licenses, and IDs are easy to forge, hard to verify internationally, and often reveal too much personal data. They require slow manual processes and are not portable across platforms.

SafePulse VCs solve this by being verified via blockchain and DID signatures, requiring no central authority. They support selective disclosure—revealing only what is necessary—and can represent any type of claim, from academic to corporate to legal. VCs integrate deeply with SafePulse's identity and document ecosystem, powering secure verification workflows.

Step-by-Step Tutorial

A. Receiving a Credential

This process stores a credential issued to you in your local wallet.

1. Open the SafePulse Lite dApp.
2. Navigate to Credentials.
3. Tap Load Credential.
4. Scan the QR code provided by the issuer, or paste the credential payload directly.
5. dApp will automatically verify:
   • The issuer's DID and its validity.
   • The cryptographic signature on the credential.
   • The credential's expiration date and revocation status (if applicable).
6. Once verification is successful, Credential will be loaded locally.

Your new Credential is now available in your dApp for future presentations or sharing.

B. Issuing a Credential

This process allows an authorized issuer to create and sign a new Verifiable Credential for a subject.

Prerequisites for Issuers

• Your issuer account DID must be created.
• You must have the necessary issuer permissions within your organization's workflow (for organization usecase's).
• (Optional) A pre-created Verifiable Document if you wish to attach additional files to the credential.

Steps

1. Navigate to the Credential tap on Create Credential button in the application and choose the New Credential.
2. Fill in the credential fields:
   • Type: Select the appropriate type, such as Certificate, Membership, License, or a custom type.
   • Subject DID: Enter the decentralized identifier of the person or entity receiving the credential.
   • Data Fields: Input the specific claims and attributes (e.g., course name, achievement level, compliance status).
3. (Optional) Attach a Verifiable Document if the credential requires supplementary proof or a linked document.
4. Tap Issue to create the credential.
5. Your wallet will sign the VC using your issuer DID's private key.
6. Share the completed VC with the subject using one of the available methods:
   • A QR Code for them to scan.
   • A Export/Import button if user wants to share the full credential file.

C. Presenting a Credential (Verifiable Presentation)

A Verifiable Presentation allows you, the holder, to share only the required parts of a credential, preserving maximum privacy.

1. Open the credential you wish to share from your wallet.
2. Tap the Present button.
3. Use the selection interface to choose only the specific fields you need to reveal to the verifier. Unselected fields will be hidden.
4. The dApp will generate a Verifiable Presentation that includes:
   • The selectively disclosed data.
   • A cryptographic proof of your DID authentication as the holder.
   • An on-chain anchor for proof integrity.
5. Share the generated presentation with the verifier via QR code or direct message.

D. Revoking a Credential (Optional)

If an issued credential needs to be invalidated, the original issuer can revoke it.

1. Navigate to the Issued Credentials section of your profile.
2. Select the specific credential you need to revoke.
3. Tap the Revoke button.
4. Confirm the revocation action, which will be signed with your issuer DID.

Once revoked, any future verification checks against this credential will show it as invalid.

Credential Structure (Simplified Example)

A VC is a JSON object containing the claims, the issuer and subject DIDs, and a cryptographic proof.

{
  "@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..."
  }
}

Use Cases

• Education & Certification: A university issues a digital degree as a VC. A student shares it with an employer, who verifies its authenticity instantly without contacting the school.
• Enterprise Compliance: An employee receives a "Certified AML Officer" credential. A financial institution verifies the employee's DID, the issuing company's DID, and the credential's integrity in seconds.
• Talent & Freelancing: A freelancer presents a verified work history or skill credential. A client validates their identity attributes without seeing any unnecessary personal details.
• Privacy-Preserving ID Checks: A user needs to prove they are over 18. They present a Verifiable Presentation from a government ID credential that reveals only the "Over 18" attribute, keeping their full name and address hidden.
• Web3 & DAO Reputation: A DAO issues a contribution-based VC to a member. On-chain tools read this VC to grant roles, voting rights, or access to gated channels.

Benefits & Drawbacks

Benefits

• Trustless and verifiable: Authenticity is proven by cryptographic signatures, not by trusting a platform.
• Self-sovereign: Credentials are stored in your wallet, not controlled by SafePulse or any other platform.
• Portable: Use your credentials across different applications, companies, and blockchain networks.
• Privacy-preserving: Selective disclosure and Verifiable Presentations allow you to share only the minimum necessary data.
• W3C Compliant: Global standard compatibility ensures broad interoperability.

Drawbacks

• User responsibility: You must safeguard your wallet and your credentials. Loss of a device or private key requires a secure backup to recover.
• Revocation requires active issuer: A credential can only be revoked if the original issuer maintains their DID and performs the action.
• Ecosystem adoption: Some external platforms may still rely on centralized or non-standard credential formats.

Best Practices

For Issuers

• Use a stable, persistent DID to ensure long-term verifiability of your credentials.
• Anchor your revocation registry on-chain so verifiers can always check the latest status.
• Avoid including unnecessary personal data in the credential itself; only put what is required for verification.
• Use credential types aligned with global schemas (like those from W3C) to improve interoperability.

For Holders

• Make secure, encrypted backups of your wallet and stored credentials.
• Always use Verifiable Presentations with selective disclosure to maximize your privacy.
• Keep your DID keys secure and follow best practices for key rotation.

For Verifiers

• Always check the DID signature on the credential and its validity timestamp.
• Verify the credential's revocation status against the issuer's registry before accepting it.
• Use standards-compliant VC parsers to ensure correct interpretation and best interoperability.

Asset Paywall

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

Overview

The Asset Paywall service allows creators, businesses, and developers to register a digital content delivery contract. It is designed to support digital content sales like media, PDFs, videos, and research, as well as premium memberships and one-time access models.

The service integrates deeply with the SafePulse ecosystem, using DIDs for identity and authorship. It works fully decentralized: issuers register a content delivery contract and retain sovereign ownership of their content. Customers approve the contract by making a payment and receive a content identifier in return. The platform does not take custody of funds or content at any point.

Context & Problem

Most content monetization platforms require central hosting, control creator accounts, and can censor or block content. They offer weak content protection and depend on fragile, credential-based logins. Creators need trustless payment and true ownership without relying on intermediaries.

SafePulse's Asset Paywall solves this by using smart-contract payments to deliver a content identifier after payment. It stores protected assets via decentralized links or secure URLs, uses DIDs instead of centralized accounts, and runs entirely from the user's wallet with no platform custody.

Step-by-Step Tutorial

A. Creating a Paywalled Asset

This process deploys a smart contract that governs access to your digital content.

Prerequisites:

• Your file must be uploaded and hosted before you begin. Choose one of:
  • IPFS: Upload and copy the CID.
  • Arweave: Upload and copy the Transaction ID.
  • Centralized Host: Upload and copy the direct download link.
• Your issuer DID must be initialized.
• You must have network tokens for the deployment transaction.

Steps:

1. Open the SafePulse dApp.
2. Navigate to the Asset Paywall section.
3. Choose the appropriate asset type for your content.
4. Configure your payment and asset details:
   • Issuer DID: Your decentralized identifier.
   • Network and Token: Select the blockchain network and the token you wish to be paid in (e.g., a stablecoin or native asset).
   • Price: Set the one-time purchase price in the chosen token.
   • Asset Name: Enter a descriptive name for your asset.
   • Content Reference: Paste the file link, IPFS CID, or Arweave Transaction ID.
5. Review the details and confirm the on-chain deployment transaction in your wallet.
6. Once minted, the Asset Paywall contract is deployed and active.
7. Share the asset's DID with potential buyers. This DID is their gateway to the paywall.

B. Purchasing Access to an Asset

This process is how a user pays to unlock content.

1. Open your SafePulse Wallet.
2. Scan the Paywall QR code provided by the seller, or paste the asset's DID directly into the dApp.
3. The wallet will display a content preview (if provided) and the purchase price.
4. Tap the Purchase button.
5. Your wallet will execute the payment transaction. This sends the exact amount to the paywall smart contract.
6. On successful transaction confirmation, your wallet automatically receives an access credential bound to your DID.
7. The content unlocks automatically, providing you with the content identifier (link, decryption key, etc.).

C. Managing Your Paywalled Asset

As the asset creator, you can manage your paywall contract from the Organize section.

• Navigate to your deployed Asset Paywall contract in your History or Dashboard.
• Access the management options (usually under More or a similar menu):
  • Freeze/Unfreeze Asset: Temporarily halt new purchases without deleting the contract.
  • Collect Payments: Withdraw accumulated funds from successful purchases to your wallet.
  • Delete Asset: Permanently deactivate the paywall contract.

Use Cases

• Paid Digital Content: A researcher sells a 200-page PDF hosted on IPFS. After a user pays, their DID is granted access to the file.
• Video Courses: A teacher uploads course videos behind a paywall. Students make a one-time purchase per course module.
• Premium Journalism: A journalist publishes a pay-per-article story. Readers pay once to unlock the full text.
• Photography & Art Packs: A designer distributes a set of high-resolution image files, protected by the paywall.
• Enterprise Reports: A business monetizes a proprietary research report and sells access directly to clients.

Benefits & Drawbacks

Benefits

For Creators:

• Low fees: Simple and predictable platform fees.
• No censorship: You have sovereign ownership, and your content cannot be delisted.
• Automated payments: Funds are sent directly to your wallet with no manual invoicing.
• Privacy-first: No KYC is required to monetize content.

For Users:

• No centralized accounts: Access is managed by your self-sovereign wallet and DID.
• Portable access: Your proof of purchase is tied to your identity, not a platform login.
• Verifiable proof of purchase: You have an on-chain record of your transaction.

Drawbacks

• Gas fees required: The creator must pay a network fee to deploy the contract, and users pay gas on the purchase transaction.
• Content hosting costs: The creator is responsible for the ongoing cost and maintenance of the file's storage (IPFS, Arweave, or centralized host).
• Contract-defined pricing: Changing the price or token typically requires deploying a new contract.
• User key security: Users must protect their local wallet keys to retain and prove their access rights.

Best Practices

• Always encrypt sensitive files before uploading them to any storage provider. The paywall controls access, but encryption adds a critical second layer of protection.
• Offer a low-cost or free preview to build trust with potential buyers. A preview can be a sample page, a trailer, or an abstract.
• Use decentralized storage for permanence: IPFS and Arweave ensure your content remains accessible as long as the network exists, making your paywall truly resilient.
• Clearly describe the asset: The asset name and any preview should accurately represent the final deliverable to reduce purchase disputes and build a strong reputation.
• Keep your issuer DID secure: This DID represents your brand as a creator. Losing control of it would impact your ability to manage contracts or prove authorship.

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 180 days'
Reason: The system enforces a maximum escrow duration limit of 180 days for all deposits.

Solution:

1. Review duration: Check your specified deposit duration
2. Reduce duration: Adjust the duration to 180 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 180-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

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 an 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 / Avalanche / 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.

Privacy Policy

Last updated: 4 Jun 2026

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 a decentralized escrow and settlement protocol that enables secure payments, conditional escrow, document notarization, and verification on-chain. By synchronizing agreements, verifiable documents, and fund transfers through smart contracts, SafePulse ensures that payments and settlements are executed only when predefined conditions are met.

2. Decentralized Architecture & Data Control

SafePulse operates using decentralized technologies, including blockchain networks, smart contracts, and user-controlled cryptographic systems.

SafePulse is designed so that users maintain control over their own identity credentials, cryptographic keys, and wallet access. SafePulse does not custody user assets, store private keys, or maintain centralized identity accounts.

Certain information generated through blockchain interactions, such as wallet addresses, transaction records, timestamps, and smart contract activity, may be publicly available on the relevant blockchain network. Such blockchain records are maintained by the network itself and cannot be deleted or modified by SafePulse.

Users are responsible for managing their own wallets, keys, and credentials. SafePulse does not have the ability to recover lost private keys or alter blockchain records.

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

The core ecosystem protocols and thier components are patent pending. All intellectual property rights are owned by the creator.

• 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.

• 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.

By accessing or using the Platform, you represent and warrant that you are not located in, resident in, or accessing the Platform from any restricted jurisdiction and that you are legally permitted to use the Platform under applicable law. We reserve the right to restrict, suspend, or terminate access to the Platform at any time if we reasonably believe you are in breach of this section.

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

14. Security Measures

SafePulse uses:

• Local encryption and decenrtalized identifiers mechanisms
• Decentralized architectures and secure cryptographic standards

However, no system is perfectly secure. Users must:

• Protect and backup contract DID's
• Do initialization after deployment soon as possible
• Understand the risk of DID loss and losing access to smart contracts

SafePulse do not have access to DID keys.

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: 4 Jun 2026

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 a decentralized escrow and settlement protocol that enables secure payments, conditional escrow, document notarization, and verification on-chain. By synchronizing agreements, verifiable documents, and fund transfers through smart contracts, SafePulse ensures that payments and settlements are executed only when predefined conditions are met.

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 copyright protected.

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.

Decentralized Operation & User Responsibility

SafePulse provides decentralized software infrastructure that enables users to interact with smart contracts, digital agreements, and blockchain-based settlement mechanisms.

SafePulse does not control, approve, monitor, verify, or guarantee:

• user-created agreements
• transactions between users
• the identity, behavior, or intentions of counterparties
• the accuracy of information submitted by users
• any off-chain activities, obligations, or representations made by users

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 DID's or their keys
• store wallet data in any form

If you lose your contract DID:

• SafePulse cannot restore access
• SafePulse cannot reset data
• access may be permanently lost or access be limited

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 contract DID
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.

Users are solely responsible for their own actions, decisions, transactions, and compliance with applicable laws and regulations.

Because SafePulse relies on decentralized technologies and smart contracts:

• SafePulse cannot unilaterally reverse blockchain transactions
• SafePulse cannot recover lost private keys, wallets, or digital assets
• SafePulse cannot modify smart contract states after execution
• SafePulse cannot force parties to fulfill off-chain obligations or agreements

Users acknowledge that they interact with SafePulse and its smart contracts at their own discretion and risk. SafePulse provides technical infrastructure only and does not act as an intermediary, agent, custodian, broker, legal representative, or guarantor of any user activity.

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:

SafePulse is operated by Hassan Qasemi, registered as a sole proprietorship in the Islamic Republic of Iran (registration No. 18892452). The software is protected by registered copyright (registration No. 8-107218-103731). The software has undergone conformity assessment (certificate No. 207518).

The core ecosystem protocols and thier components are patent pending. All intellectual property rights are owned by the creator.

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.

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

Eligibility and Restricted Jurisdictions

Access to and use of the Platform, including its decentralized application (dApp), smart contracts, interfaces, APIs, and any related services (collectively, the “Platform”), is strictly prohibited for individuals or entities located in, incorporated in, resident in, or accessing the Platform from any restricted jurisdiction.

Restricted jurisdictions include: Argentina, Australia, Bahrain, Canada, Costa Rica, Egypt, Estonia, France, Germany, India, Israel, Italy, Japan, South Korea, Kuwait, Lithuania, Pakistan, Poland, Qatar, Saudi Arabia, Ukraine, United Arab Emirates, United Kingdom, United States of America, Oman, Morocco, Romania ,and Syria.

By accessing or using the Platform, you represent and warrant that you are not located in, resident in, or accessing the Platform from any restricted jurisdiction and that you are legally permitted to use the Platform under applicable law.

We reserve the right to restrict, suspend, or terminate access to the Platform at any time if we reasonably believe you are in breach of this section.

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

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 operational tokens:

• ELYPS – an access credential token

• PULSE – an execution asset

  No stablecoin token is planned for launch yet.

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 of AssetPaywall

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 contract 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 contracts. Users remain responsible for their contract DID.

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
• Manual 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 contract DID?

SafePulse cannot recover lost DID's or DID keys. Users are fully responsible for securely storing and backing up DID.

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. Is SafePulse KYC/KYB compliant?

SafePulse is protocol-first, non-custodial, and on-chain, so KYC are not required.

25. Is SafePulse AML compliant?

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, safe transaction environment.

38 & 39. Who pays transaction pulse fees?

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

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 100% on-chain and KYC/KYB 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, 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 EVM compatible 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 DID and 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.