Governance, Regulation, Ethics and Sustainability

Introduction and context

Blockchain systems are often described as trust-minimising technologies. This description is useful but incomplete. A blockchain does not eliminate governance, regulation, institutional power or ethical responsibility; it redistributes them among protocol developers, validators, token holders, platform operators, application developers, users, regulators and courts. Decisions about software upgrades, validator admission, asset issuance, dispute resolution, privacy and environmental design remain collective decisions, even when they are expressed through code.

For information-technology professionals, governance and regulation are therefore design concerns rather than legal topics added after implementation. A blockchain project may be technically secure yet legally impermissible, economically manipulative, environmentally costly or socially exclusionary. Conversely, a highly regulated and well-governed system may sacrifice some censorship resistance while delivering greater accountability and consumer protection.

This chapter evaluates three major governance settings—protocol, platform and consortium governance—and examines compliance, taxation, consumer protection, AML/KYC, data protection, smart-contract accountability and jurisdiction. It also assesses decentralisation claims, inclusion, market manipulation and environmental impacts.

Learning objectives

By the end of this chapter, a student should be able to:

1. Distinguish protocol, platform and consortium governance.
2. Analyse how power, incentives and accountability are distributed in blockchain systems.
3. Explain the significance of AML/KYC, taxation, consumer protection, data protection and jurisdiction.
4. Evaluate legal and ethical responsibility for smart contracts and decentralised applications.
5. Assess decentralisation claims using technical, economic and institutional evidence.
6. Identify inclusion risks, market-manipulation techniques and sustainability trade-offs.
7. Recommend governance and compliance controls for a blockchain application.

1. Governance as a socio-technical system

Governance is the process through which rules are created, interpreted, enforced and changed. In blockchain, rules exist at several layers:

• Protocol rules: consensus, block validity, transaction ordering, issuance and upgrade procedures.
• Network governance: admission of validators, peer-to-peer operation and responses to attacks.
• Platform governance: rules imposed by exchanges, wallets, cloud providers, application stores or smart-contract platforms.
• Application governance: permissions, fees, dispute mechanisms, oracle administration and user policies.
• Legal and institutional governance: statutes, regulations, contracts, courts, regulators and industry standards.

The phrase “code is law” should be treated as a limited metaphor. Code can automatically enforce some conditions, but it cannot determine the legal meaning of events, resolve every dispute, compensate victims or legitimise unlawful conduct. A transaction may be irreversible at the protocol layer while remaining reversible through a court order, an exchange freeze, a contractual remedy or a software upgrade.

A useful governance analysis asks five questions:

1. Who decides? Identify developers, validators, token holders, operators, users and public authorities.
2. What can they decide? Distinguish technical, financial, operational and legal powers.
3. What incentives constrain them? Consider rewards, reputation, liability, regulation and exit by users.
4. How are decisions challenged? Examine voting, forks, arbitration, courts and market exit.
5. Who bears the consequences? Identify users, creditors, communities, employees, investors and the environment.

Governance also involves a trade-off between efficiency and legitimacy. Centralised decision-making can respond quickly and coordinate compliance, but it may create concentration and abuse risks. Distributed decision-making can broaden participation and reduce dependence on one operator, but it may be slow, technically complex and vulnerable to voter apathy or concentrated token ownership.

2. Three governance models

2.1 Protocol governance

Protocol governance concerns changes to the rules of a blockchain network. It may include formal on-chain voting, informal developer coordination, validator signalling, foundation decisions, or a combination of these mechanisms.

Common decision rights include:

• proposing a software change;
• reviewing and testing code;
• approving or rejecting an upgrade;
• determining activation thresholds and dates;
• responding to security incidents;
• changing monetary or fee policy; and
• deciding whether incompatible versions continue as separate networks.

On-chain voting can provide transparency, but token-weighted voting may convert wealth into political power. One-token-one-vote is not equivalent to one-person-one-vote. Large holders, custodians and exchanges may control substantial voting power, while many users do not vote. Off-chain governance may be more deliberative but less transparent and more dependent on informal authority.

A protocol’s governance risk is not measured only by the number of validators. It also depends on validator ownership, client diversity, geographic distribution, access to development resources, concentration of delegated stake and the ability of users to verify or reject changes.

2.2 Platform governance

