Skip to content
Question Vault?
Free to readNo accountNo email wallNo invented statisticsNo partial listsCopy or print any set and take it with you

Questions to Ask About Blockchain

Questions to ask about blockchain when a vendor, a founder or an enthusiast has pitched you a project, a product or a token, for the manager or investor who has to decide and the student who has to assess it. They follow the order the decision goes in: what a shared ledger solves here that a database would not, who runs the chain, security and custody, cost and speed, the token and the rules around it, and proof that it works.

54 questions

The questions

Each question, and why to ask it

The problem

What problem does this solve that a shared database could not?

Why ask it

Have the person describe how they would build it with an ordinary database first, then say exactly where that version fails. A solid answer is about who gets to keep the record when nobody involved will accept a single keeper. Speed, lower cost and transparency in general are things a database with good access controls already offers.

Can you walk me through one transaction from start to finish, without the jargon?

Why ask it

Good for a student and just as good for a board. You should hear who submits it, who checks it, how it is grouped with others and when it counts as settled. Someone who understands the system can do it in a minute; a reply that leans on 'decentralized' and 'trustless' to fill the gaps is a sign to bring someone more technical next time.

Which parties write to this ledger, and why can none of them be trusted to keep it alone?

Why ask it

A shared ledger earns its complexity when the writers are rivals or strangers, such as competing banks or suppliers in different countries. When every writer sits inside one company, or one participant runs it for the rest anyway, you are being offered a slower database with a new name.

What exactly is recorded on the chain, and what is kept somewhere else?

Why ask it

Most systems store only a fingerprint or a pointer on the chain and keep the document, image or file on ordinary servers. That is sensible, but it means the off-chain part can still be changed, lost or switched off. Have them draw the two halves and say who is responsible for each.

Who checks that the information is true before it goes on the ledger?

Why ask it

A ledger preserves whatever it is given, so a false entry is kept as faithfully as a true one. For anything physical, such as a shipment, a diamond or a land title, a person or a sensor still has to vouch for it at the door. A pitch with no answer for that step has moved the trust problem, not removed it.

Is this a public chain anyone can join, or a private one with approved members, and why?

Why ask it

Neither is better in itself. A public chain brings openness and outside validators at the price of less control and visible data; a permissioned one brings control and privacy, and then the question becomes what it offers over a database the members share. Listen for a reason tied to your case and not to fashion.

What does the smart contract do here that a normal agreement and a payment system would not?

Why ask it

A smart contract is a program that runs on the chain when its conditions are met, so it suits simple rules both sides want enforced automatically. It cannot weigh anything that needs discretion, and a bug in it executes as reliably as the intended logic. Ask what happens when the code and the written agreement disagree.

Who else has to join before this is useful, and how many of them already have?

Why ask it

A ledger with one company on it is not shared. Get names and dates, and separate signed participants from those 'in discussions'. If the value depends on your competitors or your suppliers signing up, find out what the plan is when they decline.

What do we give up by using a blockchain for this?

Why ask it

Every design has a price: slower writes, entries that are hard to correct, data copied to every participant, and a smaller pool of people able to maintain it. An advocate who lists the trade-offs unprompted has probably built one. 'Nothing' is a salesperson's answer.

Who runs it

Who runs the nodes or validators, and how many of them are independent of you?

Why ask it

Count the separate organizations, not the machines. Twenty nodes run by one company and its investors are one point of control with twenty addresses. A published list of operators, and a way for an outsider to apply to run one, are both good signs.

How are transactions agreed on, and what does that method demand of the people who take part?

Why ask it

This is the consensus question. Proof of work spends computing power, proof of stake puts up tokens as a bond, and permissioned systems usually let a named set of members vote. Each one settles who has power over the ledger and what attacking it would cost, so you want the method named and the reason it fits in two or three sentences.

Who can change the rules or upgrade the code, and how is that decided?

Why ask it

