TermiNode: Building a Verifiable GIS Proof Layer on the Internet Computer
Maps usually show us the current shape of a region, boundary, service area, asset corridor, or infrastructure record.
But in real operations, the important questions rarely stop at “what does the map show right now?”
For a municipality, utility operator, insurance review team, logistics system, infrastructure partner, or audit workflow, the deeper questions are usually:
Which geometry was valid at that time?
Who changed it?
What did the previous version look like?
Which dataset did this record belong to?
Which query was executed against which boundary?
Can the same result be inspected again later?
Can a customer, public stakeholder, technical team, or auditor receive the same evidence package?
TermiNode is being built for those questions.
TermiNode is a GIS infrastructure and verifiable spatial proof-layer DApp running on the Internet Computer.
Live DApp: https://terminode.io
Map and evidence screen: https://terminode.io/#map
Developer docs: https://terminode.io/#docs
Pilot package: https://terminode.io/#pilot
Whitepaper: https://terminode.io/#whitepaper
MVP readiness: https://terminode.io/#mvp-readiness
GitHub: https://github.com/developertugrul/terminode
TermiNode is not trying to replace everything existing GIS products already do well. ArcGIS, Mapbox, GIS Cloud, QGIS, and similar tools are strong at mapping, basemaps, tiles, routing, field workflows, search, analytics, and broader location-platform capabilities.
TermiNode’s focus is narrower:
Make spatial records more accountable by preserving their history, current state, query context, proof receipts, and exportable evidence.
In short:
A map shows the current state. TermiNode makes that state verifiable.
Why This Matters
GIS data is often treated as a visual layer. A polygon is drawn, a layer is loaded, and a map displays the result.
That is useful, but it is not always enough.
When operations become more serious, spatial data stops being just something to display. It becomes a record that may need to be reviewed, defended, exported, compared, and trusted.
For example:
- If a service zone changes, why should the previous version remain inspectable?
- If an outage region or response boundary is updated, how can a team show who accepted the change?
- If a logistics system checks whether a delivery point falls inside a compliance zone, how can that decision be reviewed later?
- If an insurance or infrastructure review depends on a boundary file, can the same evidence be reproduced after the case is closed?
- If a public-sector or utility team needs to explain a spatial decision to stakeholders, can it provide more than a screenshot?
Traditional map viewers are not always designed for these proof-heavy workflows.
The need here is not only to draw a map. The need is to manage spatial state, preserve version history, support bounded reads, expose an audit trail, generate proof receipts, and leave portable evidence behind.
That is the product gap TermiNode is exploring.
What TermiNode Provides Today
TermiNode is live today as a technical pilot MVP.
The main product surface is an ICP asset-canister-hosted DApp available at:
The current MVP focuses on a Municipal / Utility pilot story because service zones and infrastructure boundaries are easy to understand and naturally proof-sensitive.
Today, the product demonstrates the following surfaces.
1. Dataset and Feature Model
TermiNode organizes spatial records around datasets and features.
A dataset can be understood as a layer, collection, or operational record group.
A feature is a spatial record inside that dataset, such as a polygon, multipolygon, service zone, compliance boundary, maintenance corridor, or other proof-worthy geometry.
2. Versioned Geometry
When a feature changes, the previous state should not silently disappear.
TermiNode is designed so geometry updates can produce durable version history. This makes it possible to inspect the current geometry, previous versions, timestamps, owner context, and metadata changes.
3. Bounded Reads
Instead of reading everything everywhere, TermiNode favors bounded access patterns:
- Viewport reads
- Bounding box queries
- Dataset-scoped queries
- Pagination
- Feature-level inspection
- Exportable snapshots
This matters for performance, data discipline, and operational review.
4. Audit Trail
Spatial records often need more than a map preview.
TermiNode surfaces audit context so a user can inspect how a record changed, what the current geometry is, which dataset it belongs to, and how it can be packaged for review.
5. Proof Receipts
High-value location checks can be escalated into proof workflows.
A proof receipt provides a portable record of a verification path, making it easier to explain what was checked, against which context, and why the output matters.
6. Evidence Export
TermiNode is not only about showing data on screen.
The product is designed around exportable evidence: snapshot JSON, checksum references, proof receipts, feature history, and audit context.
Map and evidence screen:
7. Developer Documentation
Technical users can inspect Candid methods, import paths, production boundaries, REST / OGC adapter notes, MCP support, and canister references inside the DApp.
Developer docs: https://terminode.io/#docs
SDK / REST / OGC adapter notes: https://terminode.io/#docs-sdk
MCP docs: https://terminode.io/#docs-mcp
8. MCP Support
TermiNode includes a read-only MCP server for agent-ready GIS proof-layer context.
This means an AI agent can inspect dataset lists, bounded GeoJSON, feature versions, audit events, snapshot checksums, location verification context, and operational metrics without receiving write, market, custody, token-transfer, or governance permissions.
MCP is especially useful for:
- Support triage
- Pilot review
- Dataset discovery
- Audit checks
- Proof package review
- Internal operator summaries
- Read-only location verification context
MCP docs:
https://terminode.io/#docs-mcp
Why Build This on the Internet Computer?
TermiNode’s main frontend is hosted through an ICP asset canister.
That means the canonical DApp is served from Internet Computer infrastructure rather than being treated as a normal externally hosted web app.
Main DApp:
Production asset canister:
mihrj-waaaa-aaaam-qi6ma-cai
TermiNode currently uses these main canister surfaces:
-
frontend_assets: the canonical DApp surface served at terminode.io -
spatial: datasets, features, versions, audit events, bounded GeoJSON reads, snapshots, write fees, and quota policy -
oracle_gateway: coordinate verification, proof receipts, proof metrics, and premium verification paths -
trmg_ledger: ICRC-style utility ledger for TermiNode product operations -
governance: controlled product evolution and operational governance -
mcp-server: read-only stdio server for agent-ready dataset, audit, snapshot, and metrics context
Mainnet references:
- DApp asset canister:
mihrj-waaaa-aaaam-qi6ma-cai - Spatial canister:
ov27b-fiaaa-aaaam-qi6dq-cai - TRMG ledger canister:
os3zv-iqaaa-aaaam-qi6da-cai - Governance canister:
ncitt-uqaaa-aaaam-qi6la-cai - Oracle gateway canister:
nfjvh-ziaaa-aaaam-qi6lq-cai
The goal is not to move every application workflow on-chain.
The better design is selective.
Everyday application state, private CRM records, internal notes, high-volume search, dashboards, payment records, and personal data can remain in conventional infrastructure.
TermiNode is most useful where accepted spatial state, geometry history, proof receipts, audit events, and exportable evidence need to become independently inspectable.
How an Application Can Use TermiNode
Using TermiNode does not mean rewriting an entire application as a blockchain app.
A practical integration starts with one proof-worthy spatial record type.
Examples:
- Municipal service zones
- Utility boundaries
- Compliance zone polygons
- Maintenance corridors
- Outage regions
- Emergency response areas
- Insurance claim boundaries
- Public works layers
- Zoning samples
The next step is to define why that record needs a proof layer.
A good pilot question is:
If this geometry becomes important six months from now, what evidence package should we be able to inspect?
A TermiNode-based workflow can then look like this:
1. Create a Dataset
A dataset is created for a layer or operational collection, such as “Municipal Utility Service Zones”.
2. Import Features
Features can be added using formats such as GeoJSON or WKB.
The cleanest path starts with EPSG:4326 coordinates, validated polygon geometry, and a clear metadata schema.
3. Update One Feature
A pilot becomes more convincing when at least one feature has a visible before-and-after history.
This demonstrates versioning, auditability, and review value.
4. Run Bounded Queries
The map or application requests only what it needs, such as a viewport or bounding box.
5. Inspect Audit and Version History
The operator or reviewer can inspect current geometry, previous versions, owner context, and audit information.
6. Generate a Proof Receipt
A high-value location or boundary check can be escalated into a proof workflow.
7. Export Evidence
The pilot can produce snapshot checksums, audit context, proof receipts, feature history, and export JSON.
The current product surface for this workflow is:
The First Pilot Story: Municipal / Utility Records
The first vertical focus for TermiNode is Municipal / Utility.
This is intentional.
A service zone is not just a blue polygon on a map. It can affect who receives service, which team is responsible for a region, how an outage response is coordinated, and which spatial context was used when a decision was made.
For a Municipal / Utility pilot, TermiNode can demonstrate:
- A sample utility service zones dataset
- 3-5 polygon features
- One feature update
- Version comparison
- Current geometry and previous geometry
- Audit trail
- Proof receipt
- Dataset snapshot checksum
- Evidence JSON export
- Developer docs for Candid / GeoJSON / adapter paths
Pilot package:
A good first pilot does not need to be broad.
In fact, it should be narrow.
The first milestone is to prove the value of one important spatial layer.
The key question:
When this record becomes important, will the team have only a map screenshot, or will it have an inspectable spatial evidence package?
MCP: Agent-Ready GIS Proof Context
MCP support is an important part of the TermiNode direction.
The TermiNode MCP server makes proof-layer context available to AI agents, but it does so with a strict read-only posture.
The agent does not receive tools for:
- Dataset creation
- Geometry editing
- Token transfer
- Market operations
- Governance writes
- Custody
- Exchange-like flows
Instead, MCP focuses on inspection:
- List datasets
- Read dataset metadata
- Query bounded GeoJSON
- Inspect feature versions
- Read audit events
- Review snapshot checksums
- Inspect verification context
- Read operational metrics
This matters because many teams are beginning to use AI-assisted operational workflows.
In that future, an agent should be able to help review context without receiving unnecessary authority.
TermiNode’s MCP support is designed for that boundary.
MCP docs:
https://terminode.io/#docs-mcp
REST / OGC Adapter Direction
TermiNode’s canonical product path currently starts with canister APIs and DApp-based documentation.
At the same time, conventional GIS adoption matters.
Many GIS teams will want to connect through existing tools, internal dashboards, QGIS-style workflows, ETL systems, or REST-oriented integration layers.
That is why TermiNode includes REST / OGC adapter documentation and smoke evidence.
There is an important boundary here:
The current MVP does not promise a separate live api.terminode.io gateway.
Instead, it shows how a future HTTP adapter can sit beside the canonical canister API through:
- Manifest artifacts
- OpenAPI JSON
- Runtime helper
- HTTP adapter smoke
- Connected canister smoke
- GeoJSON export paths
SDK / REST / OGC notes:
https://terminode.io/#docs-sdk
This keeps the MVP honest while still showing a practical adoption path for developers.
Longer-term adapter work may include:
- GeoJSON export improvements
- Bounded viewport reads
- OGC API Features compatibility paths
- QGIS helpers
- ETL helpers
- Customer workspaces
- Monitoring dashboards
- Backup and export automation
- Enterprise readiness workflows
What TRMG Is, and What It Is Not
TRMG is positioned as a utility layer for TermiNode product operations.
The center of the story is not a token.
The center of the story is the product: making spatial records more accountable, versioned, queryable, reviewable, and exportable.
Within that product context, TRMG can support:
- Spatial write credits
- Oracle proof credits
- Governance support
- Operational usage accounting
- Measurable proof workflows
The public TermiNode MVP does not present TRMG as a market product, trading venue, return instrument, or financial promise.
The product posture is utility-first and GIS-first.
That also shapes how community participation is discussed.
Useful contributions may include:
- Reproducible bug reports
- Test evidence
- Documentation fixes
- MCP feedback
- Sample dataset review
- Pilot integration notes
- GIS workflow suggestions
The project should avoid language that creates automatic entitlement based on low-signal activity such as follows, likes, reposts, or referral pressure.
If contribution recognition is used in the future, it should be product-related, manually reviewed, recorded, and aligned with jurisdiction and compliance boundaries.
The goal is not speculation.
The goal is to attract real GIS users, ICP builders, developers, technical partners, and pilot customers who can evaluate the actual product.
How You Can Support TermiNode
The most valuable support right now is simple:
Open the product, test it honestly, and share useful feedback.
1. Test the Live DApp
Live DApp:
Useful pages to review:
- Map evidence: https://terminode.io/#map
- Developer docs: https://terminode.io/#docs
- MCP docs: https://terminode.io/#docs-mcp
- SDK / REST / OGC adapter notes: https://terminode.io/#docs-sdk
- Pilot package: https://terminode.io/#pilot
- Whitepaper: https://terminode.io/#whitepaper
- MVP readiness: https://terminode.io/#mvp-readiness
- Privacy: https://terminode.io/#privacy
- Terms: https://terminode.io/#terms
- Risk disclosures: https://terminode.io/#risk-disclosures
- Compliance: https://terminode.io/#compliance
- Support readiness: https://terminode.io/#support-readiness
Questions worth asking while testing:
- Is the sample dataset understandable?
- Does the map explain the Municipal / Utility pilot story?
- Is the feature audit trail convincing?
- Are proof receipts and evidence exports clear?
- Can a developer understand the integration path?
- Is MCP support explained well?
- Does the product stay GIS-first rather than token-first?
- Would a technical buyer understand what TermiNode is useful for?
2. Give Technical Feedback on GitHub
GitHub:
https://github.com/developertugrul/terminode
Useful feedback areas:
- Reproducible bug reports
- UI / UX issues
- Mobile responsive problems
- GIS workflow suggestions
- GeoJSON import / export suggestions
- MCP tool suggestions
- Documentation fixes
- Production readiness observations
- Security and privacy boundary feedback
3. Join the Community Channels
OpenChat:
https://oc.app/community/n5ozy-iqaaa-aaaac-bfjqa-cai/?ref=ibvd5-dyaaa-aaaac-bfjpq-cai
DSCVR:
https://social.dscvr.one/invite/terminodeio?ur=b45aeee8-eba2-4d84-8733-17d403aed108
X / Twitter:
Telegram group:
Telegram channel:
OpenChat and DSCVR are especially useful for ICP ecosystem feedback.
The Telegram group can be used for faster product testing discussion.
The Telegram channel is reserved for official product updates.
4. Follow Product Testing and Contribution Workspaces
Zealy:
https://zealy.io/cw/terminode/invite/Dic7Y9xXzHKvpqwDNQx1K
Galxe:
https://app.galxe.com/id/4nMGonT5ZdNzAoazWayPAD
Domino quests:
https://terminode.domino.page/quests
These platforms can help organize product testing, feedback collection, and contribution review.
The purpose is not hype.
The purpose is to help more people test the product, find missing pieces, improve documentation, and prepare TermiNode for better pilots.
5. Suggest a Municipal / Utility Pilot
The strongest feedback will come from real or realistic spatial workflows.
Good pilot candidates:
- Municipal service zones
- Utility service boundaries
- Outage response regions
- Maintenance corridors
- Compliance boundaries
- Claim review polygons
- Public works layers
If you know a workflow like this, you can reach out without sending sensitive data at first.
Useful context to include:
- Dataset type
- Geometry format
- Coordinate reference system
- Approximate feature count
- Why proof is needed
- Who needs to inspect the evidence package
- Public / private data boundary
- Current GIS stack
Contact:
support@terminode.io
+90 531 235 42 29
Pilot package:
What Comes Next
TermiNode is currently at the public pilot MVP stage.
The goal at this stage is not to look like a broad enterprise GIS suite.
The goal is to prove one sharp product wedge:
Verifiable spatial records for teams that care about provenance, auditability, bounded reads, proof receipts, and exportable evidence.
Upcoming areas of work include:
- Stronger demo dataset stories
- Better feature-level audit trail views
- Improved version comparison UX
- More visible proof receipt flows
- More readable evidence export packages
- Stronger REST / OGC adapter evidence
- QGIS and ETL helper paths
- More mature MCP read-only tools
- Monitoring and metrics dashboards
- Customer workspace models
- Backup and export automation
- Enterprise readiness checklists
- Support and incident response workflows
- Index canister and transaction history visibility
The long-term goal is not to become “another map viewer”.
The stronger goal is to become a verifiable GIS proof layer that can sit beside existing GIS stacks and make accepted spatial records more accountable.
Short Summary
TermiNode is a GIS infrastructure and verifiable spatial proof-layer DApp running on the Internet Computer.
Today it demonstrates:
- Municipal / Utility sample dataset
- GIS map evidence
- Feature panel
- Audit trail
- Version context
- Proof receipt
- Evidence export
- Developer docs
- REST / OGC adapter notes
- Read-only MCP support
- Utility-first TRMG model
- Pilot readiness surface
Live DApp:
English SSR information site:
Turkish SSR information site:
GitHub:
https://github.com/developertugrul/terminode
Community links:
- OpenChat: https://oc.app/community/n5ozy-iqaaa-aaaac-bfjqa-cai/?ref=ibvd5-dyaaa-aaaac-bfjpq-cai
- DSCVR: https://social.dscvr.one/invite/terminodeio?ur=b45aeee8-eba2-4d84-8733-17d403aed108
- X / Twitter: https://x.com/terminodeio
- Telegram group: https://t.me/terminodexyz
- Telegram channel: https://t.me/terminodeio
- Zealy: https://zealy.io/cw/terminode/invite/Dic7Y9xXzHKvpqwDNQx1K
- Galxe: https://app.galxe.com/id/4nMGonT5ZdNzAoazWayPAD
- Domino quests: https://terminode.domino.page/quests
Contact:
support@terminode.io
+90 531 235 42 29
If you care about GIS, ICP, Rust canisters, MCP, spatial data provenance, civic infrastructure, public-sector accountability, or technical pilot products, I would be grateful if you tested TermiNode and shared feedback.
The best place to start is the live DApp:
A map record does not have to be only a shape on a screen.
With the right architecture, it can become a versioned, queryable, reviewable, exportable, and accountable piece of operational evidence.
That is what TermiNode is trying to build.
Top comments (0)