A platform governs access to blockchain capabilities. Examples include a smart-contract execution environment, a decentralised-finance interface, an exchange, a wallet provider or a cloud-hosted node service. Platforms determine listing criteria, application interfaces, fees, identity requirements, moderation rules and access to liquidity.

Platform governance is often more centralised than the underlying ledger. An exchange can freeze accounts, delist an asset and collect identity information even when the base protocol is permissionless. A wallet interface can block access to a contract without changing the blockchain itself. These controls may improve safety and compliance but create gatekeeping power and single points of failure.

Platform operators should document decision rights, conflicts of interest, incident procedures, complaint handling, custody arrangements and the circumstances in which access can be suspended. They should distinguish assets held in custody from assets controlled directly by customers and explain operational risks in understandable language.

2.3 Consortium governance

A consortium blockchain is operated by a defined group of organisations, such as banks, hospitals, logistics firms or public agencies. Governance typically uses contracts, membership rules, technical committees and voting procedures.

Consortium governance can provide known participants, access control, privacy controls and clearer accountability. It is appropriate where participants need a shared record but cannot rely on a single organisation. Its limitations include cartel risk, unequal bargaining power, dependence on a small number of operators and difficulties when a participant becomes insolvent or leaves.

A sound consortium agreement should specify:

• membership and admission criteria;
• validator responsibilities and service levels;
• data ownership and permitted uses;
• upgrade and emergency procedures;
• audit rights and security obligations;
• liability and indemnification;
• dispute resolution and applicable law;
• exit, insolvency and data-portability arrangements; and
• procedures for regulatory cooperation.

3. Decentralisation: claim, spectrum and measurement

Decentralisation is not a single property. It has at least four dimensions:

• Architectural decentralisation: how many independent machines or organisations operate the system.
• Political decentralisation: how many independent actors can influence rules.
• Economic decentralisation: how widely ownership, rewards and control are distributed.
• Legal decentralisation: how responsibility and authority are distributed across jurisdictions.

A network can be architecturally distributed but politically controlled by a small development team. It can have many validators but depend on one cloud provider, one client implementation or one token custodian. A permissionless system may still be economically inaccessible because transaction fees, hardware requirements or technical knowledge exclude ordinary users.

Evaluation should use evidence rather than marketing language. Relevant indicators include validator and mining concentration, client diversity, geographic and hosting-provider diversity, stake distribution, governance participation, code-review diversity, dependence on privileged administrators, censorship resistance and the ability of users to run independent nodes. No single threshold establishes decentralisation. The significance of each indicator depends on the threat model and application.

A useful distinction is between formal decentralisation and effective decentralisation. Formal decentralisation describes rules that permit participation; effective decentralisation describes who actually has the resources and influence to participate. This distinction is central to assessing claims made by decentralised autonomous organisations (DAOs).

4. Regulatory and compliance architecture

Blockchain regulation is jurisdiction-specific and changes over time. The same token or service may be classified differently depending on its economic function, distribution method, rights attached to it and the law of the relevant jurisdiction. Technology does not determine legal classification by itself.

4.1 Regulatory classification

A project may fall within rules concerning securities or investment contracts, payment services, electronic money, commodities, derivatives, consumer credit, gambling, corporate law, intellectual property, privacy, cybersecurity or taxation. The analysis should begin with function and conduct, not labels such as “utility token” or “decentralised.”

A compliance inventory should identify:

1. the entity or individuals exercising operational control;
2. the jurisdictions of developers, operators, customers and assets;
3. the services offered, including custody, exchange, lending or brokerage;
4. the flow of funds and fees;
5. the rights promised to token holders; and
6. marketing statements and risk disclosures.

Legal advice is necessary for an actual deployment. General educational analysis cannot replace jurisdiction-specific advice or regulator guidance.

4.2 AML and KYC

Anti-money-laundering (AML) and counter-terrorist-financing controls seek to prevent illicit finance and identify suspicious activity. Know-your-customer (KYC) procedures verify customer identity and support risk-based monitoring. Obligations commonly apply to intermediaries such as exchanges, custodians and certain virtual-asset service providers, although exact coverage differs among jurisdictions.

A risk-based programme may include customer identification, beneficial-owner identification, sanctions screening, transaction monitoring, suspicious-activity reporting, record retention, staff training and independent testing. Blockchain analytics can identify address relationships and transaction patterns, but an address is not automatically a legal person. Analytics may produce false positives and can be evaded through mixers, chain-hopping, privacy technologies or intermediaries.

