DAPI and Proofs

Your marketplace asks Dash Platform for Alice's public profile, and an answer comes back even though you don't run a node or choose a server. Before your app acts on it, four questions matter: who answered, what happens if that machine fails, what stops it from lying, and what do you still have to trust?

One reply from a network

The request goes through DAPI, Dash's decentralized API, and one evonode answers it. That machine is a Dash network node which serves Platform data; it isn't a hidden copy of your application's backend.

One machine still sent the reply, so what makes the API decentralized? DAPI is available through many network nodes rather than one server belonging to the company that built your app. Your app doesn't depend on that company keeping an API process alive, and no single DAPI instance is the only route to Platform.

This distinction is easy to miss. A decentralized service doesn't mean every request comes from the network as a single voice. It means your client has a choice of network nodes, while a normal company API usually gives it one operator's service as the authority and point of access.

If the first node stays silent

The SDK needs candidates before it can choose one. On Dash's live network (mainnet) and its practice network (testnet), it contacts seed nodes, which help it discover addresses for DAPI nodes on that network. It then rotates among the discovered addresses instead of binding the app to one DAPI server.

If the first candidate never answers the request for Alice's profile, the SDK can retry through another discovered node and temporarily avoid the failed address. A bad pick can cost time, but it doesn't have to take the app offline. Later requests aren't stuck waiting on the same broken machine either.

Discovery solves an access problem, not a truth problem. Seed nodes help the client find candidates; they don't make every answer from those candidates correct. Likewise, an encrypted TLS connection protects bytes while they travel between the app and a node, but a well-protected connection can still carry a false answer.

Now change the scenario. The selected node replies promptly, but it alters Alice's profile before sending it. Retrying only helps if another node happens to return something different, and then the app has two claims with no reason to prefer either. Availability has been handled; honesty hasn't.

Evidence travels with the answer

A proof-aware Platform request can return her profile together with a state proof: cryptographic evidence tying the result to state the network has finalized and committed. Finalized state is the accepted Platform state for a completed block, rather than a pending change that nodes may still disagree about.

The SDK checks that evidence locally. If it verifies, your app can establish that the returned profile matches the committed state. The same kind of evidence can support an answer that a requested record is absent, so a node can't safely turn "not found" into an unsupported assertion. If verification fails, the SDK rejects the result instead of presenting altered data as verified.

A troublesome node still has ways to waste your time. It can stay silent, delay its reply, omit proof evidence where an ordinary response is allowed, or send evidence that fails the check. Proofs don't force a machine to cooperate, which is why the SDK still needs retry and temporary avoidance. Retry finds another speaker; verification decides whether the proof-bearing statement from that speaker deserves acceptance. Keeping those jobs separate prevents a common mistake: treating a responsive node as an honest one.

An ordinary API response can't provide that conclusion. It contains a payload and may arrive through an encrypted connection, but the receiver still has to trust the server's account of the data. Nor does a response become proved merely because it came through DAPI or an SDK. DAPI supports ordinary responses too; only a proof-bearing response that the client successfully verifies crosses this boundary.

Return to Alice's profile:

• If the reply has no checked proof, the app trusts the node for what it says.
• If the proof checks, the app verifies that this profile, or its reported absence, agrees with committed Platform state.

Changing nodes improves the first case's chance of getting an answer. It doesn't turn that answer into the second case.

What the proof doesn't say

Proof verification needs an anchor that the responding node can't choose for itself. A lightweight client uses public keys for the group of network nodes that committed that Platform state. Those keys let it check the network's commitment without creating one. In the pinned SDK's trusted setup, a well-known HTTPS service supplies those keys and the discovered node addresses as trusted context.

That leaves a narrower, but real, trust boundary. For a successfully verified response, your app doesn't have to trust the DAPI node's payload. It still trusts the hosted service to supply the correct public keys for that network group, and it trusts the SDK and cryptographic verifier running locally to perform the check correctly.

That last row matters. A valid proof can establish that Platform committed a profile saying "I am an accredited reseller." It can't inspect Bob's accreditation or decide whether he told the truth. The proof authenticates what the shared state says, not every real-world claim recorded inside it.

Running a full node changes the boundary because the node can derive those public keys from the Core chain rather than accepting the hosted key source. Lightweight DAPI access therefore doesn't have the same trust model as running a full node. It gives an app locally checkable Platform answers without requiring the app to maintain and validate the full chain, but the remaining anchor and client software still count.

For any DAPI result your app might act on, ask two separate questions. Did the response carry a proof that the client actually verified? And where did the client obtain the keys used as its anchor? "The SDK returned it" answers neither one by itself.

Check your understanding

Restoring your progress…

4 correct to pass