Praxifi documentation

Praxifi is a non-custodial financial policy infrastructure for digital wealth. The current public application supports MetaMask authentication, protected dashboard access, selected Base Mainnet portfolio visibility, HS-V1 diagnostics, policy configuration and review, and status/history views.

• Product status: live web application with operational application-level functionality.
• Current public policy path: Base Mainnet, chain ID 8453.
• Version 1 focuses on owner-authorized policies, not investment management or legal inheritance determination.
• Base Mainnet contract deployment is internally documented; independent audit evidence and sustained real-funds operation are not claimed.

Users connect MetaMask, sign a scoped authentication message, review Base Mainnet configuration, inspect supported assets, and create policies only after reviewing authorization requirements.

• Supported wallet path: MetaMask wallet connection.
• Authentication: backend nonce, wallet signature, server-side verification, and protected session.
• Wallet login does not authorize asset movement.
• Users should confirm Base Mainnet, wallet address, supported token balance, recipient, amount, and allowance before activation.
• Cancelling a policy depends on policy type, current state, and available cancellation controls.

Portfolio visibility is limited to Base assets currently supported by Praxifi. Portfolio visibility is not the same as automation eligibility.

• Current visibility may include Base native ETH and selected registered Base ERC-20 assets.
• Examples currently include USDC, USDT, and WETH where registered and readable.
• Complete arbitrary ERC-20 enumeration is not claimed.
• Automation eligibility is limited to USDC and USDT.
• WETH may appear in diagnostics but remains blocked from current automation execution.

Portfolio Healthiness is experimental, heuristic, deterministic, versioned, diagnostic, non-predictive, non-advisory, not a suitability assessment, not a credit rating, and independently unvalidated.

• HS-V1 uses ten weighted categories totaling 10.00.
• Normalized score = 10 x weighted assessed contribution / assessable weight.
• Minimum assessable weight is provisionally 6.0, but it is heuristic and not a scientific boundary between good and bad portfolios.
• Missing evidence must not automatically become a risk score.
• Confidence reflects coverage, freshness, provider consistency, asset identification, historical availability, and security-data availability.
• Confidence is not a probability that the score is correct.

A financial policy is a narrow, owner-authorized instruction with defined parameters, lifecycle state, cancellation boundaries, eligibility checks, execution evidence, and fees only after a defined successful billable execution.

• Policy parameters include owner, network, token, amount, recipient, condition, timing, and cancellation rights where supported.
• Authorization requires wallet ownership and supported token approval where applicable.
• Lifecycle states separate draft, active, cancelled, pending execution, submitted, confirmed, failed, and refundable states where implemented.
• Execution must match the original authorized policy parameters.

Scheduled Transfer lets an owner configure a supported stablecoin transfer for a selected future execution time, subject to approval, eligibility, cancellation, and execution evidence.

• Current automation-eligible assets: USDC and USDT.
• The user reviews token, amount, recipient, and execution time before activation.
• Failure conditions include missing approval, insufficient balance, unsupported token, cancellation, RPC failure, finality delay, or configuration mismatch.
• Fee: 0.5%, capped at USD 3, after defined successful billable execution.

Basic Inheritance is an inactivity-triggered technical continuity policy. It does not prove death, incapacity, identity, lawful heirs, or legal entitlement.

• The owner selects a designated recipient and inactivity condition.
• Activity confirmation can renew or cancel the inactivity path where supported.
• A designated recipient is not automatically a legal beneficiary.
• Fee: 0.75%, capped at USD 25, after defined successful billable execution.

Refundable Inheritance adds an acceptance, refund, waiver, release, expiry, and shutdown lifecycle around a contract-controlled escrow-like state. It is implemented and internally tested, but requires separate legal and operational qualification.

• The beneficiary acceptance flow must be validated before the refundable lifecycle progresses.
• Owner refund returns control through the approved lifecycle path where conditions permit.
• Beneficiary claim and owner refund paths are separate state transitions.
• Fee: 1.0%, capped at USD 49, after defined successful billable execution.