KYC also creates privacy risks. Organisations should collect only information necessary for a defined purpose, protect it, restrict access and establish retention periods. Compliance is not a justification for unlimited surveillance.

4.3 Consumer protection

Consumers may misunderstand volatility, custody, smart-contract risk, governance risk and the difference between a token balance and a legal claim. Effective protection includes clear disclosures, suitability or appropriateness controls where required, transparent fees, segregation of customer assets, operational resilience, complaint processes and fair marketing.

Important questions include:

• Is the customer buying an asset, a service, a claim or merely access to software?
• Who controls private keys?
• What happens after loss of a key, a hack or a protocol fork?
• Are returns guaranteed or merely projected?
• Can the provider pause withdrawals?
• Are conflicts of interest disclosed?

Consumer protection should also address accessibility. Interfaces should not conceal material risks behind technical terminology or present speculative assets as risk-free savings products.

4.4 Taxation

Tax treatment varies widely. A transaction may create income, a capital gain or loss, a payroll obligation, a withholding obligation, a sales or value-added tax issue, or no taxable event until disposal, depending on local rules and facts. Tax analysis may consider acquisition cost, fair market value, holding period, mining or staking rewards, airdrops, swaps, lending income and compensation.

Accurate records are essential. At minimum, organisations should preserve transaction identifiers, dates and times, asset units, fiat values, fees, wallet ownership, counterparties where known and the method used to calculate basis. A blockchain record proves that an address participated in a transaction; it does not necessarily prove who owned the address or the tax character of the transaction.

4.5 Data protection

Blockchains create tension with data-protection principles because replicated ledgers are difficult to alter or delete. Personal data may include names, identifiers, location information, wallet linkages and metadata, not merely text explicitly labelled as personal.

A privacy-by-design architecture should:

• avoid storing unnecessary personal data on-chain;
• keep sensitive records off-chain under controlled access;
• store only hashes or commitments where appropriate;
• use key rotation and access governance;
• separate identity from transaction data;
• assess re-identification risks; and
• define controller and processor responsibilities.

Hashing does not guarantee anonymity. If an attacker can obtain the original data or link the hash to an individual, the hash may remain personal data. A hash also does not make incorrect information correct or automatically satisfy deletion requirements. Technical immutability must therefore be reconciled with legal rights through architectural separation, revocation mechanisms and carefully designed retention policies.

4.6 Jurisdiction

Jurisdiction can arise from the location of an operator, developer, customer, server, validator, transaction, harmed person or targeted market. A globally accessible application may be subject to multiple legal regimes. “Decentralised” does not mean “outside the law.” Courts may examine practical control, promotion, contractual relationships and benefit flows rather than accepting a project’s label.

Projects should conduct a jurisdictional map covering users, service providers, assets, data, governance bodies and dispute forums. They should consider licensing, geographic restrictions, sanctions, local consumer law, cross-border data transfers and recognition of judgments. A choice-of-law clause helps but does not always defeat mandatory protective rules.

5. Smart-contract accountability

A smart contract is software that executes predetermined logic, often in response to blockchain transactions or external data. It may automate performance, but automation does not settle whether a legally enforceable contract exists. Formation, consent, capacity, interpretation, mistake, fraud, unjust enrichment and remedies remain legal questions.

Responsibility can be distributed among code authors, auditors, deployers, interface operators, oracle providers, governance participants and users. The appropriate analysis is fact-sensitive. Relevant evidence includes who wrote and controlled the code, who marketed the system, whether administrators could upgrade or pause it, what disclosures were made and whether a foreseeable vulnerability was ignored.

Good engineering practice includes:

• requirements and threat modelling;
• access-control review;
• unit, integration and property-based testing;
• independent security audits;
• formal verification for critical invariants where feasible;
• controlled deployment and upgrade keys;
• emergency pause procedures with safeguards;
• bug bounties;
• monitoring and incident response; and
• clear user documentation.

An audit is evidence of a review, not a guarantee of safety. Formal verification can establish properties of a specified model, but it cannot prove that the specification reflects user expectations or that off-chain components are honest.

6. Ethics and social responsibility

6.1 Autonomy, fairness and accountability

