Native EVM & Account Abstraction Data Model
Brixs uses the highly proven, globally adopted Account-based model intrinsic to the Ethereum Virtual Machine (EVM), augmented heavily by our native implementation of EIP-4337 Account Abstraction.
Testnet Environment
Our EVM execution environment is currently deployed on the Testnet. Standard Solidity smart contracts and EVM dev tools (like Hardhat and Foundry) work out-of-the-box.
How it Works
Unlike alternate L1s that require learning new execution architectures, Brixs embraces Ethereum's standard state trie while supercharging how accounts operate.
Externally Owned Accounts (EOA)
Standard cryptographic keypairs (e.g. MetaMask). Fully supported for backward compatibility.
Smart Contract Accounts (SCA)
Accounts managed by code rather than private keys. Natively bundled into the protocol for zero-gas UX.
Account Abstraction at the Protocol Level
Brixs doesn't rely on third-party relayers for gasless transactions. We have built a custom JSON-RPC gateway that natively intercepts user Intents and routes them through our protocol-level Paymaster.
// Example of an EIP-4337 UserOperation on Brixs
{
"sender": "0xabc...123",
"nonce": "0x1",
"callData": "0x4f2a...881b",
"paymasterAndData": "0xPaymasterAddress...SponsorshipData",
"signature": "0x..."
}
State Management
The EVM State Trie
Raw blockchain data is ingested into our modified state Merkle tree. While it maintains 100% equivalence with Ethereum's data structures (enabling seamless contract deployments), it is heavily optimized for fast retrieval required by our ZK-Prover Engine.
// Connect to the Testnet RPC and interact natively
const provider = new ethers.providers.JsonRpcProvider("http://localhost:8545");
const code = await provider.getCode("0xYourContractAddress");
console.log(`Deployed Bytecode: ${code}`);