Identities

Alice's marketplace profile works in two apps, just as it did in What is Dash Platform?. Both show the same biography. Now Alice wants to change it, which raises a question the profile alone can't answer: who is allowed to write?

Her wallet can sign a request, but a signature alone doesn't answer the network's question: is this the person allowed to edit this profile? Platform needs a record connecting the profile's owner to the keys that can act for them. That's what an identity provides.

Who can change the profile?

An identity is an account recorded on Platform. It has a stable identifier, public keys, and a credit balance. The profile's owner field points to that identifier, not to the app Alice happened to use.

When Alice saves a new biography, her wallet signs the request with a private key. Platform checks the signature against a public key registered on her identity and checks that the key is allowed to authorize this action. It also checks that her identity owns the profile and that the update follows the data contract's rules.

Bob, selling tickets on the same marketplace, could submit a biography with exactly the right fields and a valid signature from his own identity. It would still fail the ownership check. A valid signature proves who authorized a request; it doesn't give that person permission to change someone else's data.

The wallet and identity do different jobs here. The wallet manages private keys and signs locally. The identity is the public network record used to check that authority. Its identifier is a 32-byte value, usually displayed as a string. Knowing it lets someone refer to Alice's account, not sign as her. Private keys aren't published in that record.

A Core address is a payment destination for Dash, not the owner account for a Platform document. Alice may control both with the same wallet, but receiving Dash at an address doesn't create an identity.

A readable name isn't the account either. A DPNS name such as alice.dash can point to an identity. The identity works without a name, and the profile refers to its identifier rather than the name.

Why not use one key for everything?

The marketplace app needs permission to update Alice's biography. It doesn't need the power to replace all the keys on her account or transfer her remaining credits elsewhere. Keeping those jobs separate limits what an exposed everyday key can authorize.

Each identity key has a purpose:

A key also has a security level: Master, Critical, High, or Medium. These guide how clients should protect the key and affect which actions it can authorize. Master is reserved for updating the identity itself; it isn't an all-purpose key to use for every request.

Every identity requires exactly one master-level authentication key. A separate authentication key can handle ordinary document writes, provided its level meets the document's requirements. High is commonly used for this kind of signing. Critical keys call for stronger protection, while Medium keys are intended for less sensitive uses such as encryption and decryption.

Alice's everyday signing key is exposed, but her master key remains safe. She can authorize an identity update to disable the exposed key and add a replacement. Her identity identifier stays the same, so her profile still belongs to the same account. The disabled key can't authorize new changes; replacing it doesn't undo changes an attacker already made.

That gives the separation a practical purpose: routine editing doesn't require handing the app the authority needed to manage the account's keys. A wallet can derive several keys from one seed phrase, but they're still separate keys with separate permissions. The labels don't protect them automatically; the app must keep more powerful private keys out of routine use.

Who pays when Alice saves?

Authorization is only part of accepting the update. Network operators also do work to check and store it. Platform charges for that work in credits, deducted from the identity's balance for an ordinary document write.

There are two kinds of charge:

• Processing fees pay for checking and applying the request.
• Storage fees pay for keeping data on the network.

The conversion unit is fixed: 1 duff = 1,000 credits. A duff is one hundred-millionth of a Dash, so 1 DASH corresponds to 100,000,000,000 credits. This conversion doesn't tell you what a profile update costs. The fee depends on the operation, the data, and the network's fee rules.

For a simplified calculation, suppose Alice has 120,000 credits and an update costs 10,000 in processing plus 40,000 in storage. These are illustrative amounts, not a network quote; assume no refund or extra fee adjustment.

The total is 50,000 credits, leaving 70,000. If a second update costs the same, she'll have 20,000 left. A third 50,000-credit update would need more funding, even if she still has Dash in her Core wallet.

Which balance needs topping up?

For that profile update, it's Alice's identity balance that needs credits. Having money elsewhere doesn't automatically pay the bill.

Credits can reach an identity through a Core funding transaction that locks Dash for use on Platform. They can also come from an already funded Platform address, a separate destination that holds credits directly on Platform. A Platform address can fund an identity's creation or top up an existing one; it isn't the identity that owns Alice's profile.

So when an app reports insufficient credits, check the balance of the identity signing the write. Don't assume that a funded Core wallet or Platform address means that identity is funded too. Funding is a separate operation, with its own fees.

Alice doesn't have to supply the funds herself. Anyone can top up her identity, which is how the marketplace covers its users' fees. Paying into her balance doesn't give the developer her keys or ownership of her profile. Funding an account and controlling it are different things.

Check your understanding

Restoring your progress…

4 correct to pass