Why build on Dash?

Your ticket marketplace has an architecture problem. Buyers like Alice need to pay sellers like Bob, find tickets that are still available, choose readable usernames, earn a loyalty token, and resell ticket records to new owners. Some attendee details, including legal names and accessibility notes, must remain confidential. Which parts, if any, belong on Dash?

The tempting choice is to put the whole marketplace on Dash because all of those facts belong to one app. That would be a mistake. The useful question isn't "Can Platform store this?" but "What would Alice and Bob gain if no marketplace operator, you included, held the only authoritative copy?"

Which records earn a place?

Payments have a straightforward route: buyers spend Dash when they pay sellers. Past payments, Platform gives the marketplace usernames, its loyalty token, and ticket records that can change hands. Module 3 introduced those capabilities; here they matter because each solves a marketplace requirement.

The ticket record makes the strongest case for shared state. If you alone control the ownership database, Alice must trust your service not to revoke her ticket, assign it twice, or disappear before she can resell it. Putting ticket ownership on Platform gives her and Bob a common record that one marketplace operator doesn't control alone.

The same argument doesn't apply to every row. Your draft email, a cached search page, and an internal support note don't become better merely because a network stores them. A conventional database is the better tool when one operator is an acceptable authority and nobody needs to verify the record independently. Dash fits the parts that benefit from public payments or shared, verifiable state, not automatically the whole application.

An answer buyers can check

Ownership only helps if Alice can find the right tickets. The marketplace might ask, "Which tickets for this event are still available?" Platform can answer questions over indexed state, meaning records are organized by fields chosen in advance so applications can filter or sort them efficiently. Her app doesn't need to download every ticket and trust your server to filter the list.

There are two claims in a search result: these records match the question, and they match the state the network committed. A Platform query can include cryptographic evidence for the second claim, letting the app verify the result against committed state instead of taking the responding node's word for it. Later lessons handle query syntax, index design, and proof checking. For this architecture decision, the capability is enough: the shared data can be queried, and the answer can be checked.

Public means public

That useful search changes the privacy decision. Records written to shared Platform state are queryable wherever their indexes permit, so you must treat them as public application data. Ticket ownership may deserve that visibility; Alice's legal name or accessibility notes don't.

Those confidential details belong in encrypted form or in storage outside Platform. Encrypting a value means the shared record contains unreadable data and the app controls who receives the key. Keeping it off-network lets you use ordinary access controls instead. Either choice accepts the same limit: a public shared record isn't a safe place for a plaintext secret.

This is the public-ledger tradeoff in application terms. Alice may expect only you to see a support note, but writing it to Platform can make it available far beyond you. The interface and privacy policy need to match what the architecture actually reveals.

Two balances in one purchase

Now follow one resale. Alice sends Dash to Bob because Dash is the asset used for payment. Changing the ticket's owner updates Platform state, and Platform charges Credits for that work. Credits are created from Dash, but they remain a separate balance used for Platform fees.

So "Alice has enough Dash" answers only the payment question. The Platform account submitting the ownership change also needs enough Credits, whether she funds them or you sponsor the fee. The split is simple: spend Dash to move money; spend Credits to store or change application state.

Depending on the network

Choosing shared state means your marketplace now depends on work that your company doesn't direct alone. Dash introduced its decentralized autonomous organization, or DAO, in 2015, and it is the oldest DAO still operating. The useful governance loop is short: proposals request funding from the network treasury, masternodes vote on them, and approved work receives treasury funding.

That doesn't guarantee you'll like every funded proposal. It tells you how the network chooses and pays for work it depends on, rather than leaving that role entirely to one company's budget. The official Dash governance guide explains the system, and DashCentral's current proposals page shows active proposals and their voting status.

Make the cut

The final architecture uses Dash for buyer-to-seller payments, public ticket ownership, usernames, the loyalty token, and verifiable ticket searches. It keeps confidential attendee details and operator-only records elsewhere. If you didn't need shared ownership or independently checkable results, a normal database would be cheaper in complexity and easier to keep private.

Apply the same cut to your own app. For each payment or record, ask who must trust the operator, who needs to verify the answer, and who may read the data. Choose Dash where public, shared, verifiable state changes those answers for the better. Reject it where secrecy matters, one operator is already trusted, or the record gains nothing from network agreement.

Check your understanding

Restoring your progress…

5 correct to pass