Somebody always can. It may be a foundation, a core team, a vote weighted by token holdings or a committee of member firms. Ask about the last change that was contested and how it was settled, because the written process and the real one often differ.

Is there an admin key that can pause, freeze or reverse things, and who holds it?

Why ask it

Many projects keep one, and for a young product it can be a reasonable safety net. What matters is that it is disclosed, that it takes several people to use, and that you know when it would be used. Finding it in the code later, after being told nobody controls the system, is a serious mark against the team.

Which underlying chain is this built on, and what happens to us if that chain raises its fees, splits or fades?

Why ask it

A product built on someone else's network inherits that network's costs, outages and politics. A careful team has thought about moving and can say roughly what it would involve. Blank looks here mean the dependency has not been examined.

What happens to the system and our records if your company closes?

Why ask it

With a public network the ledger carries on without the vendor, though the app and the support may not. With a private one the vendor is often the thing holding it together. The reply you want covers who keeps the nodes running, who holds the code, and where in the contract it says so.

How is an error or a fraudulent entry corrected if records cannot be edited?

Why ask it

The usual answer is a new entry that reverses the old one and leaves both visible, as an accountant would do it. The worrying answers are 'that cannot happen' and 'we would just roll it back'. The second tells you the ledger is less permanent than the brochure says.

When two participants disagree, who decides, and under which agreement?

Why ask it

Code settles what the code covers and nothing else. For a business network you want signed member rules that name a process and a legal venue. For a public project, find out whether any person or body can be held to account at all, and if none can, size your exposure to match.

Who are the people behind this, and can I verify their names and earlier work?

Why ask it

Real names, work histories you can check and earlier projects that still exist are the baseline. Anonymous founders are part of the culture in some corners of this field, which is exactly why to weigh it: there would be no one to pursue if the money went missing.

Security

Who holds the private keys, and what happens if one is lost or stolen?

Why ask it

Whoever holds the key controls the asset, and on most chains there is no reset button. If you would hold it, ask about backups and who in your organization could sign. If they would, you are trusting a custodian and should question them as you would a bank.

What stops a single employee, yours or ours, from moving funds alone?

Why ask it

Look for approvals that need several keys held by different people, limits on amounts and a delay on large transfers. Ask who those people are and what happens when one of them leaves. 'Our founder keeps the key safe' is one person, however trustworthy.

Has the code been audited by an outside firm, and can I read the full report?

Why ask it

Ask which firm, which version of the code and what was left unfixed, since an audit covers only what was put in front of the auditor on that date. A badge on a website is not a report. Even a clean one lowers the odds of an obvious flaw and promises nothing beyond that.

What would an attacker need in order to rewrite or reverse confirmed transactions?

Why ask it

On a public chain the answer is usually control of a majority of the mining power or a large share of the staked tokens, and the team should be able to say roughly how expensive that would be on this particular network. Small chains are far cheaper to overwhelm than the famous ones. For a private chain, ask how many members would have to collude.

Which parts sit outside the chain and could be attacked: bridges, price feeds, wallets, the website?

Why ask it

Trouble tends to arrive at the edges, where the ledger meets something else. Have them list each connection and say who secures it. A team that only talks about how strong the chain is has not answered.

Has this chain or its code ever been hacked, halted or rolled back, and what changed afterward?

Why ask it

A dated account with the fix described is reassuring, whether the story is an outage, a bug caught late or a phishing attempt on staff. 'Nothing, ever' means the product is very new or the person is not being straight with you. Incidents on public networks are usually written up somewhere, so search for the name before you take the reply as complete.

What personal or commercial data goes on the ledger, and who can read it?

Why ask it

On a public chain, assume everything written is visible to anyone and stays that way, even when names are replaced by addresses. Pricing, volumes and trading partners can sometimes be worked out from patterns alone. A good design keeps sensitive data off the chain, and the team can show you what a competitor would see.

If someone has the right to have their data deleted, how would you do it?

Why ask it

