Azimuth

Institutional market intelligence for @Arc.

[Azimuth @UseAzimuth]

Azimuth launches follow a fixed order:

1. Add config, theme and vocabulary
2. Deploy token + FeeCollector with a fresh deployer
3. Isolate database, Redis, domain and RPC infrastructure
4. Smoke test
5. Live

A terminal launch is more than a contract deployment.

[Azimuth @UseAzimuth]

A signal engine cannot be tested only by checking whether an alert appeared.

Azimuth’s test plan starts with deterministic fixtures for every signal kind: known input, expected output.

That is how a price move signal stays a calculation rather than an impression.

[Azimuth @UseAzimuth]

Historical market data needs to be retained.
Live market data needs to move.

Azimuth’s architecture separates those jobs:
Timescale for prices and signals over time, Redis for fanout when the terminal needs the latest update.

One system for the record. One for the moment.

[Azimuth @UseAzimuth]

A fund NAV, an FX rate and a traded token do not share one honest price source.

Azimuth’s configuration supports different price adapters, including Chainlink mult, StableFX and NAV feeds.

The data source is part of the instrument definition, not an implementation detail.

[Azimuth @UseAzimuth]

Transfers, swaps, depth changes and feed updates are not interchangeable.

Azimuth ingests them as separate inputs before its signal workers process them.

That is how a flow spike remains different from a depth shift, even when both happen at the same time.

[Azimuth @UseAzimuth]

Most products call it multichain when they mean multiple forks.

Different code.
Different feature sets.
Different failure modes.

Azimuth is built around one terminal core.
@arc gets its own configuration and data adapter.

Not a second product to maintain.

[Azimuth @UseAzimuth]

Signal weighting is an editorial decision.

Azimuth computes the same signal types across its terminals.
The brand configuration decides what leads the feed.

On @arc, PRICE_MOVE and EVENT sit first.

Same data. A clearer first question.

[Azimuth @UseAzimuth]

Arc is not a new colour scheme on another chain’s data.

Its Azimuth adapter is built around @arc RPC, StableFX rate events, fund/NAV feeds and benchmark fixes.

The visual layer can be branded.
The source data has to be native.

[Azimuth @UseAzimuth]

A market terminal does not need a vault to be useful.

Azimuth keeps data collection, signal processing and alerts in its application stack.

Onchain: a brand token and fee collector.

Watch the market.
Do not ask users to deposit into another protocol.

[Azimuth @UseAzimuth]

Markets leave receipts.

Azimuth’s shared data model keeps prices, signals and alert firings in time series storage.

That matters when the real follow up is:
what did we know when this signal went out?

A terminal should leave a trail.
Built for @arc

[Azimuth @UseAzimuth]

A feature request should not create five versions of the product.

Azimuth has a simple core rule: if a feature is in the terminal core, every brand gets it. If it is not, no brand gets a special exception.

Restrictive by design. Better software because of it.

[Azimuth @UseAzimuth]

Shared code does not mean shared blast radius.

Each Azimuth brand is specified to run with separate database, Redis, domain and RPC key infrastructure.

One terminal core. Separate operational surfaces.
Soon on @arc

[Azimuth @UseAzimuth]

Fast deployment is usually where quality goes missing.

The Azimuth launch path is deliberately boring:
load the config and theme, deploy the token and fee collector, isolate the infrastructure, smoke test, then go live.

Speed only counts if the checklist survives it.

[Azimuth @UseAzimuth]

Colours, logo, type and vocabulary belong in a theme layer.

Azimuth keeps them separate from the market-data engine, so @arc can have its own desk language without becoming a separate codebase with separate bugs.

[Azimuth @UseAzimuth]

A new chain changes quickly.
Documentation, feeds and interfaces move with it.

Azimuth’s @arc build specification pins ABIs and feeds from Arc’s live documentation at build time.

Small implementation detail. Important data discipline.

[Azimuth @UseAzimuth]

A terminal is not a landing page with a chart added later.

Azimuth’s UI is specified as a dark, data dense PWA:
A working surface built around the board, not a page designed to make the data look sparse.

Soon on @arc

[Azimuth @UseAzimuth]

A brand configuration can break a product just as easily as a code change.

Azimuth’s test plan runs the full suite against every brand configuration and keeps a visual snapshot per theme.

Different look. Same standard.

[Azimuth @UseAzimuth]

A stale oracle should not create a current price.

Azimuth’s design labels stale or paused feed states.
Its test plan is explicit: paused or stale conditions are labelled, never priced.

Soon @arc

[Azimuth @UseAzimuth]

Azimuth does not reduce every move to price.

It computes separate signals for price moves, peg or basis drift, depth shifts, holder shifts, flow spikes, and events such as NAV updates or pauses.

[Azimuth @UseAzimuth]

A price terminal is a screen.
A market terminal needs to explain the move.

Azimuth is designed for @arc assets where price, liquidity, NAV, peg conditions and market events can tell very different stories.