Activity Confirmation is a Product signal used to show that the wallet owner is still active. It is not death proof, incapacity proof, identity proof, or a legal beneficiary determination.

• Current behavior relies on wallet authority and application-level confirmation.
• Password-assisted check-in may help user experience but does not recover keys.
• Replay protection, scoped messages, and chain/domain consistency remain security requirements.
• Gasless check-in remains a research boundary unless separately verified.

Praxifi separates user wallet authority, frontend review, backend coordination, smart-contract constraints, technical executor submission, Worker/Poller operations, data providers, RPC providers, notifications, audit records, and reconciliation.

• The user wallet remains the source of ownership and approval authority.
• The frontend explains and collects policy parameters; it must not hardcode contract addresses outside shared registries.
• Backend services coordinate sessions, policy records, observability, and eligibility.
• Smart contracts constrain execution to authorized parameters.
• Worker and Poller services remain operational infrastructure with PARTIAL maturity.

Current project records identify Base Mainnet deployments for the Version 1 policy contracts. Deployment is not an independent audit and does not alone establish sustained Production operation.

• PraxifiInactivityExecutorV2: 0x29c6efF6D4f2687568e77E6CAA34102C92b07552
• PraxifiRefundEscrow: 0x4A0f710cEE41E1987E0f5B6601Bf1Fd229d78b82
• PraxifiScheduledTransfer: 0x35874Fd2bF16d0C7D2430BcBAae5D10547F83A56
• Network: Base Mainnet, chain ID 8453.
• Polygon policy deployment is not established in this release.
• Independent smart-contract audit is not claimed.

Execution operations include candidate selection, eligibility checks, transaction submission, idempotency, finality, retry, reconciliation, history, notifications, incident handling, gas monitoring, and executor balance monitoring.

• Worker/Poller maturity remains PARTIAL.
• Sustained Production operation, failover, SLOs, and real-funds runtime are not independently verified.
• Failed or skipped attempts should not create a Praxifi service fee.
• Execution history distinguishes submitted, provisional, finalized, failed, and cancelled evidence where supported.

Security is based on least privilege, owner-authorized material parameters, cancellation and renewal where available, single execution, idempotency, evidence, and explicit acknowledgement that non-custodial design does not remove risk.

• Praxifi does not receive private keys or general wallet authority.
• Approvals should be understandable and limited to supported policy requirements.
• Audit, security events, execution proofs, and monitoring are observability layers, not guarantees.
• Security-related reports: praxifi.official@gmail.com

The public threat model groups risks across user wallets, execution infrastructure, smart contracts, token behavior, pricing/data providers, and operations.

• User / Wallet: wallet compromise, wallet loss, recipient-address error, malicious frontend, session hijacking, password compromise, signature replay, chain/domain mismatch.
• Execution: executor-key compromise, executor censorship, executor downtime, Worker failure, Poller failure, RPC failure, RPC inconsistency, chain reorganization, insufficient finality, gas shortage, duplicate execution.
• Smart Contract: contract vulnerabilities, approval misuse, unlimited allowances, timestamp assumptions, upgrade authority, pause authority.
• Token / Stablecoin: issuer freeze, blacklist, pause, depeg, token incompatibility, decimals, rounding, fee-on-transfer, rebasing, non-standard behavior.
• Pricing / Data: oracle manipulation, stale pricing, provider poisoning, incomplete portfolio data.
• Operations: notification failure, service shutdown, dependency compromise, privacy leakage, treasury compromise, gas-price spike.

Praxifi uses an execution-fee model for supported policies. There is no subscription, native Praxifi token, or separate payment gateway required for the current model.

• Gross amount = net recipient amount + service fee.
• Fee is intended to settle from transferred principal.
• Fee applies only after the defined successful billable execution.
• Gas and external costs remain separate.
• Pricing, depeg, and oracle Production specifications remain qualified.

The current public network is Base Mainnet, chain ID 8453. Polygon is planned Version 1 scope, not current deployed policy availability.

