Contract Permissions
Contract permissions are the fine-grained resource authorization layer in Prividium™. For each role, they control two things, both enforced through the Prividium™ API: which contract functions the role may call (read or write), and which contract events the role may read. Function rules are role-based (RBAC) and can add attribute conditions (ABAC) — for example, restricting an argument to the caller's own address. Administrators configure permissions in the Admin Dashboard under Contract Permissions.
1. Open the Permissions page
- Go to the Admin Dashboard at
http://localhost:3000. - Select Contract Permissions from the sidebar.
- You will see a list of all registered contracts and their function-level access rules.
2. Register a contract
Note: System contracts are registered automatically at startup. You cannot create, edit, or delete them. Skip to step 3 to configure their permissions.
Before you can assign permissions, register the smart contract that needs access control.
- Click Add contract (or + Add contract).
- Fill in the details:
- Contract Name (Required)
- Contract Address (Required, starts with
0x) - Description (Optional)
- Template (Optional): Select a pre-defined template to inherit default permissions.
- Contract ABI: Paste the full JSON ABI of the contract.
- Disclosure Settings (Optional, only shown when selective disclosure
is enabled — it is disabled by default):
- Check Disclose bytecode to make the bytecode hash public.
- Check Disclose Erc 20 Supply to expose total supply data (if it's an ERC20 token).
- Click Save Changes.
Once registered, the contract's functions will be listed in the Function Permissions table.
Edit a registered contract
To update a registered contract's details, click the contract in the list, then click Edit.
You can update any field including the Contract Address. Use this when a contract is redeployed to a new address — all existing function and event permissions transfer automatically to the new address. After saving, the page redirects to the new address.
Note: You cannot change the address to one that belongs to an existing contract or a system contract.
3. Configure function permissions
Permissions are managed directly from the contract details page. There are two types of permissions you can configure: Function Permissions and Event Permissions.
To configure functions:
- In the Contracts list, click on the contract you want to manage.
- Ensure the Function Permissions tab is selected (default).
- For each function row:
- Permission Level: Select the desired level from the dropdown:
- Forbidden: No one can call this function (default).
- All Users: Any authenticated user can call it.
- Check Role: Only users with specific roles can call it.
- Restrict Argument: Restricts arguments (e.g., user can only use their own address).
- Access Details:
- If Check Role is selected, choose the authorized role(s).
- If Restrict Argument is selected, choose the argument index to restrict.
- Permission Level: Select the desired level from the dropdown:
- Changes are saved automatically (or click the checkmark if present).
4. Function permission rule types
| Rule Type | Description | Example Use Case |
|---|---|---|
| All Users | Allows any authenticated user to call this function | Read-only views like getGreeting() |
| Check Role | Requires the caller to hold one of the listed roles | Only users with Trader role can call transfer() |
| Restrict Argument | Ensures a function argument matches the caller's wallet address | User can only updateGreeting(address) if the address is their own |
| Forbidden | Blocks all access to the function | Internal or deprecated functions |
5. Configure event permissions
Admins can also control which roles are allowed to read specific smart contract events (e.g., via eth_getLogs).
Similar to functions, events are restricted by default.
- In the Contracts list, click on the contract you want to manage.
- Select the Event Permissions tab.
- Click + Add Permission.
- In the Add Event Permission modal:
- Event: Select the specific event you want to allow (e.g.,
GreetingUpdated) or choose All Events to apply the rule to all events in the contract. - Roles: Select the role(s) that should have access to these events.
- Event: Select the specific event you want to allow (e.g.,
- Click Create.
The new permission rule will appear in the Event Permissions table. Users with the assigned roles can now query logs for these events.
By design, Prividium™ uses a deny-by-default model: if a function is set to Forbidden (the default state for new contracts), the Prividium™ rpc blocks all access to it.
6. Edit or remove a permission rule
-
For Functions:
- To update: Change the Permission Level or Access Details dropdowns in the Function Permissions table.
- To reset: Set the Permission Level back to Forbidden.
-
For Events:
- To delete: Click the trash icon next to the event permission rule in the Event Permissions table.
Tip: If a function or event is not listed, check that your ABI is correct and up to date.
7. Default access policy
By design, Prividium™ uses a deny-by-default model: if a function or event is not explicitly permitted, the Proxy blocks access to it.
This ensures that only explicitly authorized functions can be called and events queried, reducing risk of accidental exposure.
8. Testing permissions
After updating permissions:
- Open the User Dashboard.
- Log in as a user with a specific role.
- Interact with the connected dApp or contract through the Prividium™ RPC.
- Verify that allowed functions/events succeed and restricted ones fail.
If the Prividium™ RPC returns 403 Forbidden, the user lacks permission for that function or event.
9. Example configuration
| Contract | Function/Event | Access | Rule Type | Allowed Roles |
|---|---|---|---|---|
| Token | transfer(address,uint256) | Write | Check Role | Trader |
| Token | approve(address,uint256) | Write | Restrict Argument | Trader |
| Token | balanceOf(address) | Read | Check Role | Trader, Auditor |
| Token | Transfer (Event) | Read | Check Role | Auditor |
| Registry | register(address,string) | Write | Check Role | Admin |
10. Best practices
- Keep All Users rules to a minimum to ensure authenticated control.
- Use Restrict Argument for address-sensitive functions.
- Review permissions regularly, especially after contract upgrades.
- Document your role-to-permission mapping for audits.