SafeGate / Fee Architecture Decision

Transparent 100 + 1 Verification Fee

SafeGate may use a transparent verification fee model: service amount plus a separate SafeGate verification fee. SafeGate does not process payments, does not custody funds, and does not act as escrow.

Fee Architecture Documented Split-Aware Non-Split Fallback Defined No Custody No Escrow No Postpaid Merchant Debt
Main Review Hub V13 Controlled Hardening V10 Submission Ready Public Fee Decision Doc

Core Decision

SafeGate charges for successful post-payment trust verification. This is not a payment processing fee, not escrow, and not custody.

100 Merchant service amount
+ 1 SafeGate verification fee
= 101 Buyer-visible total

No verified receipt, evidence, access unlock, or public verify until required payment and fee states are confirmed.

Where Split Is Supported

If the payment environment supports safe native split or audited non-custodial routing, the payment can be routed automatically.

Party Result
Buyer pays 101
Merchant receives 100
SafeGate receives 1

Where Split Is Not Supported

If native split is not available, including Pi if multi-recipient split is unavailable, SafeGate uses a separate verified fee payment.

Step Payment
1 Buyer pays merchant service amount
2 Buyer pays SafeGate verification fee
Final SafeGate verifies both before final trust state

Non-Split Verification Rule

In a non-split environment, SafeGate verification is not finalized until both required payments are backend-verified.

Flag Required State
merchantPaymentVerified true
safegateFeeVerified true

If either required payment is missing, pending, failed, ambiguous, mismatched, replayed, or unavailable, SafeGate does not finalize the verified outcome.

No Custody

SafeGate should not hold the full buyer payment and then redistribute funds.

No Escrow

SafeGate is not positioned as an escrow provider or dispute-holding payment intermediary.

No Veresiye

Postpaid merchant receivable or delayed manual settlement is not the primary fee model.

Pi-Specific Direction

SafeGate does not assume native Pi payment splitting. If Pi does not support native multi-recipient payment split, SafeGate should use the dual verified payment model.

  • Buyer pays merchant.
  • Buyer pays SafeGate verification fee.
  • Backend verifies both payment states.
  • SafeGate finalizes trust only after both are verified.

Future Programmable Chains

For EVM, Solana, or other programmable environments, SafeGate may later support non-custodial splitter/router logic.

  • Audited or reviewable
  • Minimal
  • Non-custodial
  • Transparent
  • Chain-specific
  • Separated from payment verification logic

What SafeGate Must Not Claim

  • Production readiness
  • Formal third-party audit
  • Security certification
  • Official Pi partnership
  • Pi Mainnet settlement if not live
  • Native Pi split if not supported
  • Custody
  • Escrow
  • Payment processing
  • Automatic deduction where split does not exist
  • All fee models solved across all chains

Current Safe Statement

SafeGate may use a transparent 100 + 1 verification fee model. Where native non-custodial split is supported, the fee can be routed automatically. Where native split is not supported, SafeGate uses a separate verified fee payment.

SafeGate does not finalize verified receipt, evidence, access unlock, or public verify until the required service payment and SafeGate verification fee are confirmed.

SafeGate never holds buyer or merchant funds.