Le moteur technique d’un Trade Finance importateur.

Le cœur technique devient TradeFinancePool.sol, pas MusharakahPool.sol.

La V8.2 ne peut plus utiliser un contrat nommé MusharakahPool.sol par défaut, car toutes les opérations import ne sont pas des Musharakah. Si l’importateur apporte uniquement son travail, son réseau et sa capacité de revente, la structure ressemble davantage à une Mudarabah Import. Si l’importateur apporte aussi du capital, elle peut devenir une Musharakah Import.

TradeFinancePool.sol
├─ MUDARABAH_IMPORT              // investisseurs = capital, importateur = travail / revente
├─ MUSHARAKAH_IMPORT             // investisseurs + importateur apportent du capital
├─ LOGISTICS_COSTS_INCLUDED       // logistique incluse dans l'opération import
└─ SCHOLAR_REVIEW_REQUIRED        // cas atypique ou marge / risque non standard

Base exécute les flux, HAQQ Ethiq certifie, ETHIGONE orchestre les preuves.

La stack V8.2 conserve la séparation fondamentale : Base porte les dépôts USDC, les verrous, les états de pool et les distributions ; HAQQ Ethiq porte la certification Shariah vérifiable ; ETHIGONE orchestre KYB, scoring, documents, inspection, paiement et settlement.

UTILISATEURS
Importateur · Investisseur · Fournisseur · Acheteur final · Inspecteur · Transitaire · Scholar · Admin
        │
        ▼
APPLICATION ETHIGONE
KYB/KYC · scoring · documents · débouché commercial · inspection · paiement · settlement
        │
        ├─────────────── Base — exécution financière ───────────────┐
        │   TradeFinancePool.sol                                    │
        │   TakafulReserve.sol                                      │
        │   FraudRegistry.sol                                       │
        │   CompanyTradePassport.sol                                │
        │   ReputationEngine.sol                                    │
        │   SupplierRegistry.sol                                    │
        │   BuyerCommitmentRegistry.sol                             │
        │   PaymentMilestoneEngine.sol                              │
        │   ImportSettlementEngine.sol                              │
        │   DefaultWorkflow.sol                                     │
        │                                                           │
        └─────────────── HAQQ Ethiq — certification ────────────────┘
            ShariahGateway.sol
            ShariahPolicyRegistry.sol
            ShariahCertificateRegistry.sol
            ShariahOracleProcess

Chaque module a une responsabilité simple, auditable et non mélangée.

Un dossier import doit relier acteur, marchandise, paiement, revente et preuve.

Le dossier technique ne doit pas seulement stocker une facture. Il doit relier toutes les preuves qui permettent de comprendre l’opération : qui achète, qui vend, qui revend, quelle marchandise, quel Incoterm, quels coûts, quelles preuves de paiement et quel revenu final.

ImportDeal
├─ dealId
├─ importerId
├─ supplierId
├─ buyerCommitmentId
├─ goodsCategory
├─ incoterm
├─ originCountry
├─ destinationCountry
├─ supplierInvoiceHash
├─ resaleCommitmentHash
├─ inspectionReportHash
├─ cargoXReference / eBLReference
├─ financedAmount
├─ importerCapitalContribution
├─ tabarruAmount
├─ shariahMode
├─ poolStatus
├─ milestoneStatus[]
├─ payoutProofs[]
├─ resaleCollectionProof
├─ settlementResult
└─ defaultStatus

Le pool doit avancer par états contrôlés, pas par décaissement libre.

Pour éviter les abus, chaque pool suit un cycle d’états. Les investisseurs déposent, mais les fonds ne sont utilisés qu’après validation des preuves et des jalons. L’importateur ne reçoit pas librement le capital.

DRAFT
  → KYB_PENDING
  → DOCUMENTS_UNDER_REVIEW
  → SHARIAH_REVIEW
  → APPROVED_FOR_FUNDING
  → FUNDING_OPEN
  → FUNDED_LOCKED
  → SUPPLIER_PAYMENT_PENDING
  → SUPPLIER_PAID
  → INSPECTION_PENDING
  → IN_TRANSIT
  → DELIVERED
  → RESALE_COLLECTION_PENDING
  → SETTLEMENT_READY
  → DISTRIBUTED

Cas négatifs :
  → REJECTED
  → SUSPENDED
  → DEFAULT_WORKFLOW
  → ICC_ARBITRATION
  → CLOSED_LOSS

Le parcours technique suit l’opération réelle, du dossier jusqu’à la distribution.

Le moteur Shariah choisit la structure selon les apports réels.

La qualification ne doit pas être décidée au hasard ou par marketing. Elle dépend de qui apporte le capital, qui supporte le risque, qui travaille, et comment les pertes sont traitées.

if importerCapitalContribution == 0:
    structure = MUDARABAH_IMPORT
    lossRule = investors bear capital loss except fraud / negligence / breach
    importerLoss = effort + reputation + contractual liability if fault

elif importerCapitalContribution > 0:
    structure = MUSHARAKAH_IMPORT
    lossRule = losses according to capital exposure
    profitRule = ratio agreed upfront

elif ethigoneBuysAndResells == true:
    structure = MURABAHA_REVIEW_ONLY
    action = Scholar Board + legal review required

else:
    structure = SCHOLAR_REVIEW_REQUIRED

Certains défauts ne réduisent pas le score : ils refusent directement le dossier.

