Submission Process

The submission process is how asset owners provide information about their real-world assets for verification. It is a structured, multi-step form that collects device specifications, location data, financial projections, and supporting documentation.

Submission Form

The form is divided into logical sections that progressively collect deeper detail about the asset:

Step 1: Device Information

Basic identification of the physical asset or device being tokenized.

Field	Description	Example
Device Name	Model or product identifier	"AquaPure Water Purifier WP-3000"
Device Type	Category of the asset	"Water Purification System"
Manufacturer	Company that produced the device	"AquaPure Technologies"
Serial Number	Unique device identifier	"WP3000-2026-00142"
Installation Date	When the device was deployed	2026-01-15
Specifications	Technical specs (capacity, output, etc.)	JSON object with device-specific fields

Step 2: Location

Geographic and operational context for the asset.

Field	Description	Example
Address	Physical location of the asset	"Av. Comandante San Martin 1200"
City	City of deployment	"Arica"
Country	Country code	"CL" (Chile)
Coordinates	GPS latitude/longitude	-18.4783, -70.3126
Operational Zone	Regulatory jurisdiction	"Region de Arica y Parinacota"

Step 3: Financial Information

Revenue projections and cost structure for the asset.

Field	Description	Example
Estimated Revenue	Monthly/annual revenue projection	$2,400/month
Operating Costs	Recurring operational expenses	$800/month
Capital Expenditure	Initial investment cost	$15,000
Payback Period	Expected time to ROI	8 months
Revenue Model	How revenue is generated	"Per-liter water sales"

Step 4: Documents

Supporting evidence uploaded as file attachments.

Document Type	Purpose	Formats
Proof of Ownership	Legal ownership documentation	PDF, JPG, PNG
Installation Photos	Visual evidence of deployment	JPG, PNG
Technical Certifications	Safety or quality certifications	PDF
Financial Statements	Revenue or cost documentation	PDF, XLSX
Permits and Licenses	Regulatory approvals	PDF

Files are uploaded to Google Cloud Storage and referenced by URL in the submission record.

Submission States

Every submission follows a defined state machine:

DRAFT --> PENDING --> UNDER_REVIEW --> APPROVED --> (Certificate Issued)
                                   \-> REJECTED --> APPEAL --> UNDER_REVIEW

State	Description	Who Transitions
DRAFT	Submission is incomplete; user is still filling out the form	User (auto)
PENDING	User has submitted; awaiting validator review	User (submit action)
UNDER_REVIEW	A validator has picked up the submission	Validator (admin)
APPROVED	Submission passed review; certificate is issued	Validator (admin)
REJECTED	Submission did not pass review; reason provided	Validator (admin)
APPEAL	User disputes rejection; resubmitted for second review	User (appeal action)

State Transition Rules

• A submission can only move forward in the pipeline (no skipping states).
• DRAFT submissions are only visible to the owner.
• REJECTED submissions include a reason field explaining what was insufficient.
• APPEAL resets the submission back to UNDER_REVIEW for a fresh evaluation.
• Once APPROVED, the state is final and a certificate is generated.

Data Integrity

SHA-256 Hashing

Every submission produces a deterministic hash that serves as its fingerprint:

1. Canonical JSON normalization -- All submission fields are serialized into a canonical JSON format. Keys are sorted alphabetically, whitespace is stripped, and values are normalized (trimmed strings, consistent number formatting).

2. SHA-256 digest -- The canonical JSON string is hashed with SHA-256 to produce a 32-byte digest, represented as a 0x-prefixed hexadecimal string.

3. Immutability -- Once a submission moves to APPROVED, the hash is locked. Any modification to the underlying data would produce a different hash, making tampering detectable.

Submission Data --> Canonical JSON --> SHA-256 --> 0x-prefixed hash

The hash is used throughout the certificate and on-chain attestation pipeline. It serves as the unique identifier that links the off-chain data to the on-chain record.

Canonical JSON Format

The normalization process ensures that the same logical data always produces the same hash, regardless of field ordering or formatting differences:

{
  "deviceInfo": {
    "deviceName": "AquaPure Water Purifier WP-3000",
    "deviceType": "Water Purification System",
    "manufacturer": "AquaPure Technologies"
  },
  "financials": {
    "capitalExpenditure": 15000,
    "estimatedRevenue": 2400,
    "operatingCosts": 800
  },
  "location": {
    "city": "Arica",
    "country": "CL",
    "coordinates": [-18.4783, -70.3126]
  },
  "scores": {
    "environmental": 88,
    "financial": 85,
    "overall": 90,
    "regulatory": 92,
    "technical": 95
  },
  "wallets": {
    "owner": "GBDM6KRXXJHKVYFJPTPW3WBDKUYVCH7NNEI67DDCP7YX4UHX2GODPHGI"
  }
}

File Storage

Document attachments are stored on Google Cloud Storage with the following conventions:

• Bucket: Dedicated GCS bucket for validator uploads
• Path structure: submissions/{submissionId}/{documentType}/{filename}
• Access control: Files are private by default; accessible only through signed URLs generated by the backend
• Size limits: Individual files are capped to prevent abuse
• Supported formats: PDF, JPG, PNG, XLSX

Files are referenced in the submission record by their GCS URI. The frontend displays previews for images and download links for documents.

API Endpoints

The submission lifecycle is managed through the following API routes:

Method	Endpoint	Description
POST	/api/submissions	Create a new draft submission
PUT	/api/submissions/:id	Update a draft submission
POST	/api/submissions/:id/submit	Move from DRAFT to PENDING
GET	/api/submissions/:id	Get submission details
GET	/api/submissions	List user's submissions
POST	/api/submissions/:id/appeal	Appeal a rejected submission

Admin-only endpoints for validators:

Method	Endpoint	Description
GET	/api/admin/submissions	List all pending submissions
POST	/api/admin/submissions/:id/review	Start review (PENDING to UNDER_REVIEW)
POST	/api/admin/submissions/:id/approve	Approve with scores
POST	/api/admin/submissions/:id/reject	Reject with reason