Skip to content

Digitalia Marketplace Submission Operations Manual

Version: 1.0
Last updated: 2026-05-15 (UTC)
Audience: Marketplace operators, approvers, administrators, and support staff

1. Purpose

This manual defines the operational process for handling Digitalia Marketplace developer submissions from intake through final decision.

It covers: 1. Submission intake and queueing behavior 2. Approval and rejection workflow 3. State transitions and operator actions 4. Audit, escalation, and service-level handling

2. Scope

This process applies to all Marketplace submissions received through the Digitalia Passport developer flow.

Network policy: 1. Digitalia PoA Mainnet (chain ID 1): approval required before publication 2. Digitalia Testnet (chain ID 11): approval required before publication 3. Digitalia-controlled government networks: approval required before publication 4. Other non-controlled networks: standard registration path, no operator queue requirement

3. Approval States

The submission lifecycle uses the following canonical states:

  1. SUBMITTED_FOR_DIGITALIA_APPROVAL
  2. UNDER_DIGITALIA_REVIEW
  3. APPROVED_BY_DIGITALIA
  4. REJECTED_BY_DIGITALIA

Operational meaning: 1. SUBMITTED_FOR_DIGITALIA_APPROVAL: submission captured and queued, no publication 2. UNDER_DIGITALIA_REVIEW: assigned to reviewer and actively evaluated 3. APPROVED_BY_DIGITALIA: approved for publication/deployment 4. REJECTED_BY_DIGITALIA: rejected with reason code and required remediation guidance

4. Intake Requirements

A valid submission must include:
1. DApp identity metadata
name, category, description, website URL
2. Commercial agreement selection
one of 1% self-build, 30% Digitalia-build, Joint Venture
3. Terms acceptance hash
deterministic hash for accepted marketplace terms payload
4. Network context
source network name and chain ID

If any required field is missing, mark as INVALID_INTAKE and request resubmission.

5. Operator Workflow

Step 1: Queue Intake

  1. Confirm record appears in approval queue storage.
  2. Verify state = SUBMITTED_FOR_DIGITALIA_APPROVAL.
  3. Validate metadata completeness and hash format.

Step 2: Assign Review

  1. Assign reviewer based on category and risk profile.
  2. Move state to UNDER_DIGITALIA_REVIEW.
  3. Record assignment timestamp and operator ID.

Step 3: Compliance and Security Review

Review checklist:
1. Functional accessibility
declared URL resolves and app is reachable
2. Content and policy compliance
no prohibited, fraudulent, or malicious content
3. Contract and network claims
declared behavior matches app/network declarations
4. Agreement consistency
commercial model is clear and internally consistent
5. Terms hash integrity
hash present and bound to submission context

Step 4: Decision

Approval criteria: 1. All checklist controls pass 2. No unresolved critical/high risk issue 3. Agreement and terms evidence valid

If approved: 1. Set state = APPROVED_BY_DIGITALIA 2. Publish via standard listing path 3. Emit approval audit event

If rejected: 1. Set state = REJECTED_BY_DIGITALIA 2. Attach rejection reason code and remediation notes 3. Notify submitter with exact required corrections

6. Rejection Reason Codes

Use one or more standard codes: 1. R001_INVALID_METADATA 2. R002_UNREACHABLE_APPLICATION 3. R003_POLICY_NON_COMPLIANCE 4. R004_SECURITY_RISK 5. R005_MISMATCHED_NETWORK_OR_CONTRACT_CLAIMS 6. R006_INVALID_TERMS_HASH 7. R007_AGREEMENT_INCONSISTENCY

All rejections must include: 1. human-readable explanation 2. minimal remediation steps 3. allowed resubmission path

7. Service Level Targets

Target response windows:
1. Intake acknowledgement: within 15 minutes
2. Initial triage: within 4 hours
3. Review completion:
normal risk within 2 business days
elevated risk within 5 business days 4. Rejection remediation follow-up: within 1 business day after resubmission

8. Escalation Path

Escalate to governance/security leads when: 1. suspected legal or sanctions issues 2. malicious code indicators 3. impersonation of regulated entities 4. unresolved high-severity risk beyond SLA

Escalation levels: 1. L1 Operations reviewer 2. L2 Marketplace governance lead 3. L3 Security and policy authority

9. Audit and Retention

For each decision, retain: 1. submission payload snapshot 2. agreement selection 3. terms acceptance hash 4. reviewer decision log and reason code(s) 5. final state and timestamps

Retention baseline: 1. approval/rejection records retained for 24 months 2. security escalations retained for 36 months minimum

10. Incident Handling

If an approved app is later found non-compliant: 1. suspend listing immediately 2. create incident record with severity 3. notify submitter and internal governance owner 4. require corrective action before reinstatement

11. Operations Runbook Quick Actions

  1. New queue item received
    Validate intake, assign reviewer, set UNDER_DIGITALIA_REVIEW
  2. Approval granted
    Set APPROVED_BY_DIGITALIA, publish, log audit event
  3. Rejection issued
    Set REJECTED_BY_DIGITALIA, attach reason code, notify submitter
  4. Dispute opened
    Freeze listing transition, escalate to governance lead

12. Change Control

Changes to this manual require: 1. operations owner approval 2. governance sign-off for policy/state model changes 3. documentation publication in docs.juro.net prior to enforcement date