Permanent records and privacy rules pull against each other, and how that is resolved depends on the law where you and your customers are. A common design keeps personal data off the chain so it can be erased, leaving only a reference behind. Take the reply to your own legal or compliance people before you rely on it.

If you hold assets for us, are they kept apart from your own, and how can I confirm it?

Why ask it

You want to hear about separate addresses you can look up yourself, an outside audit and a clear statement of what happens to client assets if the firm fails. That last point turns on the contract and on local law, so ask how it works where they are based and where you are. 'It is all on the blockchain' does not tell you who legally owns it.

Cost and speed

How many transactions can it process per second today, and where was that measured?

Why ask it

Lab figures and live figures can be far apart. Ask for the number on the production network under normal load, then compare it with your own busiest hour. If only a test result exists, treat throughput as unknown.

How long before a transaction is final and cannot be undone?

Why ask it

Appearing on screen and being settled are two different moments, and the gap runs from about a second to an hour or more depending on the chain. For payments, or anywhere goods are released on confirmation, that wait is your real processing time. Ask what the user sees in between.

What does each transaction cost, who pays it, and how much has that fee moved in the past year?

Why ask it

On public networks the fee floats with demand, so a process that is cheap in the demo can be expensive on a busy day. Ask for the range, not the average, and whether the vendor absorbs it or passes it on. A fixed-fee promise should name who carries the difference.

What happens to our transactions when the network is congested or goes down?

Why ask it

Networks do halt and queues do form. You should hear about retries, a fallback process and how users are told. If the pitch claims the chain never stops, look up its status history yourself.

Beyond the fees, what will it cost to build, integrate and staff this over the first three years?

Why ask it

License or node fees are usually the small part. Connecting it to existing systems, hiring or training people who understand it, a fresh audit after each change and legal review all add up. Put the total next to an estimate for doing the same job with a conventional database.

How do records get from the systems we already use onto the chain, and back again?

Why ask it

Staff will go on working in the accounting, inventory or records software they have, so something has to carry entries both ways. Find out whether connectors exist for your systems or would be written for you, and who maintains them when either side updates. Typing the same entry into two systems by hand is how a pilot quietly dies.

How much energy does the network use, and where does that figure come from?

Why ask it

The answer differs enormously by design: proof of work networks consume a great deal by design, while proof of stake and permissioned ones use roughly what ordinary servers do. If your organization reports on emissions, ask for a source you can cite and check that it describes this chain and not a different one.

If we wanted to leave, how would we get our records out and carry on elsewhere?

Why ask it

Being able to read the chain is not the same as having your data in a form another system accepts. Ask for a sample export, the format and the price. On a private network, also ask whether your history stays with the other members after you go.

Token and rules

Does this need its own token, and what would break if it used ordinary money or none?

Why ask it

Some networks need a token to pay validators or deter spam. Other products add one mainly to raise funds. If the honest answer is that nothing would break, you are looking at a financing method attached to software, and should judge the two separately.

Would we or our customers have to hold cryptocurrency or manage a wallet to use this?

Why ask it

Plenty of business ledgers involve no coin at all, and some products hide the wallet behind an ordinary login. If people must buy a token, pay fees in it or look after a key, that is the step where ordinary users drop out, and one your finance team has to approve. Have them show you the sign-up as a new user would see it.

Who holds the tokens today, and when are founders and early backers free to sell?

Why ask it

Ask for the allocation table and the unlock schedule, and check them against what the chain itself shows. A large share in few hands that unlocks soon means the people pitching you can sell into your purchase. A vague reply about 'the community' holding most of it deserves a request for addresses.

Where does the promised return or yield come from?

Why ask it

There are only a few real sources: fees paid by users, interest from borrowers, or newly issued tokens that dilute everyone. If the reward is paid in the project's own token from a pool the project created, the yield tends to last only while new buyers keep arriving. A seller who cannot name the payer has not explained the return.

How is the supply set, and who can create more?

Why ask it