Le score aide à décider, mais ne remplace jamais les critères bloquants.

Après les blocages, ETHIGONE calcule un score global 0-100. Ce score sert à orienter la décision : refus, revue manuelle ou éligibilité au financement.

if anyBlockingCriterion == true:
    decision = REJECTED
elif globalScore < 40:
    decision = REJECTED
elif globalScore >= 40 and globalScore <= 60:
    decision = MANUAL_REVIEW
else:
    decision = ELIGIBLE

ETHIGONE orchestre le paiement ; un partenaire régulé exécute la conversion et les virements.

Le smart contract verrouille les USDC, mais ETHIGONE ne doit pas devenir lui-même une banque ou un établissement de paiement. En Phase 1, la conversion USDC → fiat et les virements aux bénéficiaires doivent passer par un partenaire VASP/PSP validé.

Option recommandée Phase 1

1. Investisseurs déposent USDC dans TradeFinancePool.sol
2. Fonds verrouillés jusqu'à validation documentaire
3. Admin + contrôles déclenchent le décaissement
4. USDC transférés vers partenaire VASP / stablecoin payment provider
5. Conversion USDC → fiat si nécessaire
6. Paiement direct : fournisseur / inspecteur / transporteur / assureur
7. Preuve de virement récupérée
8. Hash de la preuve uploadé dans le Trade Passport
9. Validation manuelle avant étape suivante

Le fournisseur peut être payé par jalons, pas forcément en une seule fois.

Le paiement par jalons réduit le risque fournisseur. Selon le secteur, ETHIGONE peut payer une partie à la commande, une partie après inspection, puis le solde contre documents de transport ou preuve d’expédition.

Le profit est calculé seulement après encaissement réel.

Le settlement est le point sensible du modèle importateur. ETHIGONE ne distribue pas un profit théorique basé sur une facture ou une promesse. Le moteur de settlement attend une preuve d’encaissement réelle ou sécurisée.

Inputs settlement
├─ totalFinancedCosts
├─ importerCapitalContribution
├─ actualSupplierPaid
├─ actualLogisticsPaid
├─ actualInspectionPaid
├─ resaleAmountCollected
├─ nonDistributableFees
└─ profitShareRatios

profitDistribuable = resaleAmountCollected
                     - actualSupplierPaid
                     - actualLogisticsPaid
                     - actualInspectionPaid
                     - nonDistributableFees

if profitDistribuable > 0:
    distribute capital + profit according to pool rules
elif profitDistribuable == 0:
    return available capital only, no profit
else:
    trigger loss / default workflow

Le défaut doit être codé comme un workflow, pas traité au cas par cas.

Le défaut peut venir du fournisseur, de l’importateur, de l’acheteur final, de la douane ou d’un problème qualité. Le workflow doit distinguer retard simple, litige, fraude et perte économique normale.

DefaultWorkflow.sol

J+7
├─ relance importateur / fournisseur / acheteur final
├─ demande de preuve complémentaire
└─ statut WATCHLIST

J+14
├─ mise en demeure contractuelle
├─ suspension réputation
├─ gel nouvelle exposition
└─ revue comité risque + Scholar Board si nécessaire

J+30
├─ activation analyse Takaful si perte éligible
├─ ouverture procédure ICC si litige commercial
├─ inscription FraudRegistry si fraude documentée
└─ clôture perte si perte économique normale

Si la preuve Shariah devient indisponible, les nouveaux pools sont bloqués.

ShariahGateway.sol est le point de contrôle technique entre HAQQ Ethiq et Base. Il vérifie que le certificat est actif, que le contrat correspond au hash certifié et que le pont/oracle ne renvoie pas de données périmées.

if gatewayMode == PAUSED:
    block sensitive actions
if oracleStatus == UNAVAILABLE:
    block new pools
if bridgeDataIsStale == true:
    block new pools
if certificate.status == REVOKED:
    reject pool
if certificate.status == SUSPENDED:
    scholar review required
if bytecodeHash != certifiedHash:
    reject pool
else:
    allow next action

La certification HAQQ doit être un processus, pas un badge marketing.

ETHIGONE conserve un Scholar Board interne pour la première revue, puis HAQQ Ethiq sert de couche de certification indépendante, vérifiable et auditable.

Processus Shariah Oracle

1. ETHIGONE prépare le dossier technique et économique
2. Scholar Board interne valide ou refuse la structure
3. Le dossier validé est soumis au Shariah Oracle HAQQ Ethiq
4. Community Approval / revue de conformité HAQQ
5. Scholar Board HAQQ examine politique, contrat et version
6. Certificat / label SBT non transférable émis si validation
7. ShariahGateway.sol publie le statut : ACTIVE, SUSPENDED, REVOKED
8. TradeFinancePool.sol exécute uniquement si statut ACTIVE

La sécurité V8.2 doit couvrir les risques importateur, pas seulement blockchain.

Les intégrations doivent rester manuelles au début, puis devenir API en Phase 2-3.

La Phase 1 ne doit pas chercher le full automation. L’objectif est de prouver que le flux fonctionne avec de vrais dossiers, de vrais paiements et de vraies preuves. L’automatisation vient ensuite.

La V8.2 démarre semi-manuelle, puis automatise seulement ce qui est validé terrain.

Le MVP ne doit coder que le nécessaire pour prouver le modèle.