Ethical evaluation should consider autonomy, non-maleficence, fairness, transparency and accountability. A system that gives users control over assets may support autonomy, but irreversible errors can cause severe harm. Transparent code may increase accountability, yet technical transparency is not meaningful if users cannot understand the consequences.

Fairness includes access to hardware, internet connectivity, affordable fees, identity documents and financial services. Permissionless participation can coexist with practical exclusion. Governance systems should measure who benefits, who bears risk and who has meaningful voice.

6.2 Inclusion and the digital divide

Blockchain projects may improve remittances, credential verification, supply-chain traceability or access to financial services. They may also exclude people through volatile fees, smartphone requirements, unreliable connectivity, English-only interfaces, biometric requirements or lack of recourse.

Inclusive design may require low-bandwidth interfaces, local languages, accessible user experience, fee subsidies, assisted recovery, offline or delayed workflows and non-blockchain alternatives. Identity systems require particular care: exclusion from a digital identity can become exclusion from employment, welfare or finance.

6.3 Market manipulation

Cryptoasset markets can be thin, fragmented and highly information-asymmetric. Manipulation techniques include wash trading, spoofing, pump-and-dump schemes, insider trading, oracle manipulation, front-running, sandwich attacks and misleading promotional claims. Automated systems can amplify these practices.

Mitigations include surveillance, market-abuse policies, conflict-of-interest controls, transparent token vesting, disclosure of holdings, trading restrictions for insiders, robust oracle design, transaction-ordering protections and enforcement cooperation. However, transparency alone does not eliminate manipulation; public data can help sophisticated actors exploit less-informed participants.

7. Sustainability and environmental impact

Blockchain sustainability has environmental, economic and social dimensions. Proof-of-work consensus requires participants to perform computational work to compete for block-production rights. Its electricity consumption depends on network activity, hardware efficiency, energy prices, block rewards and participant behaviour. Electricity use alone does not establish total environmental harm; the energy mix, equipment manufacture, land use, cooling, noise and electronic waste also matter.

Proof-of-stake generally replaces energy-intensive computational competition with capital-based selection and penalties. It can substantially reduce operational electricity demand, but it introduces risks related to wealth concentration, custodial concentration, governance power and financial barriers to participation. Permissioned systems may use less energy, but lower energy use does not automatically make them socially sustainable.

A project should assess:

• energy consumption and its measurement boundary;
• carbon intensity and location of energy use;
• hardware lifespan and electronic waste;
• social effects on local communities;
• accessibility and affordability;
• resilience and long-term operating costs; and
• whether blockchain is necessary for the proposed benefit.

Environmental claims should state methodology, scope and uncertainty. Offsetting should not substitute for reducing avoidable energy use. A lifecycle perspective is preferable to quoting an isolated transaction estimate, because transaction-level allocation can be misleading in systems whose infrastructure operates regardless of a particular transaction.

8. Applied case: illustrative cross-border agricultural traceability network

Background

A consortium of growers, exporters, logistics firms, retailers and a development agency proposes a blockchain system to record produce origin, inspection events and temperature readings. Retailers want faster recalls, growers want evidence of fair payment and consumers want provenance information.

Problem

The participants face conflicting requirements. Growers have limited connectivity and may lack formal identity documents. Exporters operate in several jurisdictions. Temperature sensors can be inaccurate or manipulated. Personal information about small farmers should not become permanently public. The consortium also wants to market the system as “decentralised and tamper-proof.”

Analysis

The system is a consortium platform, not a fully decentralised public network. Its governance should therefore be explicit. A small committee controlled by large exporters could exclude growers and rewrite operational rules. Conversely, unrestricted publication could expose commercially sensitive data and personal information.

The ledger can provide evidence that a record was submitted and that later changes are detectable; it cannot prove that a sensor was calibrated or that a human entered truthful information. This is the oracle problem: the ledger preserves inputs, but it cannot independently verify all real-world facts.

Approach and solution

The consortium adopts a membership agreement with balanced representation, an independent audit function and published procedures for admitting members, suspending validators and changing software. Detailed personal and commercial records remain off-chain. The ledger stores transaction identifiers, timestamps, permissions and cryptographic commitments. Access is role-based, with retention and deletion processes for off-chain data.