A cap written into code that nobody can alter is one thing; a cap in a white paper, with a team that can upgrade the contract, is another. Find out how many tokens are still to be released, to whom, and on what dates.

If I wanted to sell, where would I do it and how much trades on an ordinary day?

Why ask it

A quoted price means little if selling your amount would move it. Look at the volume on the venues they name and compare it with what you would hold. Listings only on small or unregistered exchanges, or a lockup that applies to you and not to insiders, are reasons to slow down.

Which regulators have you dealt with, and how is this classed where I live?

Why ask it

Whether a token counts as a security, a commodity, a payment instrument or something else varies by country and sometimes by state, and it is still changing. A serious team names its legal advisers, its registrations and the places it does not sell. 'It is decentralized, so the rules do not apply' is an opinion, not a clearance; check with the regulator or a lawyer where you are.

How do you verify who your users are and screen for sanctioned parties or laundered funds?

Why ask it

For a manager this decides whether your own compliance team can approve the project at all. Expect to hear about identity checks, transaction monitoring and a named person in charge of both. A product proud of asking no questions may be one your bank will not let you send money to.

How would this be taxed and shown in our accounts?

Why ask it

Do not take the seller's reply as the last word, because the treatment of tokens, fees and rewards differs between tax authorities and has shifted over time. What you can learn here is whether they have thought about it: can they supply transaction records in a form an accountant can use? Then put the same question to your own accountant.

Would a record or a contract on this chain stand up as legally binding where we operate?

Why ask it

A ledger entry saying you own a building does not move the title unless the local registry or a court recognizes it. Ask which written agreement sits behind the code and which jurisdiction governs it. Some places have passed laws on electronic records and digital assets and others have not, so have a lawyer confirm it for yours.

Proof it works

Is this live with real users today, or is it a pilot, a test network or a plan?

Why ask it

Get one of those four words. Pilots and test networks are honest stages, but neither is evidence that it works at scale or that anyone will pay. Follow up with the launch date and what has happened to usage since.

Can you show me real activity on a public block explorer right now?

Why ask it

One advantage of a public chain is that you need not take anyone's word: transactions, active addresses and contract code are there to be seen. Have them open it in front of you and explain what you are looking at. Activity that comes from a handful of addresses, or that stopped months ago, tells its own story.

Who is paying for this today, and may I speak to two of them?

Why ask it

Paying customers are different from pilot partners, grant recipients and users rewarded in tokens for showing up. Call the references and ask what it replaced and what they would do differently. Reluctance to provide any is an answer.

Which of the company names on your partner slide have signed contracts?

Why ask it

Logos get onto slides through a single meeting, a free trial or membership of the same industry group. Go through them one at a time: signed, paying, in production? It is a fair thing to ask, and a straightforward team will sort the slide into those piles without taking offense.

What on your roadmap has shipped when you said it would, and what slipped?

Why ask it

Past delivery is the best guide to the promises in the deck. Ask for two items that were late and why. A roadmap where the hard parts, such as scaling, handing over control or regulatory approval, are all still ahead is a plan and should be priced as one.

Is the code open for anyone to read, and who outside your team has contributed to it?

Why ask it

Open code lets independent people test the claims, and outside contributors suggest it would survive the founders. Closed code is not disqualifying for a private business system, but then you are relying on the vendor's word and should ask for the source to be held in escrow. Look at the repository's recent activity yourself.

What would have to be true for you to tell a customer that blockchain is the wrong tool?

Why ask it

A knowledgeable advocate can reply straight away: one operator everyone already trusts, very high volumes, data that must stay private or be deleted, rules that need human judgment. If nothing would ever make it the wrong tool, you are hearing belief, not analysis.

Can we run a small pilot on real data first, and what would count as success?

Why ask it

Agree on the measure before it starts: a cost per transaction, a reconciliation time or an error rate, compared with how you do it now. Keep the pilot small enough to walk away from. If success is defined only afterward, every pilot succeeds.

What happens if I take a month to think about this?

Why ask it

