@venusprotocol/isolated-pools 1.3.0-dev.2 → 1.3.0-dev.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -161,6 +161,25 @@
|
|
|
161
161
|
"name": "Unauthorized",
|
|
162
162
|
"type": "error"
|
|
163
163
|
},
|
|
164
|
+
{
|
|
165
|
+
"anonymous": false,
|
|
166
|
+
"inputs": [
|
|
167
|
+
{
|
|
168
|
+
"indexed": true,
|
|
169
|
+
"internalType": "address",
|
|
170
|
+
"name": "vToken",
|
|
171
|
+
"type": "address"
|
|
172
|
+
},
|
|
173
|
+
{
|
|
174
|
+
"indexed": false,
|
|
175
|
+
"internalType": "uint32",
|
|
176
|
+
"name": "newBlock",
|
|
177
|
+
"type": "uint32"
|
|
178
|
+
}
|
|
179
|
+
],
|
|
180
|
+
"name": "BorrowLastRewardingBlockUpdated",
|
|
181
|
+
"type": "event"
|
|
182
|
+
},
|
|
164
183
|
{
|
|
165
184
|
"anonymous": false,
|
|
166
185
|
"inputs": [
|
|
@@ -471,6 +490,25 @@
|
|
|
471
490
|
"name": "RewardTokenSupplySpeedUpdated",
|
|
472
491
|
"type": "event"
|
|
473
492
|
},
|
|
493
|
+
{
|
|
494
|
+
"anonymous": false,
|
|
495
|
+
"inputs": [
|
|
496
|
+
{
|
|
497
|
+
"indexed": true,
|
|
498
|
+
"internalType": "address",
|
|
499
|
+
"name": "vToken",
|
|
500
|
+
"type": "address"
|
|
501
|
+
},
|
|
502
|
+
{
|
|
503
|
+
"indexed": false,
|
|
504
|
+
"internalType": "uint32",
|
|
505
|
+
"name": "newBlock",
|
|
506
|
+
"type": "uint32"
|
|
507
|
+
}
|
|
508
|
+
],
|
|
509
|
+
"name": "SupplyLastRewardingBlockUpdated",
|
|
510
|
+
"type": "event"
|
|
511
|
+
},
|
|
474
512
|
{
|
|
475
513
|
"inputs": [],
|
|
476
514
|
"name": "INITIAL_INDEX",
|
|
@@ -790,6 +828,11 @@
|
|
|
790
828
|
"internalType": "uint32",
|
|
791
829
|
"name": "block",
|
|
792
830
|
"type": "uint32"
|
|
831
|
+
},
|
|
832
|
+
{
|
|
833
|
+
"internalType": "uint32",
|
|
834
|
+
"name": "lastRewardingBlock",
|
|
835
|
+
"type": "uint32"
|
|
793
836
|
}
|
|
794
837
|
],
|
|
795
838
|
"stateMutability": "view",
|
|
@@ -900,6 +943,11 @@
|
|
|
900
943
|
"internalType": "uint32",
|
|
901
944
|
"name": "block",
|
|
902
945
|
"type": "uint32"
|
|
946
|
+
},
|
|
947
|
+
{
|
|
948
|
+
"internalType": "uint32",
|
|
949
|
+
"name": "lastRewardingBlock",
|
|
950
|
+
"type": "uint32"
|
|
903
951
|
}
|
|
904
952
|
],
|
|
905
953
|
"stateMutability": "view",
|
|
@@ -936,6 +984,29 @@
|
|
|
936
984
|
"stateMutability": "nonpayable",
|
|
937
985
|
"type": "function"
|
|
938
986
|
},
|
|
987
|
+
{
|
|
988
|
+
"inputs": [
|
|
989
|
+
{
|
|
990
|
+
"internalType": "contract VToken[]",
|
|
991
|
+
"name": "vTokens",
|
|
992
|
+
"type": "address[]"
|
|
993
|
+
},
|
|
994
|
+
{
|
|
995
|
+
"internalType": "uint32[]",
|
|
996
|
+
"name": "supplyLastRewardingBlocks",
|
|
997
|
+
"type": "uint32[]"
|
|
998
|
+
},
|
|
999
|
+
{
|
|
1000
|
+
"internalType": "uint32[]",
|
|
1001
|
+
"name": "borrowLastRewardingBlocks",
|
|
1002
|
+
"type": "uint32[]"
|
|
1003
|
+
}
|
|
1004
|
+
],
|
|
1005
|
+
"name": "setLastRewardingBlocks",
|
|
1006
|
+
"outputs": [],
|
|
1007
|
+
"stateMutability": "nonpayable",
|
|
1008
|
+
"type": "function"
|
|
1009
|
+
},
|
|
939
1010
|
{
|
|
940
1011
|
"inputs": [
|
|
941
1012
|
{
|
|
@@ -1161,7 +1232,7 @@
|
|
|
1161
1232
|
"0x45f8a08F534f34A97187626E05d4b6648Eeaa9AA"
|
|
1162
1233
|
]
|
|
1163
1234
|
},
|
|
1164
|
-
"implementation": "
|
|
1235
|
+
"implementation": "0xfAE44cf6309598c2557Bb265BF0401D594db97DA",
|
|
1165
1236
|
"devdoc": {
|
|
1166
1237
|
"details": "This contract implements a proxy that is upgradeable by an admin. To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector clashing], which can potentially be used in an attack, this contract uses the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two things that go hand in hand: 1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if that call matches one of the admin functions exposed by the proxy itself. 2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation. If the admin tries to call a function on the implementation it will fail with an error that says \"admin cannot fallback to proxy target\". These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due to sudden errors when trying to call a function from the proxy implementation. Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way, you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy.",
|
|
1167
1238
|
"kind": "dev",
|