Growers receive assisted onboarding, local-language training and a non-blockchain submission channel that synchronises when connectivity becomes available. Sensor data is signed, calibrated periodically and compared with manual inspections. Disputes are handled by a contractual committee subject to an identified legal forum. Marketing materials state that the system improves traceability but does not guarantee the truth of every input.

Outcome

The design improves recall coordination and auditability without presenting immutability as proof of physical reality. It also reduces privacy exposure and gives less powerful participants a formal voice. The system remains dependent on governance, sensor integrity, contracts and human oversight.

Learning points

1. Governance should match the actual distribution of control.
2. An immutable record is not necessarily an accurate record.
3. Privacy often requires keeping data off-chain.
4. Inclusion must be designed into onboarding and operating procedures.
5. Sustainability includes institutional and social durability, not only electricity consumption.

9. Professional governance framework

A practical blockchain governance review can follow this sequence:

1. Define the purpose: identify the problem and test whether blockchain is necessary.
2. Map actors and jurisdictions: include developers, operators, users, data subjects, regulators and affected communities.
3. Classify assets and services: analyse custody, exchange, lending, payments and investment features.
4. Identify threats: include fraud, key loss, collusion, censorship, oracle failure, privacy leakage and regulatory breach.
5. Allocate powers: document upgrade, pause, treasury, admission and dispute rights.
6. Build controls: apply security testing, access control, AML/KYC, privacy and consumer-protection measures.
7. Measure outcomes: assess participation, concentration, incidents, complaints, energy and inclusion.
8. Review continuously: regulation, code, threats and social effects change over time.

AI may support transaction monitoring, anomaly detection, code review and regulatory mapping. It should not be treated as an autonomous legal decision-maker. Models can produce biased alerts, expose sensitive data or generate insecure code. Human review, audit trails, explainability and appeal procedures remain necessary, especially when AI affects account access or suspicious-activity decisions.

Challenges and limitations

Blockchain governance faces persistent limitations. Legal rules differ across borders and may lag technological change. Decentralised systems can make responsibility difficult to locate without eliminating it. Token voting may reproduce wealth inequality. Privacy-preserving techniques can conflict with traceability requirements. Security controls can introduce centralisation. Environmental comparisons can be distorted by inconsistent measurement. Finally, no technical design can guarantee honest real-world inputs or fair social outcomes.

The appropriate response is neither uncritical adoption nor blanket rejection. It is disciplined socio-technical analysis: identify the value created, compare alternative architectures, allocate responsibility, protect affected people and make claims that evidence supports.

Chapter Summary

Blockchain governance operates across protocol, platform, application and legal layers. Protocol governance determines how network rules change; platform governance controls access and services; consortium governance coordinates known organisations through contracts and committees. Decentralisation is multidimensional and must be assessed using evidence about technical, political, economic and legal control.

Compliance requires attention to regulatory classification, AML/KYC, taxation, consumer protection, data protection and jurisdiction. Smart contracts automate execution but do not remove legal accountability or the need for testing, disclosure and remedies. Ethical analysis must address autonomy, fairness, inclusion, surveillance, market manipulation and the distribution of risks and benefits. Sustainability includes energy, carbon, hardware, social inclusion and institutional durability. Effective blockchain projects therefore combine technical controls with transparent governance, legal analysis, privacy-by-design, consumer safeguards and continuous review.

Key Terms

Governance: The creation, interpretation, enforcement and revision of rules.

Protocol governance: Decision-making about the rules and upgrades of a blockchain protocol.

Platform governance: Rules and controls imposed by an application, exchange, wallet or service operator.

Consortium blockchain: A blockchain operated by a defined group of organisations.

Decentralisation: Distribution of technical, political, economic or legal control.

DAO: A digitally coordinated organisation whose rules and decisions may be implemented through blockchain software.

AML: Measures designed to prevent money laundering.

KYC: Processes for identifying and assessing customers.

Beneficial owner: The natural person who ultimately owns or controls an entity or asset.

Consumer protection: Measures that reduce unfair treatment, deception and unreasonable consumer loss.

Data protection: Legal and technical safeguards for personal information.

Smart contract: Software that executes programmed logic, often on a blockchain.

Oracle: A mechanism that supplies external information to a blockchain application.

Custody: Control or safekeeping of assets or private keys on behalf of another party.

Market manipulation: Conduct that artificially distorts prices, trading activity or market information.