Countdown timers, bonus tiers that expire tonight and 'only a few allocations left' are sales pressure, and a familiar feature of token sales. A sound project is still there in a month. If the offer would not survive you reading the documents and getting a second opinion, let it go.

How to question a blockchain pitch

Practical guidance for the conversation itself

Before the meeting

Sketch the database version first

Write half a page on how you would solve the same problem with an ordinary shared database and one operator everybody trusts. Every claim in the pitch can then be held against that sketch, and you will notice quickly when the answer amounts to the same thing with a chain underneath.

Read what is already public

For a public project the white paper, the code repository, the token contract and a block explorer are open to you before anyone speaks. Note three things you could not find or could not follow and begin with those. For an enterprise product, ask for the technical documentation in advance and see how long it takes to arrive.

Settle what you can afford to lose

A manager is risking a budget and a system other people depend on; an investor is risking cash. Fix the limit before the conversation and write it down. Enthusiasm in the room is not information, and a number chosen beforehand is easier to keep to.

Bring someone who can read the answers

If you are not technical, invite a developer or an IT colleague for Who runs it and Security. If money is involved, line up the lawyer or accountant you would send the tax and legal replies to, since several notes on this page end with asking them.

Which questions for which pitch

A business or supply chain product

Spend most of the time in The problem, Who runs it and Cost and speed. The token group can usually be skipped unless fees are paid in one. Close with the pilot question and agree on a measure of success before anyone starts building.

A token, coin or yield offer

Start with Token and rules, then the admin key, the people behind it and the custody questions. Check the replies against the chain and the published documents the same day. If the return cannot be traced to somebody paying for something, the rest of the list does not need asking.

A class, an essay or an interview

The first group and the consensus question cover how a ledger works and when it is the right tool. Put them to a guest speaker or use them as headings. The question about when blockchain is the wrong tool makes a good closing one, because it asks for judgment instead of a definition.

When you only have ten minutes

Ask what a shared database could not do, who holds the admin key, who holds the private keys, whether it is live, and who is paying for it today. Five direct replies justify a longer meeting. Five evasions save you one.

Reading the answers

Specifics against vocabulary

A reply with names, dates, numbers and a document you can open is worth more than a fluent one built from 'decentralized', 'immutable' and 'transparent'. When you hear one of those words, ask what it means in this system: decentralized among whom, immutable unless what, transparent to which people.

Check whatever can be checked

Open the block explorer, read the audit report and look up the registration with the regulator directly instead of following a link you were sent. Public chains make more of a pitch verifiable than most technologies do. A team that points you to the evidence unprompted is showing you how it works.

Count 'I do not know' in their favor

Nobody can answer all of these on the spot, and a founder who says so and follows up in writing is behaving as you would want a partner to. Be more careful with someone who has a smooth reply to everything, including the questions about law and tax in your country that they are in no position to settle.

Ask for it in writing

Send a short email afterward listing what you were told about custody, fees, lockups and who can change the code, and ask them to confirm it. Anything that shrinks or disappears between the meeting and the reply was not a commitment.

Where these decisions go wrong

Starting from the technology

A project that begins with 'we should be doing something with blockchain' looks for a problem afterward and usually finds a weak one. Begin with the process that hurts and let the first group of questions decide whether a shared ledger belongs in the answer.

Reading 'on the blockchain' as 'true'

The ledger shows that an entry was made and has not been altered since. It says nothing about whether the entry was accurate, whether the goods exist or whether a court would recognize it. Keep the question about who checks the information at the door near the top of your list.

Taking a rising price as proof

A token can climb while the product behind it has no users, and fall while the product improves. Usage, paying customers and delivered roadmap items are the evidence. The Proof it works group is deliberately about those and not about charts.

Skipping your own advisers

How a token is classed, how it is taxed and whether an on-chain record has legal force all depend on where you are, and the person selling is not the one to rule on it. Treat their replies as a starting point and pay for an hour with someone who works for you.

More on this topic