DeBu Studio

DEBU STUDIO: DECENTRALIZED BUREAUCRACY PLATFORM

PURPOSE

DeBu Studio is a web3 application that brings bureaucratic processes onto the blockchain. It solves a fundamental problem: complex multi-step workflows like approvals, payments, and form submissions are often centralized, opaque, and controlled by single institutions. DeBu Studio decentralizes these processes, making them transparent, auditable, and executable on-chain where every action is recorded immutably.

The platform enables organizations and individuals to design standardized processes once and then execute them repeatedly without needing to rebuild the workflow each time. Think of it as creating reusable process templates for any bureaucratic operation.

WHAT USERS CAN DO

Users interact with DeBu Studio through three main sections:

DESIGN SECTION Users can create new process templates by defining a sequence of steps. Each step can be one of three types: a form (for data collection), an approval (requiring a wallet signature from an authorized person), or a payment (requiring a transaction of 0.00001 ETH). Users specify the name, description, and category of the process, then add as many steps as needed. Once designed, the template is deployed to the blockchain and becomes permanently available for anyone to use. This is the "blueprint creation" phase.

BROWSE SECTION Users can see all process templates that have been deployed by the community. They can filter by category, name, or search by contract address. For each template, users can see how many steps it contains and instantly start a new instance of that process by clicking "Start". This phase is about discovering and launching existing workflows. When a user starts a process, a unique instance is created just for them on the blockchain.

EXECUTE SECTION Users can step through their active process instance. For each step, they see what type of action is required. If it's a form, they enter data. If it's an approval, they sign the action with their connected wallet to prove authorization. If it's a payment, they confirm a small ETH transaction (0.00001 ETH). The step execution is recorded on-chain with the user's address, timestamp, and submitted data. Once all steps are completed, the process instance is marked as complete.

REAL-WORLD USE CASES

A government agency can design a permit approval workflow: citizen submits form → department head approves → treasurer collects fee → citizen receives confirmation. Instead of manual spreadsheets and email, it's now transparent and immutable on-chain.

A supply chain company can create a product inspection process: supplier ships goods → inspector verifies quality → warehouse confirms receipt → payment is processed. Each step is signed and recorded, eliminating disputes.

A legal firm can design a contract signing workflow: client reviews document → client signs electronically → attorney reviews → payment is collected → contract is finalized. Everything happens in one transparent flow.

A non-profit can create a donation and grant process: donor contributes → board votes on allocation → funds are disbursed → impact is reported. Community can see exactly where money goes.

KEY BENEFITS FOR USERS

Transparency: Every action is recorded on-chain and publicly verifiable Immutability: Once a step is completed, it cannot be altered or deleted No intermediary: Users control the process; no centralized authority can change the rules Reusability: Design once, execute many times Auditability: Complete history of who did what and when Decentralization: Anyone can design and share process templates Lower friction: Wallet signatures replace passwords and logins

WHO SHOULD USE IT

Government agencies streamlining citizen services Supply chain companies ensuring accountability Legal and financial services providing transparent workflows Non-profits managing grants and donations DAOs (decentralized organizations) automating governance Any organization needing an auditable multi-step process that multiple parties must complete

BOTTOM LINE

DeBu Studio turns bureaucracy from a closed-door operation into an open, transparent, and blockchain-verified system. Users design what they want to happen, and the blockchain ensures it happens exactly that way, with permanent proof that each step was completed by the right person at the right time.

ADDITIONAL CONTEXT: Privacy on chain and Data on Chain, alongside other modern advances in the web3 space, are critical features that need to be implemented on this protocol for real-world usage.

DEBU STUDIO SMART CONTRACT ARCHITECTURE

The three smart contracts work together in a hierarchical factory pattern that enables users to design and execute decentralized bureaucratic processes on-chain.