• Portfolio visibility: Base native ETH and selected registered Base ERC-20 assets.
• Portfolio examples: USDC, USDT, WETH.
• Automation eligibility: USDC and USDT only.
• WETH and unsupported assets are not currently automation eligible.
• Unknown assets and complete arbitrary ERC-20 wallet enumeration are not claimed.

Praxifi documentation describes technical controls and Product boundaries. It does not determine legal classification, compliance, entitlement, succession, tax treatment, or cross-border availability.

• Technical control is not the same as legal ownership.
• Technical execution is not the same as legal entitlement.
• Inactivity is not death or incapacity proof.
• Designated recipient does not mean lawful beneficiary.
• Custody, safeguarding, payment/transfer-service exposure, crypto-asset service classification, AML/CFT/sanctions, consumer protection, privacy, tax, reporting, and cross-border availability remain jurisdiction-specific uncertainties.

Status labels separate public availability, application operation, internal testing, local-chain validation, Mainnet deployment, Mainnet operation, independent validation, and unsupported future scope.

• Live means publicly accessible at application level, not Mainnet or Production readiness.
• Mainnet deployed means a specified contract exists on the stated Mainnet; it does not imply sustained safe operation.
• Independent audit completed is not claimed in this release.
• Mainnet operational is not claimed unless separately supported by evidence.

Praxifi has explicit Product boundaries that should remain visible in public documentation and user-facing copy.

• Does not recover, recreate, or custody private keys.
• Does not prove death, incapacity, identity, lawful heirs, or legal inheritance.
• Does not guarantee execution, returns, safety, or portfolio improvement.
• Does not manage investments or automatically execute investment advice in Version 1.
• Does not support every wallet, token, or network.
• Does not claim independent validation, independent smart-contract audit, or global legal compliance.

The roadmap should help readers understand future direction without presenting future phases as currently available.

• Phase 1: Public Release and Evidence Maintenance.
• Phase 2: Mainnet Operational Verification.
• Phase 3: Refundable Continuity Hardening.
• Phase 4: Financial Policy Engine.
• Phase 5: Advanced Portfolio Intelligence and Capital Allocation Research.

PraxiHub may inform and challenge Praxifi assumptions, but it is not a regulator, auditor, certification body, legal authority, or automatic independent verifier.

• Digital Asset Continuity: practical access and intent execution for digital assets.
• Autonomous Wealth: owner-authorized policies rather than unrestricted automation.
• Rule-Based Finance: narrow rules with understandable parameters.
• Resilient Financial Infrastructure: monitoring, evidence, failure handling, and recovery boundaries.
• Programmable Portfolio Intelligence: diagnostics that explain data without becoming advice.
• Capital Allocation Research: future research, not current investment-management functionality.

Documentation terminology should preserve the Whitepaper's qualifications and avoid turning technical labels into legal or financial claims.

• Owner: wallet user authorizing a policy.
• Designated Recipient: technical recipient selected by the owner; not automatically a lawful beneficiary.
• Technical Transaction Executor: infrastructure allowed to submit eligible transactions within contract constraints.
• Financial Policy: a narrow owner-authorized rule for a defined digital-asset action.
• Continuous Ownership: continued user authority and activity signaling, not legal proof.
• Digital Asset Continuity: practical continuity of digital-asset access and intent execution.
• Basic Inheritance: inactivity-triggered technical transfer policy.
• Refundable Inheritance: refundable continuity lifecycle with escrow-like contract-controlled state.
• Check-in: activity confirmation signal.
• Exact Allowance: approval sized to the required policy amount where supported.
• Coverage: portion of portfolio evidence available for assessment.
• Confidence: data-quality signal, not probability of correctness.
• Production Verification: evidence that a deployed system is operating under defined controls.

Use the official Praxifi email for general contact and security-related reports. This does not imply continuous support coverage or a dedicated security response team.

• General contact: praxifi.official@gmail.com
• Security-related reports: praxifi.official@gmail.com