Proof of work: Consensus based on computational effort.

Proof of stake: Consensus that uses economic stake and protocol penalties or rewards.

Privacy by design: Incorporating privacy protection into system architecture from the outset.

Jurisdiction: The legal authority of a state or court over persons, conduct or disputes.

Sustainability: Long-term environmental, economic and social viability.

Review Questions

Short Answer Questions

1. What is the difference between protocol governance and platform governance?
2. Why is decentralisation a multidimensional concept?
3. What are AML and KYC intended to achieve?
4. Why does hashing personal data not necessarily make it anonymous?
5. What is the oracle problem in smart-contract systems?

Long Answer Questions

1. Compare the strengths and risks of protocol, platform and consortium governance.
2. Explain how a blockchain project should analyse jurisdiction and regulatory classification.
3. Discuss the relationship between smart-contract automation and legal accountability.
4. Evaluate the ethical challenges associated with token-weighted governance.
5. Compare proof-of-work and proof-of-stake from environmental, economic and governance perspectives.

Analytical / Application Questions

1. A global token exchange serves users in five countries, holds customer assets and allows token lending. Develop a governance and compliance inventory covering custody, AML/KYC, consumer protection, taxation and jurisdiction.
2. A DAO claims to be decentralised, but three wallets control 65% of voting power and one company maintains the upgrade keys. Assess the claim using technical, political, economic and legal dimensions.
3. Design a privacy-preserving blockchain architecture for a healthcare consortium. Specify what should remain off-chain, how access should be governed and how disputes, corrections and regulatory requests should be handled.

Multiple Choice Questions with Answers

Question 1

Which governance model is most directly concerned with changing consensus rules and block-validation procedures?

A. Protocol governance

B. Platform governance

C. Consumer governance

D. Marketing governance

Correct Answer: A. Protocol governance

Question 2

Why does one-token-one-vote not necessarily represent democratic participation?

A. Tokens cannot be transferred

B. Voting power may be concentrated among wealthy holders

C. Validators never vote

D. Blockchain transactions are always private

Correct Answer: B. Voting power may be concentrated among wealthy holders

Question 3

Which statement about a blockchain hash of personal data is most accurate?

A. A hash always makes data anonymous

B. A hash prevents all re-identification

C. A hash may remain personal data if it can be linked to an individual

D. A hash automatically satisfies deletion rights

Correct Answer: C. A hash may remain personal data if it can be linked to an individual

Question 4

Which activity is most closely associated with KYC?

A. Increasing block size

B. Verifying customer identity

C. Selecting a consensus algorithm

D. Compressing transaction data

Correct Answer: B. Verifying customer identity

Question 5

What does an oracle provide to a smart contract?

A. External information or events

B. A replacement private key

C. A legal jurisdiction automatically

D. Guaranteed truthful data

Correct Answer: A. External information or events

Question 6

Which is a principal limitation of an immutable ledger?

A. It cannot record timestamps

B. It proves that every real-world input is truthful

C. It preserves submitted information but cannot independently verify all inputs

D. It cannot be replicated

Correct Answer: C. It preserves submitted information but cannot independently verify all inputs

Question 7

Which is an example of market manipulation?

A. Independent code review

B. Wash trading to create artificial trading volume

C. Customer identity verification

D. Data minimisation

Correct Answer: B. Wash trading to create artificial trading volume

Question 8

Which statement best describes proof-of-stake?

A. It selects participants solely through repeated hashing competitions

B. It uses economic stake in consensus and may impose penalties

C. It requires every user to operate a mining rig

D. It eliminates all governance concentration

Correct Answer: B. It uses economic stake in consensus and may impose penalties

Question 9

What is a major reason to keep sensitive personal information off-chain?

A. Off-chain data is always public

B. Blockchain replication and immutability can conflict with privacy and correction requirements

C. On-chain data cannot be encrypted

D. Off-chain systems never require access controls

Correct Answer: B. Blockchain replication and immutability can conflict with privacy and correction requirements

Question 10

Which statement best reflects the meaning of 'decentralised' in legal analysis?

A. The system is automatically outside all laws

B. No person can ever be held responsible

C. Legal responsibility may still arise from practical control and conduct

D. Jurisdiction applies only to physical servers

Correct Answer: C. Legal responsibility may still arise from practical control and conduct