CONTRACT 1: DeBuDeployer (Factory Contract) The DeBuDeployer is the entry point and factory for the entire system. When a user designs a new process in the UI and clicks "Deploy", the DeBuDeployer's deployProcess function is called. This function receives the process name, description, category, and an array of step definitions from the frontend. DeBuDeployer then creates a new instance of ProcessTemplate and stores its address in the deployedProcesses array. It emits a ProcessDeployed event that logs the creator, process name, and category—this allows the frontend to index all deployed processes. Think of DeBuDeployer as the blueprint registry; it doesn't execute anything, it just manages the creation and tracking of process templates.

CONTRACT 2: ProcessTemplate (Blueprint/Template Contract) ProcessTemplate is deployed by DeBuDeployer and represents an immutable blueprint of a bureaucratic process. Each ProcessTemplate stores the process metadata (name, description, category, version) and an array of Step structs. Each Step contains actionType (form, approval, or payment), configuration JSON, description, and name. ProcessTemplate is read-only from the user's perspective during process execution. However, it has a critical method called instantiate() that creates new instances of the process. When a user clicks "Start" on a process in the Browse section, they're calling the instantiate() function on the ProcessTemplate contract. This function creates a new ProcessInstance contract, passes itself (the ProcessTemplate address) as a reference, and records the new instance in the userInstances mapping. This mapping tracks which instances belong to which user, enabling quick retrieval on the frontend.

CONTRACT 3: ProcessInstance (Execution Contract) ProcessInstance represents a running execution of a process. It's created by ProcessTemplate's instantiate() function and receives two key pieces of information: the ProcessTemplate address (so it knows the rules) and the initiator address (who started it). ProcessInstance maintains state during execution through the stepStates mapping, which tracks the status, actor, data, and timestamp for each completed step. When a user executes a step in the Execute section, they call either executeStep() (for form and approval steps) or executeStepWithPayment() (for payment steps that require 0.00001 ETH). These functions validate that currentStepIndex hasn't exceeded the total step count (obtained from the linked ProcessTemplate via the IProcessTemplate interface). Upon step completion, the function stores the step data, emits a StepCompleted event, and increments currentStepIndex. The isCompleted() function checks if all steps have been executed by comparing currentStepIndex against the step count from ProcessTemplate.

INTERACTION FLOW IN ORDER:

User designs a process in the Design page → Frontend calls DeBuDeployer.deployProcess() DeBuDeployer.deployProcess() creates a new ProcessTemplate contract ProcessTemplate is registered in DeBuDeployer.deployedProcesses array User browses processes in Browse page → Frontend reads DeBuDeployer.deployedProcesses User clicks "Start" on a process → Frontend calls ProcessTemplate.instantiate() ProcessTemplate.instantiate() creates a new ProcessInstance contract ProcessInstance is stored in ProcessTemplate.userInstances[user] User is redirected to Execute page with the ProcessInstance address User executes steps → Frontend calls ProcessInstance.executeStep() or executeStepWithPayment() ProcessInstance reads from ProcessTemplate via the IProcessTemplate interface to validate step count ProcessInstance stores execution data and emits events When all steps are complete, ProcessInstance.isCompleted() returns true KEY DESIGN PATTERNS:

Factory Pattern: DeBuDeployer creates ProcessTemplates, ProcessTemplate creates ProcessInstances. Each level manages the next.

Template Method Pattern: ProcessTemplate provides the blueprint (immutable rules), ProcessInstance executes against those rules.

Dependency Injection: ProcessInstance receives ProcessTemplate address in constructor so it can validate execution against the blueprint.

Interface Segregation: ProcessInstance only needs the IProcessTemplate interface (minimal interface with just getStepCount), not the full ProcessTemplate contract.

Event Emission: Each contract emits events (ProcessDeployed, InstanceCreated, StepCompleted) allowing the frontend to track state changes without polling.

This hierarchical structure ensures separation of concerns: DeBuDeployer manages deployment, ProcessTemplate defines rules, and ProcessInstance executes them.

FRONTEND: It's made of TSX components with the related css. I was heavily assisted by AI on the frontend components creation because this is not my main specialty.